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

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

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

В чем суть

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн в Контуре

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

Эмилия Городовых

Written by

UX-исследователь в СКБ Контур

Дизайн в Контуре

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

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade