Как сформулировать задание для юзабилити-теста без подсказки решения

Проверяйте пользовательскую цель, а не знание названий в интерфейсе

Когда участнику говорят не задачу, а путь к ней, тест перестает показывать реальное поведение. Формулировка вроде «найдите раздел “Возврат и обмен”» проверяет не то, как человек обычно ищет условия возврата, а то, умеет ли он распознать подсказанный ярлык. Если раздел так и называется, вы почти встроили ответ в вопрос. Если называется иначе, вы создаете лишнюю трудность, которая не относится к пользовательской цели.

В модерируемом юзабилити-тесте полезно наблюдать, как человек выполняет конкретную задачу, и просить его проговаривать мысли вслух. Но сама задача должна быть нейтральной: с ясной целью, правдоподобной ситуацией и без намека на нужную кнопку, меню или формулировку. Тогда маршрут участника становится данными: куда он пошел первым, что ожидал увидеть, в какой момент усомнился. Для вопроса про возврат заказа цель звучит так: человеку нужно понять, можно ли вернуть заказ и на каких условиях.

Одна и та же цель, но две разные формулировки

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

Нейтральная версия лучше еще и потому, что она ближе к реальной мотивации. Пользователь не думает категориями «мне нужен раздел из футера». Он думает «мне нужно понять, вернут ли у меня товар». Поэтому в тесте полезнее задавать контекст и цель, а не термин из интерфейса. Если задача звучит естественно, участник выбирает маршрут так, как сделал бы это дома без исследователя рядом.

Отдельная деталь — речь модератора. После постановки задачи лучше замолчать и наблюдать. Если человек затруднился, вместо «поищите внизу страницы» подойдут нейтральные реплики: «Что вы сейчас ищете?», «Что ожидали увидеть здесь?», «Что заставило вас выбрать этот раздел?». Такие вопросы помогают понять логику, но не ведут к решению.

Критерий успеха должен быть наблюдаемым

Фраза «участник разобрался» слишком расплывчата. Для учебной сессии лучше заранее задать наблюдаемый критерий успеха. Например: участник без подсказки находит страницу или экран с условиями возврата, может показать, где именно эта информация расположена, и своими словами отвечает на вопрос по сценарию. Тогда вы оцениваете не только нахождение экрана, но и понимание содержания.

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

Заметки наблюдателя тоже лучше структурировать заранее, иначе после сессии останутся только общие впечатления. Минимальный шаблон может быть таким:

• стартовый экран и устройство;
• текст задачи, прочитанный участнику дословно;
• первый клик или первое действие;
• маршрут по шагам;
• места остановок и возвратов назад;
• реплики участника вроде «ожидал увидеть это в заказе»;
• нужна ли была помощь и какая именно;
• итог: успех, частичный успех или неуспех.

Такой шаблон полезен тем, что превращает сессию в проверяемый материал. После нее можно открыть протокол и увидеть не «участнику было неудобно», а конкретно: сначала искал условия внутри карточки заказа, затем в помощи, футер не рассматривал как место для политики возврата.

Учебный пример: условный тест задачи про возврат заказа

УЧЕБНЫЙ ПРИМЕР

Исходные данные: есть условный интернет-магазин одежды с мобильной версией сайта. Информацию о возврате можно найти двумя путями: через статью в центре помощи и через ссылку в футере. Цель учебной сессии — проверить не всю навигацию сайта, а качество формулировки задачи для юзабилити-теста. Для сессии задан таймбокс 3 минуты на задачу и один участник, похожий на обычного онлайн-покупателя. Это условный пример, а не вывод о реальной аудитории.

Сначала я составил ведущую версию: «Найдите раздел “Возврат и обмен” и скажите, можно ли вернуть заказ». По чек-листу она не подошла: содержит точное название раздела и подталкивает к поиску ярлыка. Затем я заменил ее на нейтральную: «Представьте, что вы получили заказ и хотите понять, можно ли его вернуть и на каких условиях. Покажите, где вы бы это проверили, и озвучьте вывод». Модератор прочитал задачу дословно и дальше не подсказывал маршрут.

Ход сессии получился таким. На 0:18 участник открыл личный кабинет, на 0:46 — список заказов, на 1:14 — карточку конкретного заказа, на 1:37 произнес: «Я ожидал увидеть возврат здесь», затем вернулся назад и открыл центр помощи. На 2:06 он нашел статью с условиями возврата и на 2:24 своими словами объяснил вывод по сценарию. По заранее заданному критерию это успех: нужная информация найдена без прямой подсказки, вывод озвучен, лимит 3 минуты не превышен.

Проверяемый результат здесь не в том, что «сайт хороший» или «люди всегда пойдут в помощь». Результат в другом: нейтральная формулировка позволила увидеть реальное ожидание участника — сначала искать условия внутри собственного заказа. Если бы в задаче фигурировал раздел «Возврат и обмен», эта учебная сессия могла бы скрыть именно этот момент, потому что внимание участника было бы направлено на совпадение слов в интерфейсе.

Что можно и нельзя выводить из одной учебной сессии

Одна учебная сессия полезна, чтобы заметить конкретную проблему постановки задачи или явный разрыв в ожиданиях пользователя. В нашем примере она показывает: при нейтральной формулировке участник сначала искал условия возврата в деталях заказа, а не в футере. Это уже материал для обсуждения с командой: там ли расположена информация, где ее ждут увидеть. Но из одной сессии нельзя делать широкий вывод вроде «все пользователи не видят футер» или «центр помощи работает плохо». Для этого нужны повторяющиеся наблюдения на нескольких похожих участниках и с одинаковой инструкцией.

Ограничение касается и самого сравнения формулировок. Если дать одному и тому же человеку сначала ведущую, а потом нейтральную задачу, вторая попытка будет искажена знакомством с интерфейсом. Поэтому в учебной практике безопаснее сначала проверить текст задачи по чек-листу, а уже затем проводить основную сессию с одной выбранной формулировкой. И только после нескольких повторов сравнивать паттерны: куда люди идут первыми, где застревают и какие слова используют для той же цели.

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

Если хотите отдельно потренировать этот навык, в сохраненном описании каталога курса «UX-дизайн. Создание usability в интерфейсах» упомянуты этапы исследования, форматы интервью, информационная архитектура, прототипирование и тема про методы тестирования в UX, включая практику проведения юзабилити-тестирования. Официальная страница школы в исходных данных недоступна, поэтому ориентироваться можно только на сохраненный фрагмент программы.