Как проверить удобство одного сценария без большого исследования

Задача без подсказанной кнопки

Вместо "нажмите календарь и выберите время" предлагаю ситуацию: "Вы хотите записаться на следующую неделю. Найдите подходящий вариант". Если подсказать нужную кнопку, можно не заметить, что её невозможно найти без помощи.

GOV.UK описывает модерируемый тест как наблюдение за выполнением задач в сервисе. Я заранее готовлю цель, начало, критерий завершения и вопросы после попытки. Участник должен понимать, что проверяют продукт, а не его способности.

Момент затруднения и помощь

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

Если тест идёт на прототипе, заранее перечисляю ограничения. Неработающий поиск в макете не позволяет оценить поведение настоящего поиска. В то же время непонятное название кнопки можно исследовать и без готовой серверной части.

Протокол одной попытки

Учебное задание: "Вам нужна консультация на следующей неделе. Выберите подходящий вариант и узнайте, как подтвердить запись". До начала модератор отмечает стартовый экран, доступные данные и критерий завершения. Если прототип не отправляет заявку, задача заканчивается там, где можно осмысленно проверить понимание, а не на вымышленном серверном успехе.

1. Во время прохождения: время и экран, действие участника, его ожидание, ответ интерфейса. Укажите, смог ли он восстановиться самостоятельно.
2. При паузе: нейтральное "О чём вы сейчас думаете?" вместо "Вы заметили кнопку справа?". Помощь фиксируется как вмешательство.
3. После попытки: спросите, каким участник считает результат и на основании чего. Это проверяет понимание подтверждения.
4. Для команды: препятствие, подтверждающий фрагмент, ограничение теста, возможное изменение и способ повторной проверки.

В учебном примере участник нажал кнопку, а затем искал письмо, потому что экран не объяснял статус. Можно проверить текст подтверждения и переход к деталям записи. Пока сервер в прототипе отсутствует, нельзя утверждать, что потеряно письмо или сама заявка.

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

Границы малой выборки

В условном примере, если три участника из пяти не нашли подтверждение, я не пишу, что "60% клиентов потеряны". Это наблюдение в конкретной группе. Nielsen Norman Group разделяет качественные и количественные задачи: небольшой тест помогает выявлять проблемы, но для измерения долей нужна другая постановка исследования.

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

Результат для следующей доработки

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

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