Благотворительный фонд "Счастливые люди" поделился презентацией для публичной работы над ошибками. Мои комментарии - это синие пузыри на слайде. Предложенная структура на последних слайдах. Презентация очень большая, ее цель: публичное выступление перед волонтерами, их привлечение в фонд.
15 декабря 2015 года в Бизнес-инкубаторе ВШЭ прошло открытое занятие в рамках программы резидентства HSE{Pro}, посвященное исследованию потребителей и проведению проблемных и решенческих интервью.
Спикер - Александр Еремеев, руководитель заочного акселератора ФРИИ.
Как сообщать пользователю, если «упс, что-то пошло не так»Собака Павлова
При разработке любого ПО команды — как большие, так и маленькие — уделяют проработке сценариев с ошибками и сбоями слишком мало времени.
Многие просто создают однотипные интерфейсные окна типа «Ошибка № 392904» или «Упс, что-то пошло не так», не задумываясь, что почувствует пользователь. А ведь он может разозлиться, расстроиться или, хуже того, потерять доверие к продукту.
Доклад поможет взглянуть на ошибки программного обеспечения глазами обычных людей. Мы поговорим о том, как научить интерфейс грамотно сообщать об ошибках и сбоях, чтобы не бесить пользователей.
Благотворительный фонд "Счастливые люди" поделился презентацией для публичной работы над ошибками. Мои комментарии - это синие пузыри на слайде. Предложенная структура на последних слайдах. Презентация очень большая, ее цель: публичное выступление перед волонтерами, их привлечение в фонд.
15 декабря 2015 года в Бизнес-инкубаторе ВШЭ прошло открытое занятие в рамках программы резидентства HSE{Pro}, посвященное исследованию потребителей и проведению проблемных и решенческих интервью.
Спикер - Александр Еремеев, руководитель заочного акселератора ФРИИ.
Как сообщать пользователю, если «упс, что-то пошло не так»Собака Павлова
При разработке любого ПО команды — как большие, так и маленькие — уделяют проработке сценариев с ошибками и сбоями слишком мало времени.
Многие просто создают однотипные интерфейсные окна типа «Ошибка № 392904» или «Упс, что-то пошло не так», не задумываясь, что почувствует пользователь. А ведь он может разозлиться, расстроиться или, хуже того, потерять доверие к продукту.
Доклад поможет взглянуть на ошибки программного обеспечения глазами обычных людей. Мы поговорим о том, как научить интерфейс грамотно сообщать об ошибках и сбоях, чтобы не бесить пользователей.
Навыки и не-навыки проектировщика интерфейсовСобака Павлова
14 мая 2017 года, ITGM (http://piter-united.ru/itgm10/), СПб.
# Смежники
компоновка текста
веб-вёрстка
контент в таблицах
схемы
бумага
числа и статистика
# Прототипус обыкновенус
концепция
интерактив
контент-наполнение
# Инструменты
ручка и бумага
скорость работы с инструментом
библиотеки
автоматизация
эксперименты
# Команда
признавать команду
«тянуть» вводные
читать документы
участвовать в мозговом штурме
презентовать эскизы
# Не надо!
текст
бизнес-анализ
анализ пользователей
управление проектом
внедрение и отладка UX-процессов
Догнать и перегнать: российский и западный опыт применения качественных метод...Собака Павлова
28 октября 2016 года, SECR, Москва.
http://2016.secr.ru/program/submitted-presentations/russian-and-foreign-experience-of-usage-qualitative-methods-in-ux-research
A little introduction of Design Manager role.
Short lecture for students at The Estonian Information Technology College (UI design course) on March, 19th, 2016
Каждый проект начинается со сбора требований. У каждого участника проектной группы своя картина мира и свое видение, что входит в это понятие.
Давайте вспомним, о чем мечтают аналитики и менеджеры, когда заходит речь о сборе требований.
Вопрос в зал: что еще делает идеальный заказчик?
А теперь давайте посмотрим правде в глаза. С чем мы сталкиваемся при сборе требований чаще всего.
Вопрос в зал: С чем еще вы сталкивались?
Вопрос в зал: Как считаете, почему так происходит?
В работе над проектом нельзя взяться за задачу и молча уйти её выполнять. А потом отметить её выполнение. Очень хочется, но нельзя. Если заказчик понимает, как работает группа, какие задачи зачем выполняются, у него появится ощущение контроля ситуации. С заказчиком, понимающим что происходит, проще общаться на равных.
Обычно, мы с коллегами проводим презентацию документов всякий раз, когда хотим что-то показать заказчику. Не стоит просто высылать сформированные документы на утверждение.
Например, когда мой коллега так поступил на одном из проектов, работа с заказчиком забуксовала. Заказчик сердился, не понимал, какие работы были проведены и зачем ему нужны эти документы. Он не представлял ценность документов. И главное, почему они стоят столько денег? Мне «повезло» реабилитировать имя компании. Мы смогли вырулить из той ситуации, но вера в нашу компетентность пошатнулась и её пришлось долго восстанавливать. Заказчик жаждал проводить экзамены, презентация каждого документа напоминала защиту диплома, все решения приходилось обосновывать и отстаивать. Конструктивный диалог не получался. В итоге проект, конечно, был завершен, но чувства морального удовлетворения не было ни у заказчика, ни у нас.
Вопрос в зал: У вас были подобные истории? Какие выводы вы сделали?
Задавайте много! Очень много разных вопросов. Даже если сначала кажется, что эта информация вам не понадобится.
Проводя интервью я обязательно предупреждаю опрашиваемого о том, что вопросов будет много и они могут повторяться. Далеко не все заказчики могут ответить на вопросы о проекте сразу. «Какова цель создания нового сайта?» - спрашиваю я. «Ну.. Не знаю.. Рассказывать о нашей уникальной услуге?» - неуверенно отвечает заказчик. И только в конце беседы выясняется, что сайт должен… продавать!
Возможна и другая ситуация: на старте проекта у заказчика нет точного представления, что он хочет получить в конце проекта. «Мне нужен сайт. Он должен рассказывать о моих услугах.» - говорит заказчик. А во время беседы заказчик сам для себя формулирует, что на самом деле ему хочется, чтобы большинство заказов приходили напрямую, а не через посредников. Как говорится, почувствуй себя психологом! :)
Бывает так, что не получается сразу получить ответ заказчика. Да, иногда надо подумать. Можно дать заказчику немного времени и обязательно договориться о дате, когда ответ будет дан. Задавая много вопросов вы показываете заказчику свою заинтересованность в проекте и помогаете ему глубже погрузиться в проект.
Очень помогает в работе привлечение заказчика к выполнению задач.
Собрать и структурировать нужную для проекта информацию. Найти ближайшего конкурента. В любом проекте есть такие мелкие подзадачи. Задачи для проектной группы заказчика должны быть простыми и выполняться быстро. Конечно, мы и сами найдем конкурентов заказчика и внимательно их проанализируем, но если заказчик принимает активное участие в работе, он чувствует, что несет ответственность за результат такую же, как и вы.
Требования могут появляться снова и снова. Идеи о новом функционале у заказчика могут рождаться постоянно. Например, он поговорил с мамой, или прочитал что-то в интернете и прибегает к вам «Я такое придумал!»… Или, что значительно хуже, не рассказывает вам об этом, потому что вы должны сами догадаться. Вы же специалист.
Хотя казалось бы, еще в начале проекта договорились о рамках проекта.
В такой ситуации мы проводим ранжирование. Это может быть ранжирование требований или, например, ранжирование пользовательских потребностей.
Как мы это делаем? В первую очередь мы пишем портреты пользователей.
Например, такие.
Опыт показывает, что заказчику проще представить себе кто будет пользоваться услугой или товаром, если в портрете описать предысторию, цель пользователя, его вопросы, антипатии, симпатии и поведенческие привычки.
Потом описываем пользовательские потребности. Обычно это длинный список задач, с которыми пользователь приходит на сайт.
А потом начинается самая интересная и порой сложная для заказчика работа: ранжирование потребностей.
Ранжирование помогает оценить значимость потребностей, найти пересечение интересов разных пользователей и помогает выделить, что для них самое главное.
Задача заказчика — указать приоритет каждой потребности для каждого пользователя.Правила следующие: максимальные 3 балла можно присвоить меньше 25% потребностям. 2 балла можно присвоить только 25% потребностям. 1 балл – больше 25% потребностей. Важно отобрать самые важные потребности и отсеять максимум неважных.
Если заказчику сложно перестроиться и увидеть проект глазами будущих пользователей. Или если он искренне уверен, что всё, абсолютно всё очень важно и ни от чего нельзя отказаться. Ранжирование будет необычайно полезно.
В результате ранжирования заказчик принимает решение о функционале. Решение выстраданное, осознанное и основанное на экспертизе заказчика.
Что самое ценное, не навязанное аналитиком или менеджером.
Решение, которое сам заказчик будет отстаивать в будущем, решение, которое он вряд ли захочет отменять.
В чем наша выгода от всего этого? Работать на следующих этапах будет легче.