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

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

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

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

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

Содержание:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 комментария

Роман Казаков

10.09.2019

Привет. Спасибо. Мы проводим очно и удалённо похожие тесты, также используем Figma для прототипов. Но работаем в основном с коллегами, новичкам, редкий раз с клиентами и студентами. Поделитесь своим опытом, откуда вы берёте клиентов на тесты? Какие каналы рабочие, какие не очень?

Ответить