Вопросы и шаблоны · 22 сентября 2026 г.

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

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

Сценарий против прямой инструкции

Прямая инструкция называет элемент интерфейса и действие с ним: «нажмите на кнопку „Добавить в корзину“». Участник просто выполняет команду, и вы узнаёте только одно — видна ли кнопка физически на экране. Сценарий описывает цель пользователя без упоминания конкретных элементов интерфейса: «вы выбрали товар, который хотите купить, — сделайте следующий шаг, чтобы его получить». Здесь участнику приходится самому понять, как достичь цели, и именно в этот момент видно, находит ли он путь интуитивно или теряется — то есть проявляется реальная проблема или её отсутствие.

Разница особенно заметна на результатах. Задание-инструкция почти всегда даёт стопроцентный успех — участник просто ищет глазами названный элемент и нажимает на него, потому что вы сами сказали, что нажимать. Задание-сценарий может провалить половина участников, если путь к цели неочевиден, и именно эта информация ценна: она показывает, что реальный пользователь без подсказки застрянет точно так же. Юзабилити-тест с одними инструкциями формально проходит гладко и создаёт ложное ощущение, что с продуктом всё в порядке, хотя на самом деле проверялась не находимость решения, а просто грамотность чтения.

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

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

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

Разберём условный пример, чтобы показать разницу на практике. Пусть тестируют функцию экспорта отчёта из аналитической панели. Формулировка-инструкция звучит так: «нажмите на иконку выгрузки в правом верхнем углу таблицы и выберите формат CSV» — участник просто ищет названную иконку и почти наверняка справляется, потому что решение уже названо. Формулировка-сценарий звучит иначе: «вам нужно передать данные из этого отчёта коллеге, у которого нет доступа к системе, — сделайте это». Здесь участник сам решает, что нужно что-то выгрузить, сам ищет способ это сделать, и может пойти неочевидным путём — например, попытаться скопировать таблицу вручную, потому что не заметил кнопку экспорта вовсе. Именно это расхождение и есть находка, ради которой стоит формулировать задания как сценарии, а не как инструкции. Цифры и детали в примере условные, реального отчёта здесь не было.

Как добавить реалистичный контекст

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

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

Сколько заданий давать на одну сессию

Практический ориентир — четыре-шесть заданий на сессию длительностью тридцать-сорок минут. Меньше — и вы не успеваете покрыть достаточно сценариев продукта за одну встречу с участником. Больше — и накапливается усталость: к пятому-шестому заданию участник начинает выполнять их быстрее и менее вдумчиво, лишь бы закончить сессию, а находки в конце теряют ту же надёжность, что и находки в начале. Если ключевых сценариев продукта заметно больше шести, лучше разбить их на две сессии с разными участниками, чем перегружать одного человека всем сразу.

• Четыре-шесть заданий — комфортный объём на сессию в тридцать-сорок минут.
• Первое задание должно быть самым простым — оно разогревает и снимает напряжение участника.
• Самые критичные для бизнеса сценарии ставьте вторым-третьим, пока внимание ещё свежее.
• Последнее задание может быть открытым: «сделайте с сайтом всё, что обычно делаете».
• Если сценариев больше шести, разделите их на две сессии, а не перегружайте одну.

В каком порядке располагать задания

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

1. Начните с самого простого и предсказуемого по успеху задания — это разминка перед основным тестом.
2. Поставьте ключевой для бизнеса сценарий вторым или третьим, пока внимание участника ещё свежее.
3. Разделяйте задания, которые логически идут подряд в реальном пути пользователя, короткой паузой между ними.
4. Оставьте один более сложный или редкий сценарий ближе к концу сессии, когда участник уже освоился.
5. Завершите сессию открытым вопросом или свободным заданием без жёсткой заранее заданной цели.

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

Как проверить формулировку до сессий

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

Типичные ошибки

• Называть элемент интерфейса напрямую вместо описания цели пользователя.
• Дословно повторять в задании текст, который уже есть в меню или на кнопке интерфейса.
• Указывать в задании порядок действий, который сам по себе является предметом проверки.
• Перегружать легенду лишними деталями, из-за которых участник путается в условии задачи, а не в самом продукте.
• Давать больше шести заданий подряд и получать усталые, менее достоверные ответы к концу сессии.
• Определять критерий успеха задания уже после того, как увидели реальное поведение участников.
• Ставить самый сложный и провальный сценарий первым, обескураживая участника прямо с начала сессии.
• Формулировать задание как просьбу оценить продукт вместо конкретной задачи на выполнение.

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

Ограничения

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

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

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

С чего начать

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