Отчёт по юзабилити-тестированию: как связать проблемы с записью
Как оформить результаты юзабилити-теста: наблюдение, контекст задания, последствия, приоритет и проверка изменения. Пример карточки проблемы и шаблон отчёта.
Отчёт начинается с наблюдений
Фраза «участнику не понравилась навигация» не объясняет, что исправлять. В записи может быть видно, что человек трижды открывал раздел оплаты, пытаясь найти возврат, а затем обратился за помощью. Это уже воспроизводимая проблема в определённом задании.
Сохраните условия теста: версия интерфейса, устройство, сценарий, критерий успешного выполнения и помощь модератора. Без них команда может принять затруднение в прототипе за ошибку действующего продукта или считать подсказанный результат самостоятельным успехом.
Превратите сессии в проверяемые находки
Разметьте важные эпизоды
По каждой сессии отметьте начало задания, затруднения, восстановление и итог. Сверяйте расшифровку с экранной записью: слова «я нажал» не всегда описывают фактический клик. Сохраняйте таймкоды до и после действия, чтобы читатель видел контекст.
Разделите факт и объяснение
В поле наблюдения записывайте действие и результат. В отдельном поле — предполагаемую причину. «Искал возврат в оплате» является наблюдением, а «название раздела непонятно» — гипотезой, которую можно проверить следующим вариантом интерфейса.
Сопоставьте похожие случаи
Объединяйте эпизоды только при одинаковой проблеме и сопоставимом сценарии. Укажите, у скольких участников её наблюдали и сколько выполняли это задание. Не переносите долю небольшой исследовательской группы на всю аудиторию продукта.
Определите действие и проверку
Оцените последствие: задача остановилась, потребовала помощи или завершилась с лишними шагами. Согласуйте приоритет с учётом контекста продукта. Для предлагаемого изменения запишите, по какому наблюдаемому результату следующего теста станет понятно, помогло ли оно.
Пользователь ищет возврат заказа
Ниже — вымышленный учебный пример. Имена, условия и результаты приведены только для объяснения метода.
Наверное, это в оплате. Нет, здесь только карта. Может, написать в поддержку? Я не вижу, где вернуть заказ.
Из одной реплики нельзя узнать, что происходило на экране. В учебном примере запись показывает два перехода в оплату и остановку задания до подсказки модератора. Это нужно включить в карточку вместе с указанием версии прототипа.
Предложение добавить ссылку в карточку заказа — возможный вариант, а не доказанное решение. Следующий тест проверит, сможет ли участник найти действие без помощи и понять, какой заказ возвращает.
| Поле | Пример записи | Зачем нужно |
|---|---|---|
| Контекст | Прототип А, возврат оплаченного заказа | Понять условия |
| Доказательство | Сессия U3, 08:15–09:02 | Проверить эпизод |
| Последствие | Продолжил только после подсказки | Оценить влияние |
| Следующее действие | Проверить размещение в заказе | Назначить проверку |
Карточка проблемы для отчёта
Сначала составьте карточки, затем соберите короткое резюме основных препятствий. Так выводы останутся связанными с материалом теста.
Краткое название проблемы: Версия / устройство / задание: Участник и таймкод: Наблюдаемое действие: Последствие для задачи: Была ли помощь модератора: Повторения в сопоставимых сессиях: Предполагаемая причина: Приоритет и его основание: Предлагаемое изменение: Как проверим результат:
Проверьте, можно ли действовать по отчёту
- Важную находку можно найти в записи.
- Понятно, завершено ли задание самостоятельно.
- Причина не выдана за прямое наблюдение.
- У предложения есть критерий повторной проверки.
Разберём детали
Нужен ли длинный видеоролик по каждой проблеме?
Нет. Достаточно точной ссылки или таймкода с необходимым контекстом, если команда имеет доступ к исходнику. Короткая нарезка не должна скрывать подсказку или изменение задания.
Можно ли сразу указать решение?
Да, как предложение команды с основанием и способом проверки. Не называйте его доказанным только потому, что участник предложил похожую кнопку.