Задача описывает намерение человека
Представим учебный сервис бронирования комнаты для встреч. Нужно выбрать помещение на четверг для небольшой группы. Задание может содержать число участников, желаемое время и необходимость экрана. Однако перечисление пунктов меню и названий фильтров уже подсказывает решение. Реалистичный сценарий задаёт условия, которые человек знал бы вне интерфейса. Отдельно полезно определить исследовательский вопрос: например, понимает ли участник, как найти комнату с нужным оснащением. Слишком общая просьба оценить сайт не показывает, какую трудность вы собираетесь наблюдать.
Успех определите до начала проверки
В нашем примере результатом считается выбор комнаты, которая подходит по вместимости, времени и наличию экрана. Красивое впечатление от страницы не заменяет выполнения этих условий. До проверки нужно решить, что будет означать самостоятельное завершение и как отметить помощь исследователя. Если участник нашёл подходящую комнату только после прямой подсказки, это важный результат, но его нельзя записывать так же, как полностью самостоятельное действие. Также полезно сохранять различие между наблюдением и объяснением: долгое рассматривание фильтра видно, а причина задержки требует уточнения.
Наблюдайте за сервисом, не оценивайте человека
Проверка прототипа предназначена для поиска затруднений в продукте. Ошибку участника не следует сразу объяснять невнимательностью или недостатком способностей. Можно попросить его рассказать, что он ожидал увидеть после действия. В учебной ситуации человек нажал на изображение комнаты, предполагая открыть описание, но перехода не произошло. Это даёт конкретный вопрос к поведению элемента. Одного случая недостаточно для вывода о частоте проблемы среди всей аудитории, однако он помогает сформулировать гипотезу для следующей проверки. Если исследование проводится с людьми, заранее объясняют его цель и согласуют запись, когда она нужна.
Попробуйте на практике
Подготовьте бумажный сценарий проверки вымышленного сервиса комнат. Реальные пользователи, персональные данные и бронирование не требуются.
- Опишите задачу участника: встреча небольшой группы в четверг, нужен экран и определённое время. Укажите только сведения, которые человек мог бы знать до открытия сервиса, без названий кнопок.
- Запишите три условия успешного результата и отдельный признак помощи. Например, исследователь назвал нужный раздел после затруднения. Не смешивайте выполненную задачу с положительным отзывом о внешнем виде.
- Создайте две условные записи наблюдений. В первой участник самостоятельно нашёл подходящую комнату, во второй выбрал неподходящую по оснащению и исправился после подсказки. Опишите различие без оценки личности.
- Сформулируйте один вопрос для уточнения ожиданий и одну гипотезу изменения интерфейса. Укажите, какое последующее наблюдение поможет проверить гипотезу, вместо заявления, что решение уже доказало эффективность.
Как проверить результат. Сценарий содержит цель без подсказанного пути, заранее определённый успех и отдельный учёт помощи. Наблюдаемые действия отделены от догадок, а вывод не распространён на всю аудиторию по одному случаю.
Частые вопросы
Можно помогать участнику, если он надолго застрял?
Да, если это предусмотрено ходом исследования. Важно отметить момент и содержание помощи, чтобы не потерять сведения о самостоятельной проходимости задачи и не исказить итог.
Нужно проверять только готовый сайт?
Нет. Подходящие задачи можно исследовать и на прототипе. При этом учитывают его ограничения: отсутствие работающего перехода в макете не всегда означает такую же проблему будущего продукта.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.