Подготовиться и провести юзабилити-тестирование самостоятельно

UX-исследовательница СКБ «Контур» Эмилия Городовых составила руководство для тех, кто только начал сам проверять свои решения и хочет делать это качественно.

К UX-исследователям в СКБ «Контур» часто приходят с запросом проверить решение — будет ли оно понятно пользователям, всё ли учтено.

Обычно это происходит на этапе, когда команда уже собрала аналитику и придумывает или проектирует новое решение. Либо когда уже есть действующий сервис и работающее решение.

При этом бывает, что ресурса UX-исследователей не хватает на все команды и проекты, а делать добро пользователям хочется.

Содержание:

1. В чём суть.
2. Как подготовиться.
   
3. Как пригласить пользователей.
   
4. Как провести юзабилити-тестирование.
   
5. Анализ результатов.
   

Модерируемое юзабилити-тестирование (далее буду писать просто ЮТ) относится к качественным методам (да, это значит, что есть и количественные немодерируемые, но сейчас о них не будем).

Суть ЮТ в том, чтобы проверить и оценить, насколько пользователю удобно решать свои задачи в интерфейсе и с какой эффективностью он это делает, какие возникают проблемы и почему они важны в его сценарии работы.

ЮТ позволяет получить убедительные результаты именно потому, что опирается на поведение пользователя. Исследуется то, что люди делают, а не то, что говорят. Во время ЮТ есть модератор или исследователь, который даёт задания, наблюдает за ходом их выполнения, задаёт уточняющие вопросы.

• Узнать новое о пользователях, обогатить сценарии.
• Проверить гипотезы об основных сценариях и способах решения задачи.
• Получить обратную связь пользователей об интерфейсе: помогает ли решать их задачи, насколько эффективно, есть ли трудности и на что они влияют.
• Посмотреть на контекст работы пользователя: рабочее место, обстановку, программы и предметы.
• Услышать слова и увидеть эмоции человека. Какие темы выделяет эмоционально? Какие использует слова во время работы с интерфейсом, что важно?

• Добавляется новый сценарий для пользователя (новая функция в продукте или новый продукт).
• Меняется привычный способ или логика работы пользователя.

Как и в любом исследовании, сначала важно сформулировать гипотезы для проверки и вопросы, на которые нужны ответы:

• Гипотеза. Есть трудность или проблема при работе в интерфейсе с... Кажется, что пользователям будет полезна новая функциональность в придуманном решении. Для проверки этой гипотезы смотрим на то, как пользователь работает с новой функциональностью во время ЮТ, что рассказывает про свой актуальный сценарий.
  Узнаём качественную информацию о том, есть ли у пользователя в принципе такая задача. Если да, то всё ли мы учли в придуманном для неё решении.
• Вопросы: как работают пользователи в интерфейсе или с его частью, что важно и почему, всё ли мы учли в нём для задач пользователя.
  

Включает в себя легенду, задание-инструкцию, шаги тестируемого сценария с вопросами. Сценарий нужен, чтобы ничего не забыть и получить обратную связь по всем интересующим частям системы от всех пользователей. Можно воспринимать его как чек-лист и место, где можно делать для себя пометки в ходе тестирования (что ещё уточнить, куда вернуться позже).

Её цель — погрузить респондента в ситуацию, помочь лучше понять, что будет происходить. Здесь важно идти от потребности пользователя, а не от функциональности системы.

В нём говорится, какую задачу сейчас нужно выполнить пользователю в сервисе.

• Смоделировать ситуацию: «Представьте, что вы А. А. Тыковка».
• Оттолкнуться от опыта пользователя: «Когда вы последний раз делали это?».
  
• Предоставить свободу действий: «Действуйте, как обычно вы работаете в системе».

При прописывании шагов сценария важно помнить: если пишем этот шаг, значит, важно у пользователя узнать об этой части интерфейса:

• Что думает, комментарий.
• Сценарий работы.
• Посмотреть, как будет действовать пользователь.

Два пути, где их можно прописать в сценарии и когда задать:

• Прописать открытые ненаводящие вопросы, которые задаются перед ЮТ (например, чтобы лучше понять текущий сценарий пользователя, как он работает сейчас). Подробнее о том, как правильно задавать вопросы и проверить свою гипотезу, — в материале о проблемных интервью.
• Под каждым шагом сценария заранее прописать уточняющие вопросы, чтобы сразу уточнить их в контексте.

Важно помнить, что лучше не увлекаться вопросами во время ЮТ. Самое ценное в таком тестировании — наблюдать, как пользователь работает в интерфейсе, а не провести интервью. Интервью лучше оставить на начало или конец ЮТ в качестве отдельного блока, помогающего установить или завершить контакт с респондентом.

После того как понятны цель и гипотезы для проверки во время тестирования, прописаны сценарий и вопросы, приходит время продумать, где мы будем наблюдать за действиями пользователя.

Для тестирования подходит прототип любой степени детализации:

• Работа с самим сервисом. В таком случае надо заранее подготовить тестовую площадку, на которой будет работать пользователь, или договориться с ним о ЮТ с его компьютера и под его учётной записью.
• Кликабельный прототип, сделанный в InVision или Figmа. В нём необязательно прорисовывать всё от и до, как это работает в живой системе. Достаточно основного сценария, чтобы были кликабельны именно те части, которые важно проверить.
  В этом случае можно предупредить пользователя, что это набор картинок. В них нажимается не всё, и это нормально. Если он начнёт работать с какой-то частью интерфейса и ничего не произойдёт, то пусть просто прокомментирует, что он хотел сделать.
• Бумажный прототип тоже подойдёт, если на его «экранах» можно выполнить осмысленную для пользователя задачу. Хорошо подходит для проверки скорее идеи о решении, чем для удобства работы с конкретным интерфейсом. Прототип в этом случае сделан настолько абстрактно, что пользователь не отвлекается на дизайн и особенности реализации, а обсуждает саму предложенную идею и насколько она вписывается в его текущую реальность.

Это важная часть, поскольку от того, какие ожидания сформируются у пользователя при приглашении, будет зависеть, насколько он будет лоялен и готов к ЮТ.

Здесь есть риск быть неверно понятым, и пользователь может решить, что под тестированием системы имеется в виду предоставление бесплатной тестовой версии или продажа дополнительной функциональности с дальнейшей демонстрацией и объяснением, как это работает.

Поэтому важно рассказать, в чём суть ЮТ для пользователя, и расставить нужные акценты во время приглашения.

• Цель звонка — зачем приглашаем именно этого пользователя на ЮТ. Цель должна быть понятна для него.
• Откуда контакт.
  
• Мотивация. Показать, как ценен и важен пользователь для исследования. Что он как эксперт в своей работе может дать ценную обратную связь для продукта.
  
• Обозначить, сколько займёт времени. В среднем ЮТ идёт минут 30. Дольше часа не имеет смысла проводить. Все устанут.
  
• Рассказать, что потребуется в процессе встречи, какие варианты места встречи есть.
  
• Обдумать, как работать с возражениями (например, «ой, да я вряд ли буду вам полезна», «мне некогда», «мне это неинтересно»).
  
• Предупредить о наблюдателях, если они будут.
  

Обязательно стоит сказать о том, что нет правильных или неправильных ответов респондента, подчеркнуть, что вы тестируете не его, а продукт или сервис.

Обычно говорим, что эта информация нужна нам для внутреннего использования и будет анализироваться в обобщённом виде.

Главное во время ЮТ — не подсказывать, не наводить на желаемые ответы пользователя. Действует правило «со всеми всё хорошо».

Яркие эмоции могут вывести респондента из контакта, и он начнёт давать приятные и желательные для модератора, но уже не совсем честные ответы, которые потом нельзя будет взять в работу и по которым нельзя будет делать выводы.

Если нет уверенности, что получится удержаться от подсказок, лучше просто молча наблюдать и сохранять покер-фейс. А все вопросы и эмоции во время тестирования фиксировать на бумаге. Так будет проще справиться с эмоциями. Что-то потом можно будет уточнить у пользователя, а что-то оставить на обсуждение с командой.

Когда проведено исследование, остаётся последний этап — фиксация и анализ результатов. Структурировать результаты ЮТ можно так:

1. Шаг из сценария.
2. Сценарий — что хотел сделать пользователь.
3. Факт — почему у него не получилось или что не так в интерфейсе, как это проявилось во время ЮТ.
4. Последствия — что будет, если оставить так, или почему это проблема.

После анализа результатов важно сформировать выводы и рекомендации по изменению интерфейса, выделить критичные проблемы и рассказать команде о «болях» или радостях пользователей, смотреть, как вносятся правки, и продолжать собирать обратную связь от пользователей.

#юзабилити #обратнаясвязь