Как составить сценарий удалённого немодерируемого UX-исследования

3 мин.
19749
Команда AskUsers
Команда AskUsers
12 августа 2026 • 3 мин.
Содержание

Как составить сценарий удалённого немодерируемого UX-исследования

Удалённое немодерируемое UX-исследование проходит без исследователя в реальном времени. Участник сам читает инструкции, выполняет задания на сайте или в приложении и отвечает на вопросы в исследовательском сервисе.

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

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

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

Из чего состоит сценарий

Хороший сценарий связывает цели бизнеса, исследовательские вопросы и действия участника. До написания заданий зафиксируйте три вещи.

1. Цель исследования

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

Фраза «проверить удобство сайта» слишком широкая. Она не подсказывает, кого приглашать, что показывать участникам и какие ответы считать полезными.

2. Исследовательские вопросы

Это вопросы команды, а не участника. Они задают направление анализа:
  • Находит ли пользователь нужный товар по заданному сценарию?
  • Какие сведения о товаре помогают принять решение?
  • Понимает ли пользователь, как добавить товар в корзину?
  • Какие поля и условия осложняют оформление?
  • Понятен ли способ оплаты при получении?
  • Что мешает завершить заказ?
Один исследовательский вопрос может проверяться несколькими заданиями. Например, понимание оплаты при доставке лучше проверять не только вопросом, но и выбором способа оплаты в форме заказа.

3. Путь участника

Опишите путь от входа до целевого действия. В нашем примере он выглядит так:
  1. Открыть сайт.
  2. Найти нужный товар.
  3. Изучить карточку товара.
  4. Выбрать характеристики.
  5. Добавить товар в корзину.
  6. Проверить состав заказа.
  7. Перейти к оформлению.
  8. Указать данные получателя.
  9. Выбрать доставку.
  10. Выбрать оплату при получении.
  11. Проверить заказ.
  12. Подтвердить оформление.
Сценарий не должен превращаться в инструкцию «нажмите сюда, затем сюда». Исследователю важно увидеть, как человек сам принимает решения. Поэтому формулируйте задания через цель, а не через конкретные элементы интерфейса.

Плохо: «Нажмите на раздел “Каталог”, введите в поиск “беспроводные наушники” и откройте первый товар».

Лучше: «Представьте, что вы хотите купить беспроводные наушники для работы и поездок. Найдите подходящий товар на сайте».

Пример сценария на одном кейсе

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

Для теста используйте учебный аккаунт или тестовую среду, чтобы не собирать реальные платёжные данные.

Ниже приведён сквозной сценарий из 23 заданий и открытых вопросов. Его можно адаптировать под конкретный сайт, категорию товара и способ доставки.

Вход и первый шаг

1. Задание: Откройте сайт интернет-магазина и осмотритесь, не переходя к оформлению заказа.
Открытый вопрос: Что вы ожидаете найти здесь в первую очередь и почему?

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

3. Задание: Если вы использовали поиск, фильтры или меню, расскажите, почему выбрали этот способ.
Открытый вопрос: Что в навигации помогло вам, а что пришлось искать?

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

Выбор товара

4. Задание: Изучите несколько вариантов и выберите товар, который вы бы рассмотрели для покупки.
Открытый вопрос: Какие сведения повлияли на ваш выбор?

5. Задание: Откройте карточку выбранного товара и найдите информацию, которая нужна перед покупкой.
Открытый вопрос: Какой информации вам не хватило или что оказалось непонятным?

6. Задание: Проверьте стоимость товара, срок доставки и доступные характеристики.
Открытый вопрос: Где вы искали эти сведения и насколько легко их нашли?

7. Задание: Если у товара есть варианты цвета, комплектации или размера, выберите подходящий.
Открытый вопрос: Как вы поняли, чем отличаются варианты?

Здесь лучше не перечислять характеристики, которые исследователь хочет проверить. Иначе участник начнёт искать именно их, а команда не увидит, что он выбрал бы самостоятельно.

Корзина

8. Задание: Добавьте выбранный товар в корзину.
Открытый вопрос: Что, по-вашему, должно произойти после добавления товара?

9. Задание: Откройте корзину и проверьте её содержимое.
Открытый вопрос: На что вы обратили внимание при проверке заказа?

10. Задание: Измените количество товара или удалите его, если считаете это нужным, а затем верните в корзину один подходящий вариант.
Открытый вопрос: Насколько понятными были действия с товаром в корзине?

11. Задание: Решите, готовы ли вы перейти к оформлению заказа.
Открытый вопрос: Что повлияло на ваше решение перейти дальше или остановиться?

Вопрос о решении важнее оценки «удобно / неудобно». Он помогает понять, какие сигналы пользователь считает достаточными для следующего шага.

Данные получателя и доставка

12. Задание: Перейдите к оформлению заказа и заполните данные так, как сделали бы это для доставки себе. Используйте тестовые данные, если это предусмотрено сценарием.
Открытый вопрос: Какие поля вызвали вопросы или потребовали дополнительного обдумывания?

13. Задание: Выберите способ доставки, который подходит для вашей ситуации.
Открытый вопрос: Как вы сравнивали варианты доставки?

14. Задание: Найдите стоимость и предполагаемый срок доставки.
Открытый вопрос: Насколько понятны эти условия? Что вы хотели бы уточнить?

15. Задание: Проверьте, можно ли изменить адрес или способ доставки до подтверждения заказа.
Открытый вопрос: В какой момент вы почувствовали, что данные заказа можно или нельзя изменить?

Этот блок проверяет не только наличие функций, но и ощущение контроля. Пользователь может видеть поле для адреса, но не понимать, применяется ли оно к текущему заказу.

Оплата при получении

16. Задание: Выберите оплату при получении заказа.
Открытый вопрос: Что вы ожидали увидеть после выбора этого способа оплаты?

17. Задание: Найдите информацию о том, когда и кому вы будете платить.
Открытый вопрос: Что для вас означает «оплата при получении» в этом заказе?

18. Задание: Проверьте, есть ли дополнительные условия или ограничения для этого способа оплаты.
Открытый вопрос: Какие условия показались важными перед подтверждением заказа?

19. Задание: Если система предлагает несколько вариантов оплаты при получении, выберите подходящий.
Открытый вопрос: Чем вы руководствовались при выборе?

Формулировка «что означает» позволяет проверить понимание своими словами. Не предлагайте варианты ответа: они могут подсказать нужную интерпретацию.

Проверка и завершение

20. Задание: Просмотрите весь заказ перед подтверждением.
Открытый вопрос: Что вы проверили в первую очередь и почему?

21. Задание: Найдите итоговую стоимость, стоимость доставки и выбранный способ оплаты.
Открытый вопрос: Какие суммы и условия вы считаете недостаточно ясными?

22. Задание: Если всё подходит, подтвердите заказ. Если вы не готовы это делать, остановитесь на последнем шаге и объясните почему.
Открытый вопрос: Что убедило вас завершить заказ или помешало это сделать?

23. Открытый вопрос после сценария: Если бы вы могли изменить одну вещь в процессе заказа, что бы вы изменили и почему?

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

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

Открытый вопрос не ограничивает ответ вариантами «да», «нет» или готовым списком причин. Он побуждает участника описать опыт своими словами.

Подходящие формулировки:
  • «Что вы ожидали увидеть после этого шага?»
  • «Как вы приняли это решение?»
  • «Что помогло вам разобраться?»
  • «Где вы искали эту информацию?»
  • «Что показалось непонятным?»
  • «Что вы сделали бы дальше в обычной ситуации?»
  • «Какая информация повлияла на ваш выбор?»
Избегайте вопросов, которые подсказывают ответ:
  • «Было ли вам неудобно искать доставку?»
  • «Понятно ли, что заказ можно оплатить при получении?»
  • «Не кажется ли вам, что кнопка слишком незаметная?»
Вместо этого спросите: «Как вы нашли условия доставки?» или «Что вы поняли о способе оплаты?»

Не задавайте два вопроса одновременно: «Что вы выбрали и почему, и было ли легко оформить заказ?» Участник ответит только на последнюю часть или выберет одну из них. Разделите вопросы.

Как сокращать и переписывать задания

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

Если участник регулярно спрашивает, что делать дальше, проверьте, не объединили ли вы несколько целей в одном задании. Разделите «выберите доставку, проверьте срок и измените адрес» на отдельные шаги.

Если участник выполняет действие, но не понимает, зачем он это делает, добавьте контекст. Вместо «выберите способ оплаты» используйте: «Выберите способ оплаты, который подходит, если вы хотите заплатить после получения заказа».

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

Как анализировать ответы

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

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

Группируйте ответы по темам
Объединяйте похожие наблюдения и формулировки:
  • поиск товара;
  • понимание характеристик;
  • содержимое корзины;
  • стоимость и срок доставки;
  • выбор оплаты;
  • доверие к заказу;
  • причины остановки.
Внутри каждой темы отмечайте, сколько участников столкнулись с похожей трудностью. Не превращайте это число в статистику качества продукта: небольшое немодерируемое исследование обычно показывает направления для проверки, а не распространённость проблемы среди всех пользователей.

Фиксируйте проблему конкретно

Формулировка «пользователям неудобно оформлять заказ» слишком общая. Лучше записать:
«Часть участников не заметила, что при оплате при получении нужно выбрать отдельный вариант в блоке оплаты. Из-за этого они возвращались к предыдущему шагу или не были готовы подтверждать заказ».

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

Один ответ не доказывает системную проблему. Смотрите на повторение паттерна: одинаковое действие, похожее объяснение или одна и та же точка остановки у нескольких участников.

Связывайте выводы с целями
Для каждого вывода ответьте на три вопроса:
  1. Какой исследовательский вопрос он раскрывает?
  2. На каких действиях и ответах основан?
  3. Что команда может сделать дальше?
Например:
«Пользователи находят товар через поиск, но не сразу понимают различия между комплектациями. Это видно по возвратам к списку и вопросам о характеристиках. Нужно проверить названия вариантов и способ показа различий в карточке товара».

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

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

  • [ ] Сформулирована одна основная цель исследования.
  • [ ] Исследовательские вопросы связаны с задачами продукта.
  • [ ] Определена целевая аудитория и критерии отбора участников.
  • [ ] Понятно, какой пользовательский путь нужно проверить.
  • [ ] Целевое действие сформулировано однозначно.
  • [ ] Каждое задание описывает цель, а не последовательность кликов.
  • [ ] В сценарии нет наводящих формулировок.
  • [ ] Открытые вопросы не дублируют друг друга.
  • [ ] Для каждого задания понятно, какие данные нужно собрать.
  • [ ] Тестовая среда позволяет пройти путь до конца.
  • [ ] Отключены реальные платежи или подготовлены безопасные тестовые данные.
  • [ ] Проверены запись экрана, сохранение ответов и логика переходов.
  • [ ] Сценарий прошёл пилот на представителе целевой аудитории.
  • [ ] Инструкции понятны без помощи исследователя.
  • [ ] Заранее определено, как наблюдения будут связаны с выводами.

Вывод

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

А также поделитесь статьей с друзьями в соцсетях.

Команда AskUsers
Команда AskUsers