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

К UX-исследователям в СКБ Контур часто приходят с запросом проверить решение — будет ли оно понятно пользователям, все ли учтено. Обычно это происходит на этапе, когда командой уже собрана аналитика и придумывается/проектируется что-то новое; либо когда уже есть действующий сервис.

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

Так и появилась эта небольшая шпаргалка, для тех кто только начал сам проверять свои решения и хочет делать это хорошо.

В чем суть

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

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

Зачем проводить

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

Критерии, что ЮТ нужно

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

Как подготовиться

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

Например:

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

Вопросы. Как работают пользователи в интерфейсе/с его частью? Что важно и почему? Все ли мы учли в нем для задач пользователя?

Прописать сценарий для тестирования

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

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

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

Смоделировать ситуацию (“Представьте, что вы Тыковка А.А.”)

Оттолкнуться от опыта пользователя (“Когда вы последний раз делали это?”)

Предоставить свободу действий (“Действуйте как обычно вы работаете в системе”).

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

• что думает, комментарий
• сценарий работы
• посмотреть как будет действовать

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

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

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

Подготовить прототипы

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

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

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

Как пригласить пользователей

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

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

•Цель звонка, зачем приглашаем именно этого пользователя на ЮТ. Цель должна быть понятна для него.

•Откуда контакт

•Мотивация. Показать, как ценен и важен пользователь для исследования. Что он как эксперт в своей работе, может дать ценную обратную связь для продукта.

•Обозначить, сколько займет времени. В среднем ЮТ идет минут 30. Дольше 1 часа не имеет смысла проводить. Все устанут.

•Рассказать, что потребуется в процессе встречи, какие варианты места встречи есть.

•Обдумать, как работать с возражениями (например, “ой, да я вряд ли буду вам полезна”, “мне некогда”, “мне это не интересно”).

•Предупредить о наблюдателях, если они будут.

Как провести ЮТ

Рассказать кто ты, что будет происходить.

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

Пример вводной инструкции

Предупредить о записи на камеру/диктофон.

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

Сесть, расслабиться и наблюдать.

Главное во время ЮТ — не подсказывать, не наводить на желаемые ответы пользователя. Действует правило «со всеми всё ОК». Яркие эмоции могут вывести респондента из контакта и он начнет давать приятные и желательные для модератора, но уже не совсем честные ответы, которые потом нельзя будет взять в работу и делать по ним выводы.

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

Анализ результатов

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

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

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

️