Как провести модерируемое юзабилити-тестирование: практическое руководство с AI-промптами

Компания в сфере e-commerce переработала мобильный поток оформления заказа, чтобы снизить долю брошенных корзин — она составляла 72%. Продуктовая команда была уверена, что новый дизайн лучше: вместо прежних пяти шагов оформление уместилось на одной прокручиваемой странице. Перед запуском UX-исследовательская команда провела модерируемые юзабилити-тесты с 6 пользователями смартфонов — каждого просили добавить товар в корзину, применить промокод и завершить покупку.

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

Команда внесла два изменения по результатам теста: переместила поле для промокода выше строки с суммой заказа — так оно появлялось до итоговой суммы — и добавила встроенное подтверждение, которое сразу показывало размер скидки и обновлённую сумму после ввода кода. Повторное немодерируемое тестирование с 50 пользователями показало: применение промокодов выросло с 12% до 31%, а завершаемость оформления — с 28% до 41%. Модерируемый тест занял одну неделю; полученный инсайт не всплыл бы ни в аналитике, ни в немодерируемом тестировании — потому что корневая причина (позиционирование поля при прокрутке в сочетании с отсутствием визуальной обратной связи) требовала наблюдения за реальными пользователями и вопроса «что вы ожидали увидеть?»

Вот что даёт модерируемое юзабилити-тестирование: не просто факт того, справились ли пользователи с задачей, а понимание того, почему они справились, столкнулись с трудностями или потерпели неудачу — и что именно в дизайне нужно изменить.

Что такое модерируемое юзабилити-тестирование

Модерируемое юзабилити-тестирование (Usability Testing — Moderated) — метод исследования, при котором фасилитатор наблюдает за участниками, выполняющими конкретные задачи с продуктом или прототипом, и задаёт уточняющие вопросы в режиме реального времени, чтобы понять, почему участники справляются, испытывают затруднения или терпят неудачу. В отличие от немодерируемого тестирования, присутствие фасилитатора позволяет заглянуть глубже за поверхностное поведение — уловить момент, когда пользователь колеблется, неверно трактует подпись или выбирается из ошибки — и превратить эти наблюдения в конкретные выводы об устройстве интерфейса, информационной архитектуре и паттернах взаимодействия.

Какие вопросы он отвечает

Модерируемое юзабилити-тестирование отвечает на вопросы о том, могут ли пользователи достичь своих целей с помощью продукта:

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

Когда применять

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

Метод не подходит, когда команде нужны крупновыборочные количественные данные (завершаемость, время выполнения у 100+ пользователей) — для этого немодерируемое тестирование быстрее и дешевле. Также не подходит, когда нет прототипа или продукта для взаимодействия: если вопрос звучит как «хотят ли пользователи этого?», а не «могут ли они этим пользоваться?», лучше подойдёт концептуальное тестирование. Модерируемое юзабилити-тестирование требует квалифицированного фасилитатора, выделенного времени на каждого участника и более высоких вознаграждений, чем немодерируемые тесты, — поэтому его стоит приберечь для ситуаций, где глубина качественных данных оправдывает затраты.

Что вы получаете (артефакты)

Отчёт о юзабилити-находках: приоритизированный список проблем, каждая с оценкой критичности (критическая, умеренная, низкая), частотой (сколько участников с ней столкнулось), описанием произошедшего и скриншотом или видеоклипом, иллюстрирующим проблему.
Данные о завершении задач: бинарный результат (успех/неудача) для каждой задачи плюс фиксация частичного завершения (выполнено с ошибками, выполнено с помощью, задача брошена).
Замеры времени на задачу: сколько каждый участник тратил на каждую задачу, с отметкой задач, где время значительно превышало ожидания.
Оценки после задачи и после сессии: баллы Single Ease Question (SEQ) по каждой задаче и баллы System Usability Scale (SUS) или SUPR-Q за общее впечатление.
Хайлайт-рил: короткая видеонарезка (5–10 минут) из наиболее показательных юзабилити-неудач и удач — для презентаций стейкхолдерам.
Рекомендации по дизайну: конкретные, действенные изменения, привязанные к каждой находке — не просто «починить навигацию», а «переместить кнопку “Сохранить черновик” из вспомогательного меню на основную панель инструментов, потому что 4 из 5 участников её не нашли».

Участники и сроки

Участники: 5–8 на каждый раунд тестирования. Исследования NNGroup показывают, что 5 пользователей выявляют примерно 80% юзабилити-проблем для заданного набора задач и профиля пользователя. Протестируйте с 5, исправьте критические проблемы, затем протестируйте снова с 5 новыми участниками — чтобы проверить, что исправления работают, и поймать оставшиеся проблемы. Если тестируете несколько пользовательских сегментов (например, новички против экспертов), рекрутируйте по 5 на каждый сегмент.

Длительность сессии: 45–60 минут на участника. Закладывайте 10 минут на знакомство и установление контакта, 25–35 минут на задачи и 10 минут на вопросы по итогам сессии и завершение.

Подготовка фасилитатора: 1–2 дня на написание плана теста, создание задач и подготовку прототипа. Плюс полдня на пилотную сессию с 1–2 внутренними участниками.

Анализ и отчётность: 2–3 дня на просмотр записей, кодирование находок, оценку критичности и написание отчёта.

Общий срок: 1–2 недели (подготовка: 2–3 дня; рекрутинг: 2–3 дня параллельно; тестирование: 2–3 дня на 5–8 сессий; анализ и отчёт: 2–3 дня).

Как провести модерируемый юзабилити-тест: шаг за шагом

1. Определите исследовательские вопросы и критерии успеха

Начните с решений, которые должен информировать тест. «Могут ли пользователи завершить поток оформления заказа?» — слишком широко. «Могут ли пользователи найти поле для промокода, применить скидку и убедиться, что итоговая сумма обновилась?» — проверяемо. Для каждой задачи определите, как выглядит успех (пользователь попадает на экран подтверждения с правильной суммой) и как выглядит неудача (пользователь отказался от задачи, использовал не то поле или не заметил применения скидки). Установите порог: если менее 4 из 5 участников выполняют задачу без помощи — дизайн нуждается в доработке.

2. Напишите реалистичные сценарии задач

Напишите 3–6 сценариев задач, охватывающих наиболее важные пользовательские пути. Формулируйте каждую задачу как реалистичную ситуацию, а не инструкцию: «Вы купили куртку онлайн на прошлой неделе, но она не подошла по размеру. Узнайте, как её вернуть, и начните этот процесс» — вместо «Нажмите на “Возвраты” и заполните форму». Не используйте слова из интерфейса в описании задачи: если на кнопке написано «Возвраты и обмены», не употребляйте слово «вернуть» в сценарии. Это исключает подсказку, которой у реального пользователя не будет.

3. Подготовьте прототип и тестовую среду

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

4. Рекрутируйте репрезентативных участников

Рекрутируйте 5–8 участников, соответствующих целевым пользователям продукта по предметному опыту, техническому уровню и контексту использования. B2B-инструмент для выставления счетов следует тестировать с людьми, которые реально работают со счетами, а не со студентами дизайна. Используйте скрининговый опросник для отбора по релевантному опыту. Рекрутируйте с запасом 20% на случай неявки: если нужно 5, запишите 6. Предлагайте соответствующее вознаграждение (как правило, 75–150 долларов в час для потребительских продуктов, выше для специализированных B2B-пользователей).

5. Проведите сессию

Начните с 5–10 минут установления контакта. Объясните процесс: «Мы тестируем продукт, а не вас. Неправильных ответов не существует. Если что-то непонятно — это вина продукта, а не ваша». Попросите участника думать вслух в процессе работы с каждой задачей — проговаривать, что он видит, что ожидает и что пытается сделать. Если участник замолкает, мягко спросите: «Что сейчас у вас в голове?» или «Что вы ищете?» Не помогайте, не намекайте и не реагируйте эмоционально на действия участника. Если участник спрашивает «Я правильно делаю?» — ответьте: «А что бы вы сделали, если бы меня здесь не было?» Записывайте и экран, и аудио.

6. Задавайте уточняющие вопросы между задачами, а не во время них

После каждой задачи просите участника поразмышлять: «Как вам это далось?», «Что вы ожидали произойдёт, когда нажали на это?», «Было ли что-то непонятным?» Используйте Single Ease Question (SEQ): «По шкале от 1 до 7, насколько лёгкой или трудной была эта задача?» Эта техника ретроспективного зондирования, рекомендованная MeasuringU, не прерывает естественный ход работы с задачей и фиксирует рассуждения участника, пока впечатления ещё свежи.

7. Завершите общими впечатлениями

Оставьте последние 10 минут для вопросов «с высоты птичьего полёта»: «Как вам общее впечатление?», «Что было самым непонятным?», «Как это сравнивается с тем, чем вы пользуетесь сейчас?», «Стали бы вы пользоваться этим продуктом? Почему?» Предложите стандартизированный опросник — SUS для программных продуктов, SUPR-Q для сайтов — чтобы получить сопоставимую общую оценку юзабилити. Поблагодарите участника и оперативно выплатите вознаграждение.

8. Проведите дебриф сразу после каждой сессии

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

9. Проанализируйте находки и оцените критичность

После завершения всех сессий просмотрите записи и заметки, чтобы составить список юзабилити-находок. Для каждой находки зафиксируйте: что произошло, сколько участников с этим столкнулось, критичность (критическая — блокирует выполнение задачи; умеренная — создаёт трудности, но не мешает выполнению; низкая — незначительное трение) и скриншот или видеоклип. Сгруппируйте находки по области (навигация, формы, подписи, обратная связь) и расставьте приоритеты по критичности и частоте. Проблема, с которой столкнулись 4 из 5 участников при критическом уровне, — приоритет номер один.

10. Пишите отчёт с доказательствами и рекомендациями

Напишите отчёт, который начинается с приоритетных находок — каждая сопровождается скриншотом или видеоклипом и конкретной дизайн-рекомендацией. Не прячьте находки в 50-страничном документе: стейкхолдеры его не прочитают. Подготовьте одностраничное резюме из 3–5 наиболее критичных находок, подробную таблицу находок для команды дизайна и хайлайт-рил на 5–10 минут для презентаций стейкхолдерам. Организуйте встречу для обсуждения находок, где команда дизайна вместе смотрит ключевые клипы и обсуждает решения.

Как AI меняет этот метод

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

Что умеет AI

Транскрибирование в реальном времени: инструменты вроде Otter.ai, Grain или Looppanel расшифровывают сессии по мере их проведения, освобождая нотера для наблюдений, а не дословной записи.
Генерация резюме сессий: после каждой сессии LLM может обработать транскрипт и выдать структурированное резюме — выполненные задачи, статус завершения, ключевые цитаты и зоны путаницы — сокращая послесессионный дебриф с 30 минут до 10 минут проверки и корректировки.
Выявление паттернов между сессиями: получив транскрипты всех сессий, AI может определить, какие проблемы встречались у нескольких участников, какие элементы интерфейса вызвали больше всего негативных комментариев и у каких задач наибольший разброс времени выполнения.
Подбор клипов для хайлайт-рила: AI-инструменты вроде Grain и Looppanel умеют отмечать в записях моменты, когда участники выражали замешательство, раздражение или удивление, — позволяя исследователю собрать хайлайт-рил за несколько минут вместо пересмотра часов видео.
Черновик отчёта: LLM может сгенерировать первый вариант отчёта о находках на основе структурированных заметок по сессиям — перечислив каждую находку с критичностью, частотой и подтверждающими цитатами — который исследователь затем дорабатывает, добавляет скриншоты и адаптирует под аудиторию.

Что остаётся за человеком-исследователем

Проведение сессии: фасилитатор должен выстраивать контакт, считывать язык тела и интонации участника, в реальном времени решать, какую нить тянуть дальше, и соблюдать тонкий баланс между тем, чтобы побуждать участника думать вслух, и тем, чтобы не направлять его к конкретному действию. Это требует социального интеллекта и ситуативного суждения, недоступных AI.
Решение о том, когда и как зондировать: когда участник задерживается на экране три секунды, фасилитатор решает — подождать (участник, возможно, читает) или спросить (участник, возможно, потерялся). Это суждение зависит от контекста: что участник говорил 30 секунд назад, каков его общий уровень навыков и чего требует задача. Ни одна автоматизированная система не способна принять это решение.
Оценка критичности и приоритизация находок: является ли юзабилити-проблема критической, умеренной или незначительной — зависит от факторов, недоступных AI: от того, как задача вписывается в более широкий пользовательский путь, как часто реальные пользователи будут сталкиваться с этим сценарием и каковы бизнес-издержки неудачи. Находка, при которой 3 из 5 участников пропустили кнопку, может быть критической (если кнопка ведёт к единственному способу отменить подписку) или незначительной (если есть альтернативный путь). Это суждение требует предметных знаний и опыта в дизайне.
Формулировка действенных рекомендаций: превратить «4 участника не увидели кнопку “Сохранить”» в «перенести кнопку “Сохранить” из вспомогательного меню на основную панель инструментов, сделать её заливной вместо контурной и добавить всплывающее подтверждение после сохранения» — значит применить знания дизайна, выходящие за рамки того, что данные могут дать сами по себе.

Рабочий процесс с AI

Наибольшая экономия времени — в работе после сессии. Традиционно исследователь тратит 30–60 минут после каждой сессии на проверку заметок, простановку временных меток на ключевых моментах и написание резюме. С AI-транскриптами и резюме исследователь проверяет и исправляет черновик за 10–15 минут — снижение послесессионных трудозатрат на 60–70%. На 5–8 сессий это экономит полный рабочий день.

Фаза анализа тоже ускоряется. Вместо того чтобы перечитывать 5–8 транскриптов в поисках повторяющихся находок, исследователь загружает все транскрипты в LLM, который выявляет паттерны: «4 из 5 участников не смогли найти ссылку на политику возврата; 3 из 5 описали поток оформления как “непонятный” или “слишком много шагов”; слово “скидка” встречается в вопросах участников во всех сессиях, тогда как интерфейс использует “промокод”». Этот межсессионный синтез, который традиционно занимает 4–6 часов повторного чтения транскриптов, AI выдаёт за минуты, а исследователь проверяет за час.

Само проведение сессий остаётся полностью в руках человека. Ни один AI-инструмент не меняет то, как ведётся сессия: исследователь по-прежнему сидит рядом с участником, наблюдает за его экраном и задаёт уточняющие вопросы в реальном времени. Роль AI начинается, когда сессия заканчивается: транскрибирование, создание резюме, поиск паттернов, черновик отчёта. Роль исследователя смещается от механической пост-обработки (ввод заметок, пересмотр видео, составление списков) к интерпретационной работе (оценка критичности, формулировка рекомендаций, определение приоритетов).

Хорошо сочетается с

Юзабилити-тестирование — немодерируемое (Unmoderated Usability Testing): модерируемые тесты выявляют проблемы и объясняют их причины; немодерируемые тесты показывают, как часто эти проблемы встречаются на большей выборке. Сначала проводите модерируемые для обнаружения, затем немодерируемые для измерения.
Концептуальное тестирование (Concept Testing): концептуальное тестирование проверяет, хотят ли пользователи продукт; модерируемое юзабилити-тестирование проверяет, могут ли они им пользоваться. Сначала концептуальные тесты (стоит ли это строить?), потом юзабилити-тесты (могут ли люди пользоваться тем, что мы построили?).
Глубинное интервью (In-depth Interview): вопросы в начале и конце модерируемой юзабилити-сессии функционируют как короткое интервью. Для более глубокого изучения потребностей пользователей проведите отдельное интервью до юзабилити-теста — чтобы понять контекст, а затем использовать эти инсайты для создания более точных сценариев задач.
Экспертная оценка (Heuristic Evaluation): экспертная оценка эвристик выявляет предсказуемые юзабилити-проблемы до тестирования с реальными пользователями, сокращая количество очевидных проблем, с которыми сталкиваются участники, и позволяя сосредоточить тест на менее предсказуемых проблемах, которые обнаруживают только реальные пользователи.
Карта пути пользователя (Journey Mapping): карты пути выявляют, какие этапы пользовательского опыта содержат больше всего болевых точек; модерируемые юзабилити-тесты масштабируются на эти конкретные этапы, чтобы наблюдать, где именно и почему возникает трение.

Пример из практики

Ошибки начинающих

Помогать участнику

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

Задавать наводящие вопросы

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

Включать слишком много задач в одну сессию

Начинающие упаковывают 8–10 задач в 60-минутную сессию, не оставляя времени на зондирование и осмысление. Участник торопится, фасилитатор пропускает уточняющие вопросы — данные получаются поверхностными. Три-шесть тщательно выбранных задач с полноценным зондированием дадут более богатые находки, чем десять задач, пройденных в поверхностном темпе. Каждая задача требует времени на попытку, на выход из ошибки и на ретроспективное обсуждение.

Использовать язык интерфейса в описаниях задач

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

Не тестировать итеративно

Провести один раунд из 10 тестов, написать большой отчёт и больше не перетестировать — распространённый, но расточительный подход. Эффективнее итеративный: протестируйте с 5 пользователями, исправьте критические проблемы, затем протестируйте снова с 5 новыми участниками — убедитесь, что исправления сработали, и поймайте проблемы, скрывавшиеся за более крупными. Два раунда по 5 дают лучший результат, чем один раунд из 10.

AI-промпты для этого метода

4 готовых AI-промптов с placeholder’ами — скопируйте и подставьте свой контекст. Все промпты для «модерируемого юзабилити-тестирования» →.