Немодерируемое исследование прототипа позволяет проверить интерфейс в ситуации, максимально близкой к самостоятельному использованию: участник получает задачу, открывает прототип и проходит сценарий без исследователя, который мог бы что-то пояснить или невольно направить его. Именно отсутствие такой помощи делает формат особенно интересным. Если человек не понимает, что делать дальше, проблема проявляется сама — ее не маскирует уточняющий вопрос модератора.
Я занимаюсь анализом данных и консультирую клиентов Тестографа по методологии опросов, и на практике вижу, что немодерируемые исследования часто воспринимают слишком упрощенно: дали респондентам ссылку на прототип, попросили выполнить несколько действий, задали вопросы — получили UX-тест. На самом деле качество результатов здесь особенно сильно зависит от методологии. Исследователь не присутствует во время прохождения, поэтому уже после запуска нельзя объяснить участнику неоднозначное задание или уточнить, что именно он имел в виду в открытом ответе.
При грамотной постановке исследования без модератора можно выяснить довольно многое. Например, понимают ли пользователи структуру интерфейса, находят ли нужную функцию, замечают ли важный элемент, могут ли самостоятельно пройти ключевой сценарий и в какой момент начинают испытывать затруднения. Поведенческие результаты можно дополнить вопросами: насколько сложной показалась задача, чего участник ожидал после определенного действия, почему выбрал конкретный вариант, чего ему не хватило.
Такой формат особенно полезен, когда нужно быстро проверить конкретные продуктовые гипотезы на относительно большой выборке. Например, команда изменила процесс оформления заказа и хочет сравнить две версии; проектирует новый личный кабинет и проверяет понятность навигации; меняет последовательность шагов регистрации; тестирует несколько вариантов структуры сервиса до начала разработки. Немодерируемое исследование позволяет собрать сопоставимые ответы участников по единому сценарию, а затем анализировать их вместе с результатами выполнения заданий.
При этом оно не является более дешевой заменой модерируемого UX-теста. Это разные исследовательские инструменты. Во время модерируемой сессии исследователь может попросить участника рассуждать вслух, уточнить неожиданную реакцию, задать дополнительный вопрос и глубже разобраться в причине поведения. В немодерируемом формате такой возможности нет. Зато условия прохождения лучше стандартизированы: каждый участник получает практически одинаковые инструкции и вопросы, а влияние модератора сводится к минимуму.
Поэтому выбор формата я рекомендую начинать не с вопроса «как нам удобнее провести исследование», а с вопроса «какие данные нам нужны для принятия решения». Если необходимо глубоко разобраться, почему несколько пользователей ведут себя определенным образом, чаще полезнее модерируемая сессия. Если нужно проверить, смогут ли десятки участников самостоятельно выполнить четко определенный сценарий, немодерируемый формат может оказаться эффективнее. В некоторых проектах мы рекомендуем сочетать оба подхода: сначала провести несколько модерируемых интервью, обнаружить основные проблемы и сформировать гипотезы, а затем проверить их на большей выборке без участия модератора.
И наконец, критически важна самостоятельность сценария. В модерируемом исследовании неудачно сформулированное задание иногда можно спасти уточнением. В немодерируемом исследовании ошибка в инструкции масштабируется на всю выборку. Если формулировку неправильно поняли 30 человек, мы получаем не 30 подтверждений проблемы интерфейса, а 30 результатов, потенциально искаженных одной методологической ошибкой.
Поэтому далее разберем немодерируемое исследование прототипа не как последовательность «создать опрос — отправить ссылку — посмотреть ответы», а как полноценный исследовательский процесс: от выбора задач и подготовки прототипа до проектирования сценария, подбора участников и интерпретации результатов. Главная цель — получить данные, по которым продуктовая команда сможет не просто сказать «пользователям понравилось» или «пользователи запутались», а понять, что именно необходимо изменить в следующей версии прототипа и почему.
Немодерируемое исследование особенно хорошо работает там, где поведение пользователя можно превратить в конкретную задачу и заранее определить, какой результат будет считаться успешным. Чем точнее мы можем описать проверяемое действие, тем надежнее будет исследование.
Например, мы проектируем сервис бронирования переговорных комнат. В прототипе появилась новая структура разделов, и команда хочет понять, сможет ли пользователь самостоятельно найти свободную комнату на определенное время. Это подходящая задача: участнику можно дать реалистичный контекст, предложить выполнить действие, а затем зафиксировать результат и задать несколько уточняющих вопросов.
Но если исследовательская задача звучит как «понять, чего пользователям не хватает в сервисе для организации рабочего дня», одного немодерируемого тестирования прототипа, скорее всего, будет недостаточно. Здесь требуется исследовать потребности, привычки и контекст, а не только взаимодействие с заранее спроектированным решением.
Что хорошо проверяется без модератора
На практике я бы выделил несколько типов задач, для которых немодерируемый формат особенно удобен.
В первую очередь это навигация и поиск нужной функции. Можно проверить, понимает ли пользователь структуру продукта, где ожидает увидеть определенную возможность и способен ли добраться до нее без дополнительных объяснений.
Допустим, мы тестируем прототип банковского приложения и хотим проверить новую структуру раздела с платежами. Не стоит давать инструкцию «Откройте раздел “Платежи”, затем выберите “Штрафы”». Такая формулировка фактически раскрывает маршрут.
Лучше сформулировать задачу через ситуацию:
В этом случае мы проверяем интерфейс, а не способность участника следовать инструкции.
Вторая подходящая задача — прохождение пользовательского сценария. Регистрация, оформление заказа, создание заявки, изменение тарифа, запись на услугу, настройка уведомлений — практически любой достаточно четкий процесс можно исследовать таким способом.
Здесь важно смотреть не только на финальный результат. Пользователь может успешно закончить сценарий, но несколько раз вернуться назад, выбрать неправильный пункт или долго искать нужное действие. Формально задача выполнена, однако такое поведение указывает на потенциальную UX-проблему.
Третье направление — проверка понимания интерфейса. После показа экрана можно спросить, что, по мнению участника, произойдет после нажатия определенной кнопки, для чего предназначен раздел или где он стал бы искать конкретную информацию. Особенно полезны такие задания при тестировании новых функций и непривычных элементов навигации.
Наконец, немодерируемый формат подходит для сравнения вариантов. Например, можно исследовать две версии структуры страницы, разные последовательности шагов или варианты названий элементов. Однако здесь особенно важно контролировать состав выборок и порядок демонстрации вариантов. Иначе различия между группами легко принять за эффект дизайна.
Что прототип позволяет проверить еще до разработки
Одна из сильных сторон исследования прототипов — возможность обнаружить проблемы до того, как команда потратила ресурсы на полноценную реализацию решения.
Для этого не всегда требуется высокодетализированный интерфейс. Иногда достаточно кликабельного прототипа, чтобы обнаружить принципиальную проблему: пользователи ищут функцию совершенно не там, где ее разместила команда.
На ранних стадиях я рекомендую концентрироваться прежде всего на крупных решениях: структуре, последовательности действий, терминологии, логике переходов. Проверять небольшие визуальные детали в черновом прототипе обычно преждевременно.
Чем ниже детализация прототипа, тем осторожнее нужно интерпретировать результаты. Если участник не заметил кнопку в схематичном wireframe, это еще не доказывает, что проблема сохранится в готовом интерфейсе. Но если большинство участников выбирает другой раздел, потому что именно там ожидает найти функцию, это уже гораздо более содержательный сигнал.
Где отсутствие модератора становится ограничением
Главное ограничение формата заключается не в количестве доступных методов, а в невозможности задать вопрос в нужный момент.
Представим, что участник неожиданно возвращается на предыдущий экран. Во время модерируемой сессии исследователь может спросить: «Что вы сейчас пытаетесь найти?» — и получить объяснение.
В немодерируемом исследовании остается только само действие и заранее подготовленные вопросы. Мы видим, что произошло, но не всегда можем достоверно установить, почему.
Поэтому формат хуже подходит для исследования сложных мотивов, эмоциональных реакций и еще не сформулированных потребностей. С осторожностью я использовал бы его и для совершенно новых продуктов, когда команда пока плохо понимает возможные модели поведения пользователей.
Есть простое практическое правило: если для получения полезного результата вам необходимо несколько раз спросить участника «Почему?», стоит рассмотреть модерируемое исследование или интервью.
Если же основной вопрос звучит как «Сможет ли пользователь самостоятельно это сделать?», немодерируемое исследование выглядит гораздо перспективнее.
Начинаем не с анкеты, а с исследовательского вопроса
Одна из наиболее частых ситуаций, которые я встречаю при консультировании по методологии, — команда приходит с уже подготовленным списком вопросов, но без четкого понимания, какое решение будет принято на основании ответов.
Я предлагаю временно отложить анкету и сформулировать исследовательские вопросы.
Например:
Теперь под каждый вопрос можно подобрать наблюдаемый показатель и дополнительные вопросы.
Если нас интересует поиск истории платежей, мы можем смотреть, выполнил ли участник задачу, каким маршрутом двигался, сколько времени потратил, а после прохождения попросить оценить сложность и объяснить, что вызвало затруднение.
Так появляется важная связка:
Именно ее я рекомендую проверять для каждого блока исследования. Если какой-либо вопрос анкеты невозможно связать с исследовательской задачей, стоит спросить себя, зачем мы вообще собираем эти данные.
Не превращайте исследование в презентацию прототипа
Есть еще одна методологическая ловушка: продуктовая команда слишком хорошо знает собственный интерфейс и бессознательно старается помочь участнику.
Отсюда появляются подробные вступления:
После такого описания проверять, найдет ли пользователь управление подпиской, уже бессмысленно — мы только что сообщили ему расположение функции.
В инструкции участнику должно быть достаточно контекста для выполнения реалистичной задачи, но не должно быть информации, раскрывающей проверяемую гипотезу.
Поэтому перед запуском я использую простой тест: смог бы человек выполнить задание только по тексту инструкции, почти не анализируя интерфейс? Если ответ положительный, скорее всего, в задании слишком много подсказок.
Хорошее немодерируемое исследование устроено иначе. Мы создаем понятную ситуацию, убираем подсказки и даем человеку возможность действовать самостоятельно. А уже затем измеряем результат и спрашиваем о впечатлениях. В следующем разделе разберем, как подготовить сам прототип к такому исследованию, чтобы технические ограничения макета не начали маскироваться под проблемы пользовательского опыта.
В модерируемом исследовании техническую шероховатость прототипа иногда можно компенсировать: предупредить участника, что определенная кнопка пока не работает, вернуть его на нужный экран или объяснить условность макета. В немодерируемом исследовании такой возможности нет. Участник остается с прототипом один на один, поэтому любая техническая недоработка может превратиться в ложную UX-проблему.
Если человек нажал на кнопку, которая должна была работать, но переход не настроен, мы не можем считать это ошибкой пользователя. Если он попал в тупик из-за отсутствующего экрана, время выполнения задания тоже теряет исследовательский смысл. Поэтому подготовку прототипа я рассматриваю как часть методологии, а не только как технический этап.
Определите необходимый уровень детализации
Для исследования не всегда нужен визуально завершенный прототип. Его детализация должна соответствовать тому, что именно мы собираемся проверять.
Если исследовательский вопрос касается структуры продукта — например, понимают ли пользователи, где искать документы, настройки или историю операций, — часто достаточно относительно простого кликабельного прототипа. В этом случае важнее корректно воспроизвести информационную архитектуру и переходы между разделами.
Если мы хотим проверить понятность конкретной формы, последовательность оформления заказа или работу нового пользовательского сценария, потребуется более детальный прототип. В нем должны присутствовать поля, состояния, кнопки, сообщения и другие элементы, влияющие на принятие решений.
А вот для исследования первого впечатления или восприятия визуальной иерархии низкодетализированный wireframe может оказаться неподходящим: участники будут реагировать на условность макета вместо будущего интерфейса.
Я использую простой принцип: в прототипе должно быть достаточно деталей для проверки гипотезы, но необязательно больше. Избыточная проработка увеличивает стоимость подготовки исследования и иногда создает ложное ощущение, что тестируется уже практически готовый продукт.
Не обязательно делать кликабельным весь продукт
Еще одна распространенная ошибка — попытка перед исследованием воспроизвести в прототипе практически весь сервис.
Представим, что мы хотим проверить новый сценарий изменения тарифа. Для исследования могут понадобиться главная страница личного кабинета, раздел с тарифом, экран выбора нового плана, подтверждение и несколько альтернативных маршрутов.
Это не означает, что необходимо проектировать все разделы личного кабинета.
Но здесь возникает важный нюанс. Если на экране присутствует элемент, который выглядит интерактивным и логически может быть выбран участником, нужно заранее решить, что произойдет после нажатия.
В реальном исследовании пользователи редко проходят тот маршрут, который команда считает очевидным. Один нажмет на имя профиля, другой — на настройки, третий — на текущий тариф, четвертый начнет искать управление подпиской в разделе оплаты.
Именно эти отклонения часто содержат наиболее полезные данные.
Поэтому прототип должен поддерживать не только идеальный путь, но и наиболее вероятные альтернативные действия.
Проверяйте кликабельные области как пользователь, а не как дизайнер
В прототипах, созданных в Figma или другом инструменте, исследователь знает расположение всех активных областей. Респондент — нет.
Из-за этого перед запуском важно самостоятельно пройти каждый сценарий, намеренно совершая «неправильные» действия.
Попробуйте нажать рядом с кнопкой. Выберите соседний раздел. Вернитесь назад. Откройте экран повторно. Нажмите на элемент, который визуально похож на ссылку. Попробуйте пройти сценарий не в той последовательности, которую задумала команда.
Такой тест часто обнаруживает проблемы, незаметные при обычной проверке happy path.
Особенно осторожно стоит относиться к искусственно увеличенным кликабельным областям. Иногда дизайнер делает активным не только небольшой элемент, но почти весь экран, чтобы участнику было проще попасть в нужную точку. Для демонстрации прототипа это удобно, но для исследования может исказить результат: человек совершает неточное действие, а прототип засчитывает его как правильное.
У пользователя не должно быть обязанности «догадаться, что это прототип»
Участник должен понимать ограничения исследования, но ему не следует постоянно интерпретировать технические особенности макета.
Плохая инструкция выглядит примерно так:
После нее становится практически невозможно отличить проблему интерфейса от проблемы самого прототипа.
Допустим, пользователь нажал на логически правильный элемент, но ничего не произошло. Затем он решил, что выбрал неправильный путь, и начал искать другой. В данных мы увидим затруднение пользователя, хотя на самом деле затруднение создали сами.
Поэтому все действия, необходимые для выполнения исследуемого сценария, должны работать предсказуемо. Если часть интерфейса намеренно недоступна, это ограничение не должно пересекаться с проверяемыми маршрутами.
Отдельно проверяйте тупиковые сценарии
Тупик — одна из самых неприятных проблем немодерируемого теста.
Участник совершает действие, попадает на экран, с которого невозможно продолжить, и не понимает, является ли это частью задания. В результате он закрывает прототип, возвращается к анкете или вообще прекращает исследование.
Перед запуском я рекомендую составить небольшую карту возможных переходов:
Особое внимание нужно уделить возврату назад. В настоящем интерфейсе пользователь привык, что может изменить решение. Если прототип позволяет двигаться только вперед, его поведение становится искусственным.
Полезно также проверить повторные действия. Например, что произойдет, если участник дважды откроет один раздел, вернется на стартовый экран или попробует заново выполнить часть сценария.
Не смешивайте техническую ошибку с UX-проблемой
Представим результаты исследования: 40% участников не смогли завершить оформление заявки.
Цифра выглядит тревожно. Но сама по себе она еще ничего не доказывает.
Нужно разобраться, почему возникли неуспешные прохождения. Одни участники могли не понять интерфейс. У других не сработал переход. Третьи открыли прототип на устройстве, для которого он не был подготовлен. Четвертые могли просто прекратить участие.
Если объединить эти случаи в один показатель, мы получим красивую метрику с сомнительным содержанием.
Поэтому еще до запуска полезно определить категории неуспешных прохождений:
Такое разделение значительно облегчает последующий анализ.
Проверьте мобильный и десктопный сценарии отдельно
Если исследование разрешено проходить с разных устройств, нельзя автоматически считать условия одинаковыми.
Прототип, который прекрасно работает на ноутбуке, может оказаться неудобным на смартфоне: текст станет слишком мелким, область прототипа не поместится на экране, появится дополнительная прокрутка или изменится поведение элементов.
Поэтому нужно заранее решить, какие устройства соответствуют исследовательской задаче.
Если мы тестируем мобильное приложение, логично ориентировать участников на смартфоны. Если исследуем сложный B2B-интерфейс, которым сотрудники в реальности пользуются с рабочего компьютера, прохождение с телефона может только добавить шум в данные.
Устройство — это часть контекста использования, а не техническая мелочь.
Проведите внутренний «сломанный» тест
Перед передачей исследования респондентам я советую попросить коллегу, который не участвовал в создании прототипа, пройти сценарий без каких-либо объяснений.
Причем задача такого тестировщика — не просто успешно дойти до конца. Попросите его попытаться «сломать» сценарий: выбирать неочевидные маршруты, возвращаться назад, нажимать на разные элементы и действовать так, как дизайнер не планировал.
Создатель прототипа слишком хорошо знает правильный путь и поэтому часто буквально не видит некоторые проблемы. Человек без этого знания намного быстрее обнаруживает места, где инструкция допускает двойное толкование или интерфейс ведет в тупик.
Я бы не запускал полноценную выборку сразу после такой проверки. Следующий этап — небольшой пилот на нескольких участниках, максимально похожих на целевую аудиторию. О нем мы еще поговорим отдельно.
Прототип и анкета должны работать как единый сценарий
Сам прототип — только одна часть немодерируемого исследования. Вторая часть — последовательность инструкций, заданий и вопросов.
Например, в Тестографе можно построить опрос, в котором участник сначала проходит скрининг и вводный блок, затем получает задание для работы с прототипом, после выполнения возвращается к вопросам об опыте, а далее переходит к следующему сценарию.
На этом этапе особенно важно проверить всю цепочку глазами участника: понятно ли, когда открыть прототип, когда вернуться к опросу, что считать завершением задания и какое действие выполнить дальше.
Чем меньше участнику приходится разбираться в механике самого исследования, тем больше внимания он сможет уделить продукту.
Именно поэтому перед запуском я проверяю не только макет, но и полный пользовательский путь исследования — от первой инструкции до последнего вопроса. Хорошо подготовленный прототип не должен требовать присутствия исследователя. Он должен позволить человеку самостоятельно действовать, ошибаться, возвращаться и принимать решения — а нам получить данные именно об интерфейсе, а не о технических ограничениях тестового макета.
Сценарий немодерируемого исследования я обычно проектирую как отдельный пользовательский путь. У него есть точка входа, контекст, последовательность заданий и точки, в которых мы собираем данные. При этом участник должен понимать, что от него требуется, без дополнительных пояснений исследователя.
Это принципиальное отличие от обычной анкеты. Недостаточно составить список вопросов и добавить между ними ссылки на прототип. Нужно заранее определить, какое действие совершает участник, что мы измеряем в этот момент и какой вопрос задаем после действия.
От исследовательского вопроса к заданию
Начинать лучше не с формулировки задания, а с гипотезы или исследовательского вопроса.
Допустим, команда изменила навигацию в личном кабинете. Гипотеза звучит так: пользователи смогут самостоятельно найти способ изменить платежные данные.
Из нее можно сформировать задачу:
Здесь мы не называем раздел, кнопку или ожидаемый маршрут. Участник получает цель, а способ ее достижения выбирает самостоятельно.
Для сравнения:
Такое задание намного слабее. Если мы хотели проверить, сможет ли пользователь найти настройки подписки, то уже подсказали ему решение.
При подготовке исследований я стараюсь проверять каждое задание одним вопросом: какую часть ответа мы уже сообщили участнику в самой формулировке?
Если инструкция содержит термин из интерфейса, название нужного раздела или последовательность действий, это повод ее пересмотреть.
Давайте контекст, но не маршрут
Полностью лишать участника контекста тоже неправильно.
Фраза «Найдите изменение способа оплаты» звучит скорее как экзаменационное упражнение, чем как реальная пользовательская задача. Человек понимает, что исследователь ожидает от него определенного действия, и начинает искать соответствующий элемент интерфейса.
Ситуационный сценарий работает лучше:
Здесь появляется причина действия, но не появляется подсказка.
Это особенно важно при тестировании терминологии. Если команда хочет узнать, понимают ли пользователи назначение раздела «Рабочее пространство», нельзя использовать выражение «рабочее пространство» в задании. Иначе мы искусственно повышаем вероятность того, что участник заметит именно этот пункт меню.
Базовая структура исследования
Для большинства немодерируемых тестов прототипов можно использовать следующую последовательность:
Скрининг нужен, чтобы определить, относится ли человек к аудитории исследования. Здесь могут быть вопросы об опыте использования определенных продуктов, профессиональной роли, частоте выполнения интересующего нас действия или других релевантных характеристиках.
Во вводном блоке мы объясняем формат исследования. Участнику важно сообщить, что тестируется интерфейс, а не его способности. Но не стоит подробно рассказывать о продуктовой гипотезе или перечислять изменения, которые команда хочет проверить.
Затем участник получает одно задание. После его выполнения мы собираем данные именно об этом сценарии и только после этого переходим к следующему.
Я не рекомендую показывать человеку сразу список из пяти задач. Он начнет заранее изучать интерфейс с учетом будущих заданий, и результаты следующих сценариев будут искажены.
Вопросы лучше задавать сразу после действия
Чем больше времени проходит между взаимодействием с прототипом и вопросом о нем, тем сильнее приходится полагаться на память участника.
Поэтому после значимых заданий полезно размещать небольшой блок вопросов.
Например:
Количество таких вопросов должно быть разумным. Если после каждого клика участнику приходится заполнять мини-анкету из десяти пунктов, исследование начинает измерять скорее терпение респондента.
Я обычно оставляю после задания только те вопросы, которые помогают интерпретировать наблюдаемое поведение.
Не спрашивайте то, что уже можете измерить
Если исследовательская система позволяет определить, завершил ли пользователь сценарий, необязательно заставлять его отдельно подтверждать каждое действие.
То же касается информации, которую мы можем получить из самого прохождения.
Полезный принцип здесь простой: поведенческие данные отвечают на вопрос «что произошло», а анкета помогает разобраться, как участник это воспринял и почему мог действовать именно так.
Например, мы видим, что человек потратил на поиск функции значительно больше времени, чем другие участники. После задания его открытый комментарий может объяснить причину: он ожидал увидеть функцию в другом разделе.
Именно соединение этих двух источников данных делает исследование содержательнее.
Осторожнее с вопросами, которые раскрывают гипотезу
Наводящими бывают не только задания.
Представим, что после первого экрана мы спрашиваем:
После этого участник уже знает, что кнопка важна для исследования. Если она понадобится в следующем задании, его поведение изменится.
Поэтому при построении сценария нужно учитывать не только порядок заданий, но и эффект предыдущих вопросов.
Каждый вопрос сообщает участнику что-то о намерениях исследователя. Иногда это неизбежно, но раскрывать проверяемую гипотезу раньше времени не стоит.
По этой же причине общие вопросы о впечатлении от интерфейса часто разумнее оставлять на конец исследования.
Одно задание — одна основная цель
Сложные многоступенчатые задания выглядят реалистично, но плохо подходят для диагностики проблем.
Например:
Если участник не завершил сценарий, возникает вопрос: где именно произошла проблема?
Гораздо удобнее разделить такой путь на исследовательски значимые этапы. Это не обязательно означает превращение каждого клика в отдельное задание. Делить сценарий нужно там, где меняется проверяемая гипотеза.
Например, отдельно проверить поиск подходящего тарифа, а затем — понимание процесса его подключения.
Так мы получаем результаты, которые можно привязать к конкретным решениям команды.
Используйте ветвление там, где оно действительно нужно
Линейный сценарий подходит не всегда.
Представим, что после задания мы спрашиваем: «Удалось ли вам выполнить задачу?»
Участникам, ответившим «да», можно задать вопрос об уверенности в результате. Тем, кто ответил «нет», — предложить указать, что именно помешало.
Нет необходимости показывать обеим группам одинаковый набор вопросов.
В опросе, созданном в Тестографе, для таких случаев можно использовать логику и ветвление: дальнейший путь респондента зависит от его предыдущего ответа. Это помогает сократить ненужные вопросы и адаптировать исследование к ситуации конкретного участника.
Но здесь есть важное ограничение: сложная логика быстро становится трудной для контроля. Если сценарий содержит десятки условий и переходов, перед запуском необходимо протестировать каждую основную ветку отдельно.
Не заставляйте участника постоянно переключаться
Один из практических источников потерь респондентов — неудобная механика прохождения.
Например:
Если таких циклов много, часть участников неизбежно начинает путаться.
Поэтому при проектировании исследования стоит считать не только количество вопросов, но и количество переключений между средами. Инструкция должна однозначно объяснять, где сейчас находится участник и что ему делать после завершения действия.
Особенно тщательно этот сценарий необходимо проверять на мобильных устройствах, где переключение между прототипом и опросом может быть менее удобным.
Не перегружайте исследование заданиями
У продуктовой команды почти всегда возникает желание добавить «еще один небольшой вопрос».
Затем еще один.
В итоге короткий тест превращается в исследование на 40 минут.
Проблема здесь не только в проценте незавершенных прохождений. Уставший участник меняет поведение: быстрее читает задания, меньше изучает интерфейс, дает более короткие открытые ответы и чаще выбирает первый приемлемый вариант.
Поэтому при проектировании сценария я задаю каждому вопросу довольно жесткий критерий: какое решение мы примем на основании ответа?
Если ответа нет, вопрос, скорее всего, можно убрать.
Сценарий должен работать без автора исследования
Перед запуском полезно провести простой эксперимент: передать готовое исследование человеку, который ничего не знает о проекте, и не отвечать на его вопросы во время прохождения.
Если он спрашивает: «Что здесь нужно сделать?», «Я уже закончил задание?», «Мне возвращаться в анкету?» или «Эта кнопка должна работать?» — это не проблема тестировщика. Это диагностический сигнал.
Все необходимые объяснения должны быть встроены в сценарий до начала основной полевой части.
При этом сценарий не должен становиться подробной инструкцией по использованию продукта. Хорошее немодерируемое исследование создает довольно необычный баланс: участнику абсолютно понятно, как проходить исследование, но не обязательно понятно, как выполнить задачу в самом интерфейсе.
Именно вторую часть мы и проверяем.
Когда этот сценарий готов, можно переходить к формулировке вопросов после взаимодействия с прототипом. На этом этапе особенно важно не испортить хорошие поведенческие данные плохой анкетой — например, наводящими вопросами или оценочными шкалами, которые на самом деле ничего не измеряют.
После выполнения задания возникает соблазн спросить участника обо всем сразу: понравился ли интерфейс, было ли удобно, понятны ли кнопки, что стоит улучшить и стал бы он пользоваться продуктом. В результате исследование быстро обрастает вопросами, но далеко не каждый ответ помогает понять качество прототипа.
При консультировании по методологии я предлагаю отталкиваться от другого принципа: вопрос после задания должен помогать интерпретировать поведение, которое мы только что наблюдали. Если пользователь не выполнил задачу, нам важно понять причину. Если выполнил — насколько уверенно он воспринимает результат. Если несколько участников остановились в одном месте — что именно они там ожидали увидеть.
Разделяйте поведение и субъективную оценку
Представим, что пользователь успешно нашел функцию изменения тарифа, но после задания оценил его сложность на 2 балла из 5.
Что считать результатом?
Факт успешного выполнения говорит о том, что человек смог пройти сценарий. Оценка сложности показывает, как он воспринимал этот процесс. Эти данные отвечают на разные вопросы, поэтому один показатель не должен заменять другой.
В исследованиях прототипов полезно мысленно разделять результаты на два слоя.
Особенно интересны расхождения. Пользователь может быстро выполнить задачу, но поставить низкую оценку удобству. Или, наоборот, сказать, что все было просто, хотя несколько раз выбирал неправильный маршрут.
Такие случаи я не рекомендую воспринимать как противоречие в данных. Часто именно они указывают на проблему, которую средние показатели скрывают.
Закрытые вопросы дают структуру, открытые — объяснение
Закрытые вопросы удобны для сравнения результатов между участниками и заданиями.
Например:
Для ответа можно использовать симметричную шкалу от «очень сложно» до «очень легко».
Если одинаковый вопрос задается после нескольких сценариев, мы можем сравнить их между собой и обнаружить этапы, которые пользователи воспринимают как более сложные.
Открытый вопрос решает другую задачу:
Что, если что-то, вызвало у вас затруднение при выполнении задания?
Здесь участник может назвать причину, которую команда не предусмотрела заранее.
Но открытые вопросы не стоит добавлять после каждого действия только потому, что «качественные данные полезны». Если человек шесть раз подряд должен подробно объяснять впечатления, качество комментариев быстро снижается.
В Тестографе можно сочетать разные типы вопросов и использовать логику показа, чтобы дополнительные вопросы появлялись только там, где они действительно нужны. Например, попросить объяснить причину именно тех участников, которые сообщили о затруднении или не смогли закончить задание.
Почему «Вам все понятно?» — слабый вопрос
Этот вопрос встречается в исследованиях интерфейсов довольно часто:
Проблема в том, что ответ «да» практически ничего нам не сообщает.
Пользователь может считать, что понял интерфейс, но интерпретировать его совершенно не так, как задумала команда. Кроме того, признать собственное непонимание психологически сложнее, чем выбрать нейтральную или положительную оценку.
Если необходимо проверить понимание, лучше попросить человека продемонстрировать его.
Вместо:
можно спросить:
Или:
Теперь мы получаем не декларацию понимания, а его содержание.
Спрашивайте об ожиданиях
Один из самых полезных вопросов при тестировании прототипов связан с ожиданиями пользователя.
Если человек нажал на элемент и получил неожиданный результат, полезно узнать, чего он ожидал.
Например:
Ответы на такой вопрос помогают обнаруживать расхождения между ментальной моделью пользователя и логикой продукта.
Предположим, кнопка называется «Сохранить», а большинство участников ожидает после ее нажатия вернуться на предыдущий экран. Прототип при этом оставляет пользователя на текущей странице. Формально функция работает, но возникает несоответствие ожиданий.
Такие небольшие расхождения часто становятся причиной ощущения, что интерфейс «не совсем понятный», хотя пользователю сложно самостоятельно объяснить проблему.
Оценивайте сложность конкретного задания
Для оценки воспринимаемой сложности отдельного задания в UX-исследованиях часто используют Single Ease Question (SEQ) — короткий вопрос, который задается сразу после выполнения задачи.
Логика метода проста: участник оценивает, насколько легким или сложным было конкретное задание.
Для исследования особенно полезна не сама цифра, а возможность сравнивать задания между собой или отслеживать изменение показателя после переработки прототипа.
Если после изменения процесса регистрации оценка одного и того же задания заметно улучшилась, а поведенческие показатели также изменились в нужную сторону, это дает гораздо более сильное основание для вывода, чем абстрактный вопрос «Нравится ли вам новая регистрация?».
При этом важно использовать одинаковую формулировку и одинаковую шкалу во всех сравниваемых исследованиях. Если в первой волне мы спрашиваем об удобстве, а во второй — о простоте, прямое сравнение становится менее надежным.
Когда имеет смысл использовать SUS
Для общей оценки воспринимаемой юзабилити продукта может использоваться System Usability Scale (SUS). Это стандартизированный опросник, состоящий из десяти утверждений.
Но я бы не добавлял SUS автоматически в каждое тестирование прототипа.
Если исследование посвящено одной небольшой функции или короткому сценарию, итоговый показатель может оказаться слишком общим относительно исследовательской задачи. Мы получим число, но не обязательно поймем, что именно нужно изменить.
SUS становится полезнее, когда участник взаимодействовал с достаточно целостной системой и нам требуется стандартизированная оценка, которую можно сравнивать между версиями продукта или исследованиями.
Здесь действует тот же принцип: метрика должна появляться потому, что она отвечает на исследовательский вопрос, а не потому, что ее принято использовать в UX.
Не смешивайте оценку интерфейса с оценкой идеи
Представим, что мы тестируем новый сервис автоматического формирования отчетов.
После прототипа задаем вопрос:
Что именно оценивает участник?
Визуальный дизайн? Навигацию? Саму идею автоматических отчетов? Полезность функции для своей работы? Качество текстов? Возможно, все одновременно.
Такие вопросы дают показатель, который сложно интерпретировать.
Если нас интересует конкретная характеристика, лучше спрашивать именно о ней:
Теперь мы разделяем удобство взаимодействия и ценность самой функции.
Избегайте подтверждения собственной гипотезы
Формулировка вопроса способна незаметно подтолкнуть участника к нужному команде ответу.
Например:
В вопрос уже встроено предположение, что навигация стала удобнее.
Нейтральнее:
Еще лучше — если исследовательская задача позволяет сравнить поведение пользователей в разных версиях, а не просить их самостоятельно оценивать, стало ли решение лучше.
Особенно внимательно я рекомендую проверять слова «удобный», «понятный», «быстрый», «современный», «улучшенный» и «простой». Они нередко появляются в вопросах как готовая оценка.
Добавляйте вариант «не могу оценить»
Не каждый участник способен содержательно ответить на каждый вопрос.
Если человек не смог закончить сценарий, вопрос «Насколько удобным был последний этап оформления?» может быть для него неприменим.
Когда ситуация допускает отсутствие опыта или мнения, полезно предусмотреть соответствующий вариант ответа: «не дошел до этого этапа», «не могу оценить», «не заметил этот элемент».
Иначе респондент вынужден выбрать случайный вариант шкалы, а исследователь получает число, которое выглядит как полноценное наблюдение.
Не превращайте итоговый блок в еще одно исследование
После завершения всех заданий можно задать несколько общих вопросов: об общем впечатлении, наиболее сложных моментах, ожиданиях или сравнении с привычным опытом.
Например:
Такие вопросы помогают увидеть проблему в контексте всего сценария.
Но итоговый блок не должен внезапно превращаться в двадцать дополнительных вопросов о бренде, цене, намерении купить продукт и демографии. Если эти данные действительно необходимы, их место и влияние на продолжительность исследования нужно продумать заранее.
Хороший вопрос должен менять интерпретацию результата
Перед финальной проверкой анкеты я предлагаю пройти по каждому вопросу и представить два противоположных ответа.
Допустим, участник отвечает «очень легко». Что мы поймем?
Теперь представим, что он отвечает «очень сложно». Изменится ли наше понимание результата или решение команды?
Если независимо от ответа мы ничего не будем делать иначе, ценность вопроса сомнительна.
В хорошо спроектированном немодерируемом исследовании вопросов обычно меньше, чем хочется продуктовой команде. Зато каждый из них выполняет понятную функцию: подтверждает результат, помогает объяснить поведение, измеряет конкретную характеристику или позволяет сравнить сегменты и версии.
Следующий важный вопрос — кому именно давать этот прототип. Даже идеально сформулированные задания и шкалы не спасут исследование, если половина выборки состоит из людей, которые никогда не сталкиваются с проверяемой задачей. Поэтому дальше разберем рекрутинг, скрининг и размер выборки.
Даже хорошо подготовленный прототип и аккуратно сформулированные задания дадут слабые результаты, если исследование проходят не те люди. В немодерируемом формате эта проблема особенно заметна: мы собираем больше прохождений и легко начинаем воспринимать размер выборки как признак надежности. Но 100 ответов нерелевантных респондентов не становятся полезнее пяти ответов представителей нужной аудитории.
Поэтому до расчета количества участников я рекомендую определить, чей пользовательский опыт нам вообще нужен.
Начните с поведения, а не с портрета аудитории
Для UX-исследования не всегда нужен подробный маркетинговый портрет пользователя.
Допустим, мы тестируем новый сценарий выставления счета в сервисе для бизнеса. Нам может быть гораздо важнее, выставляет ли человек счета клиентам самостоятельно и как часто он это делает, чем его возраст или семейное положение.
Вместо абстрактного описания «мужчины и женщины 25–45 лет, работающие в малом бизнесе» полезнее сформулировать критерий через релевантный опыт:
Пользователи, которые самостоятельно выставляют клиентам счета не реже нескольких раз в месяц.
Такой подход помогает отбирать людей, способных оценивать сценарий на основании собственного опыта.
Чем ближе критерий отбора к исследуемому поведению, тем меньше в данных случайных оценок.
Используйте скрининг, но не раскрывайте правильный ответ
Для отбора участников можно добавить в начало исследования несколько скрининговых вопросов.
Например, если нам нужны люди, которые регулярно пользуются сервисами бронирования жилья, слабый вариант будет таким:
Человек довольно легко понимает, какой ответ позволит продолжить.
Лучше спросить о поведении нейтрально:
И предложить несколько вариантов, среди которых онлайн-сервисы будут только одним из ответов.
То же касается профессиональных исследований. Если нужны руководители, принимающие решения о найме, не обязательно спрашивать: «Принимаете ли вы решения о найме сотрудников?». Можно уточнить, какие задачи, связанные с подбором персонала, человек выполнял за определенный период.
Скрининг должен выявлять нужный опыт, а не объяснять респонденту, какой профиль мы ищем.
Не собирайте лишние персональные характеристики
Возраст, пол, образование, доход, должность, город — привычный набор для многих анкет. Но в UX-исследовании далеко не каждая из этих переменных действительно нужна.
Я рекомендую для каждого такого вопроса заранее определить, как он будет использоваться при анализе.
Если мы предполагаем, что опыт взаимодействия с продуктом зависит от профессиональной роли, роль стоит измерять. Если собираемся сравнивать новичков и опытных пользователей, необходимо спросить об опыте.
Но если возраст участника никак не связан с гипотезой и мы не собираемся анализировать результаты по возрастным группам, вопрос только увеличивает анкету и объем данных, которые потом придется обрабатывать.
Собирать стоит не максимум характеристик респондента, а минимум, необходимый для интерпретации результатов.
Новичков и опытных пользователей лучше различать
Один из факторов, который действительно часто влияет на результаты тестирования, — предыдущий опыт.
Представим, что мы изменили навигацию существующего сервиса. Постоянные пользователи знают старое расположение функций и могут продолжать искать их там по привычке. Новые пользователи такой модели не имеют.
Если объединить обе группы, средний показатель успешности может скрыть важный эффект.
Например:
общий процент успешного выполнения выглядит приемлемым.
Без сегментации мы можем сделать вывод, что новая структура работает хорошо. На самом деле она работает хорошо для одной группы и создает проблему для другой.
Поэтому при исследовании редизайна, новой навигации или изменения привычного сценария предыдущий опыт пользователя стоит учитывать отдельно.
Сколько участников нужно
Универсального числа здесь нет.
Размер выборки зависит от того, какой вывод мы хотим получить.
Если задача — быстро обнаружить основные проблемы сценария и собрать качественные наблюдения, может быть полезна относительно небольшая выборка. Если требуется сравнить две версии прототипа, оценить различия между сегментами или получить устойчивые количественные показатели, участников понадобится значительно больше.
Я бы разделял два подхода.
Во втором случае размер выборки уже должен определяться с учетом статистической задачи: ожидаемой величины эффекта, допустимой ошибки, количества сравниваемых групп и требуемой уверенности в результате.
Поэтому вопрос «Сколько человек нужно для UX-теста?» без контекста примерно равнозначен вопросу «Сколько данных нужно для анализа?». Сначала необходимо понять, какой анализ предполагается.
Почему пять пользователей — не универсальное правило
В UX-среде часто встречается рекомендация протестировать интерфейс на пяти пользователях. У нее есть историческое и практическое основание в контексте выявления проблем юзабилити, но переносить число пять на любое исследование некорректно.
Пять участников могут обнаружить несколько серьезных проблем. Но выборка из пяти человек не позволяет надежно утверждать, что, например, 60% целевой аудитории не смогут выполнить задачу.
Тем более она плохо подходит для сравнений сегментов.
Представим, что у нас пять новых и пять опытных пользователей. В первой группе задачу выполнили четыре человека, во второй — два. Проценты выглядят впечатляюще: 80% против 40%.
Но за каждым участником здесь стоит сразу 20 процентных пунктов. Один человек изменит результат с 40% до 60%. Делать сильные количественные выводы по таким значениям опасно.
Поэтому небольшую выборку лучше использовать для поиска и описания проблем, а не для создания видимости статистической точности.
Не путайте число начавших и число валидных прохождений
Если исследование открыли 150 человек, это еще не означает, что выборка составляет 150 участников.
Часть может не пройти скрининг. Кто-то прекратит исследование. У кого-то не загрузится прототип. Некоторые участники пройдут задания настолько быстро, что возникнут сомнения, взаимодействовали ли они с интерфейсом вообще.
В анализ должна попадать валидная выборка, соответствующая заранее установленным критериям качества.
Именно поэтому при планировании рекрутинга полезно закладывать запас. Если для анализа требуется определенное количество завершенных и качественных прохождений, приглашенных участников обычно понадобится больше.
Контролируйте качество ответов
Немодерируемое исследование предполагает меньше контроля над тем, как именно человек проходит тест.
Поэтому после сбора данных я обращаю внимание на несколько сигналов.
Важно установить правила исключения до того, как мы увидели желаемый или нежелательный результат. Иначе возникает риск бессознательно оставить ответы, подтверждающие гипотезу команды, и исключить неудобные наблюдения.
Не исключайте участника только потому, что он ошибся
Это принципиальный момент.
Если пользователь выбрал совершенно неожиданный маршрут, не понял интерфейс или несколько раз совершил неправильное действие, это не делает его «плохим респондентом».
Наоборот, именно такое поведение мы часто и хотим обнаружить.
Исключать стоит результаты, качество которых вызывает методологические сомнения: технические сбои, нерелевантный профиль, очевидное отсутствие взаимодействия с заданием, дубли или другие заранее определенные причины.
Ошибка пользователя внутри исследуемого сценария — это данные, а не основание удалить наблюдение.
Сегменты определяйте до анализа
Еще одна распространенная проблема появляется после сбора результатов. Команда начинает искать интересные различия и делить выборку на все более мелкие группы: по возрасту, устройству, опыту, должности, частоте использования продукта.
При достаточном количестве разрезов где-нибудь почти неизбежно обнаружится заметная разница.
Поэтому основные сегменты лучше определить заранее на основании исследовательских гипотез.
Например:
Так анализ остается связанным с задачами исследования, а не превращается в поиск случайных закономерностей.
Хорошая выборка начинается с вопроса «для кого мы проектируем»
Перед запуском я рекомендую записать одним предложением критерий целевого участника.
Например:
После этого значительно проще составить скрининг, определить необходимые сегменты и понять, кого не следует включать в анализ.
Если такое предложение сформулировать сложно, вероятно, проблема не в рекрутинге — команда пока недостаточно четко определила аудиторию проверяемого сценария.
Когда критерии участников и необходимая выборка определены, можно переходить к запуску. Но отправлять исследование сразу всей базе я не рекомендую. Сначала стоит провести пилот и проверить, как реальная аудитория понимает задания, сколько времени занимает прохождение и не появляются ли ошибки, которые после масштабного запуска исправлять уже поздно.
Когда прототип, задания и анкета готовы, исследование кажется практически завершенным. Остается разослать ссылку и дождаться ответов. Именно на этом этапе я чаще всего рекомендую не торопиться: ошибка, обнаруженная после 100 прохождений, обходится значительно дороже ошибки, найденной после пяти.
Поэтому полноценному запуску должен предшествовать пилот. Его задача — проверить не продуктовую гипотезу, а само исследование: понимают ли участники инструкции, работают ли переходы, хватает ли им контекста, корректно ли отображается прототип и получаем ли мы в результате те данные, которые планировали анализировать.
Проведите пилотный запуск
Пилот — это небольшая версия будущего исследования на нескольких участниках. Желательно, чтобы они были максимально близки к целевой аудитории.
Внутреннее тестирование коллегами полезно для поиска технических ошибок, но полностью заменить пилот оно не может. Сотрудник компании знает продукт, терминологию и контекст гораздо лучше обычного пользователя.
Во время пилота я проверяю три уровня.
Последний пункт часто недооценивают. Анкета может прекрасно работать технически, но после первых ответов выясняется, что невозможно понять причину неуспешного прохождения или отделить один тип ошибки от другого.
Что смотреть на первых прохождениях
Нас интересуют аномалии.
Например, почти все участники задачу выполнили, но один вопрос систематически пропускают. Возможно, он плохо сформулирован.
Или большинство людей выбирает вариант «другое» и пишет практически одинаковое объяснение. Значит, мы не предусмотрели очевидный вариант ответа.
Еще один сигнал — участники массово сообщают о затруднении в одном месте, хотя при внутреннем тестировании проблемы не возникало. Здесь нужно определить, обнаружили ли мы настоящую UX-проблему или допустили ошибку в прототипе.
На пилоте исправление исследования допустимо и ожидаемо. После полноценного запуска изменение вопросов или сценария уже создает две версии инструмента, результаты которых не всегда можно корректно объединять.
Время прохождения — это не только организационная метрика
Перед запуском полезно знать реальную продолжительность исследования.
Если команда обещает участнику 10 минут, а тест фактически занимает 25, вероятность незавершенного прохождения увеличивается. Но время интересно и с аналитической точки зрения.
Предположим, медианное время выполнения задания — около двух минут, а несколько участников справились за 15 секунд. Это повод посмотреть их результаты внимательнее.
Обратная ситуация тоже информативна. Если один сценарий у большинства занимает значительно больше времени, чем остальные, возможно, в нем есть проблема.
Но использовать время как прямой показатель удобства нужно осторожно. Более долгое выполнение не всегда означает худший UX. Человек мог внимательно изучать информацию, отвлечься или открыть исследование и временно отойти от устройства.
Поэтому время лучше рассматривать вместе с успешностью, маршрутами и ответами участника.
Не удаляйте аномально быстрые ответы автоматически
Фильтрация по времени кажется простой: все, кто прошел исследование слишком быстро, исключаются.
На практике такой подход может удалить валидные данные.
Опытный пользователь действительно способен выполнить знакомый сценарий намного быстрее остальных. Поэтому короткое время — это сигнал для проверки, а не автоматическое доказательство низкого качества.
Я смотрю на комбинацию признаков: продолжительность прохождения, выполнение заданий, последовательность ответов, качество открытых комментариев и прохождение скрининга.
Если несколько сигналов одновременно указывают на то, что человек практически не взаимодействовал с исследованием, оснований для исключения становится больше.
Отдельно учитывайте незавершенные прохождения
Респонденты, которые начали исследование, но не дошли до конца, тоже могут содержать полезную информацию.
Особенно интересно место прекращения.
Если люди равномерно покидают исследование на разных этапах, причиной может быть обычный естественный отсев. Если значительная доля прекращает прохождение после одного и того же задания, этот участок стоит проверить.
Возможно, задача слишком сложная. Возможно, не работает ссылка. Возможно, участнику непонятно, как вернуться из прототипа к вопросам.
Поэтому я не рассматриваю незавершенные анкеты исключительно как мусор. Сначала полезно посмотреть, где именно прекращается прохождение и есть ли повторяющийся паттерн.
При этом частично заполненные анкеты не следует автоматически смешивать с завершенными при расчете всех показателей. Для каждой метрики необходимо понимать, какие наблюдения входят в знаменатель.
Проверьте устройства и браузеры
Немодерируемое исследование проходит вне контролируемой лабораторной среды. Один участник откроет его на большом мониторе, другой — на ноутбуке, третий — на смартфоне.
Если устройство имеет значение для сценария, это необходимо контролировать.
Например, мы тестируем прототип мобильного приложения. Пользователь, открывший его на десктопе, взаимодействует с интерфейсом иначе: вместо пальца использует курсор, видит другое окружение и может иначе воспринимать размеры элементов.
Если исследуется десктопный B2B-сервис с таблицами и сложной навигацией, смартфон также способен создать искусственные трудности.
Поэтому до запуска стоит определить допустимые устройства и протестировать на них всю цепочку: страницу исследования, прототип, возврат к вопросам и отправку результатов.
Не меняйте исследование незаметно во время полевого этапа
Представим, что после 40 ответов команда замечает неудачную формулировку и просто исправляет ее. Еще 60 участников получают новую версию.
Теперь в одной выгрузке находятся результаты двух разных инструментов.
Иногда такое изменение неизбежно. Например, обнаружена критическая ошибка, из-за которой исследование невозможно продолжать. Но тогда момент изменения нужно зафиксировать, а результаты до и после него анализировать с учетом разных версий.
Небольшие на первый взгляд изменения тоже способны повлиять на данные: другое название кнопки в прототипе, дополнительная подсказка, переставленные варианты ответа или измененный порядок вопросов.
Стабильность исследовательского инструмента — одно из условий сопоставимости результатов.
Настройте сбор данных до рассылки
Перед запуском полезно заранее представить итоговую таблицу, с которой предстоит работать.
Такой мысленный переход от анкеты к будущему анализу обнаруживает много методологических пробелов.
Для самого сбора ответов можно использовать Тестограф (https://testograf.ru/): настроить анкету, разные типы вопросов и логику прохождения, а затем собрать результаты исследования в единой структуре. Особенно удобно заранее продумать ветвление — например, показывать дополнительный вопрос участнику, который сообщил, что не смог выполнить задание.
Важно, чтобы выбранный инструмент помогал реализовать методологию, а не определял ее. Сначала мы решаем, какие данные нужны, и только затем настраиваем под эту задачу анкету.
Контролируйте источник участников
Если исследование распространяется через несколько каналов, источник респондента иногда стоит фиксировать отдельно.
Например, одна часть выборки приходит из клиентской базы, другая — из исследовательской панели, третья — через приглашение внутри продукта.
Эти группы могут существенно различаться по опыту и мотивации.
Если объединить их без маркировки, различия в результатах можно ошибочно объяснить особенностями прототипа.
Это особенно важно при сравнении вариантов. Версию A нельзя преимущественно показывать действующим клиентам, а версию B — новым пользователям, а затем напрямую сравнивать показатели двух прототипов.
Заранее определите критерии остановки
Еще до запуска стоит решить, когда сбор данных будет завершен.
Для небольшого диагностического исследования это может быть достижение запланированного количества валидных участников и достаточное насыщение наблюдений.
Для количественного сравнения — заранее рассчитанная выборка.
Плохая практика — смотреть результаты после каждого десятого ответа и прекращать сбор в тот момент, когда цифры начинают подтверждать ожидаемую гипотезу.
Так исследователь незаметно получает возможность влиять на результат уже после начала эксперимента.
Поэтому размер выборки, основные критерии качества и условия остановки лучше зафиксировать заранее.
После запуска не спешите смотреть только на средние значения
Когда данные начинают поступать, первым делом хочется открыть сводку: процент успешных прохождений, среднюю оценку сложности, распределение ответов.
Но агрегированные показатели способны скрывать проблему.
Без контекста ответить невозможно.
Возможно, оставшиеся 22% — почти исключительно новые пользователи. Или все они остановились на одном и том же элементе. Или половина неуспешных прохождений связана с технической ошибкой прототипа.
Поэтому после завершения полевого этапа начинается не менее важная часть исследования — анализ. Нам предстоит соединить показатели выполнения заданий, время, ошибки, ответы на шкалы и открытые комментарии так, чтобы за процентами увидеть конкретные проблемы интерфейса и понять их приоритет.
После завершения сбора данных хочется сразу посмотреть на проценты успешных прохождений и средние оценки. Но анализ немодерируемого исследования я рекомендую начинать не с построения сводных показателей, а с проверки качества данных и возвращения к исходным исследовательским вопросам.
Наша задача — не просто получить набор UX-метрик. Нужно понять, где пользователи сталкиваются с проблемами, насколько эти проблемы системны и какие изменения прототипа могут на них повлиять.
Сначала подготовьте данные к анализу
До расчета метрик стоит проверить выборку по критериям, которые мы определили перед запуском.
Отдельно отмечаем технические сбои, незавершенные прохождения, респондентов, не соответствующих скринингу, дубли и другие случаи, качество которых вызывает обоснованные сомнения.
Важно не удалять неудобные наблюдения только потому, что участник вел себя неожиданно. Если человек неправильно понял интерфейс — это исследовательский результат. Если он не смог выполнить задачу из-за сломанного перехода в прототипе — это техническая проблема.
После такой проверки полезно создать для каждого задания несколько переменных:
В итоге вместо разрозненных ответов мы получаем структуру, которую можно анализировать по заданиям, проблемам и группам пользователей.
Начните с успешности выполнения
Одна из базовых метрик — доля участников, успешно завершивших задачу.
Если задание получили 50 валидных участников и 38 из них достигли необходимого результата, показатель успешного выполнения составит 76%.
Но я редко ограничиваюсь делением на «успех» и «неуспех».
Полезно выделять как минимум три состояния:
Такой подход позволяет не потерять сценарии, в которых формально все закончилось успешно, но путь оказался проблемным.
Если человек пять раз открывал неправильные разделы, возвращался назад и в итоге случайно нашел нужную функцию, записывать это прохождение в одну категорию с быстрым и уверенным выполнением не всегда полезно.
Процент успеха ничего не говорит без причины ошибки
Допустим, только 65% участников завершили задачу.
Эта цифра становится полезной лишь после того, как мы поймем, что произошло с оставшимися 35%.
Например:
Теперь перед нами уже не абстрактные «35% неуспешных пользователей», а несколько разных проблем.
Причем продуктовые решения для них будут различаться. В первом случае стоит проверить информационную архитектуру. Во втором — терминологию. В третьем — визуальную иерархию. В четвертом исправлять интерфейс вообще не требуется: необходимо устранить проблему исследовательского прототипа.
Поэтому в отчетах я предпочитаю показывать не только сколько пользователей не справились, но и какие типы затруднений сформировали этот показатель.
Анализируйте время вместе с поведением
Время выполнения задания кажется объективной метрикой, но интерпретировать его нужно осторожно.
Если пользователь выполнил задачу за 30 секунд, это может означать, что интерфейс понятен. Но может означать и то, что он почти не изучал информацию и случайно выбрал правильный путь.
Если другой участник потратил четыре минуты, он мог испытывать сложности. А мог внимательно читать условия тарифа перед подтверждением.
Поэтому время приобретает смысл в сочетании с другими показателями.
Например, полезно сравнить:
Кроме среднего значения я рекомендую смотреть медиану и распределение. Несколько очень длинных сессий способны заметно увеличить среднее время и создать впечатление, что типичный пользователь выполнял задачу дольше, чем это было на самом деле.
Сопоставляйте поведение с оценкой сложности
Один из наиболее информативных этапов анализа — сравнение объективного результата и субъективного впечатления.
Можно условно получить группы:
Последняя ситуация особенно интересна. Пользователь может быть уверен, что выполнил задачу, хотя на самом деле пришел к неправильному результату.
Например, он изменил адрес доставки в профиле, полагая, что тем самым изменил адрес для уже оформленного заказа. Интерфейс не вызвал ощущения сложности — проблема заключается в неверной ментальной модели.
Если смотреть только на субъективную оценку, такой сценарий можно вообще не заметить.
Кодируйте открытые ответы
При небольшой выборке комментарии можно прочитать вручную. Когда ответов становится несколько десятков или сотен, полезно использовать кодирование.
Сначала я просматриваю часть комментариев и выделяю повторяющиеся темы.
Например:
Затем комментариям присваиваются соответствующие категории. Один ответ может относиться сразу к нескольким темам.
Так качественные данные приобретают структуру. Мы можем увидеть не просто отдельные цитаты, а повторяющиеся модели: например, 18 из 60 участников упоминают отсутствие подтверждения после сохранения.
При этом я не рекомендую превращать любой открытый ответ в процент. Кодирование помогает увидеть масштаб темы, но свободные комментарии не всегда собирались как строгий количественный показатель.
Участники могут предлагать самые разные изменения:
Такие предложения полезно фиксировать, но не обязательно реализовывать буквально.
Респондент хорошо описывает собственное затруднение, но не обязан знать оптимальное дизайнерское решение.
Поэтому вместо «пользователь попросил перенести кнопку» я стараюсь сформулировать наблюдение уровнем выше:
Теперь команда может рассмотреть несколько решений: изменить расположение, визуальный приоритет, текст или структуру экрана.
Мы сохраняем проблему, но не привязываемся к предложенному участником способу ее исправления.
Ищите повторяющиеся паттерны
Один необычный комментарий может быть интересным, но несколько независимых участников, столкнувшихся с одной проблемой, — гораздо более сильный сигнал.
Например, один пользователь говорит, что искал настройки уведомлений в профиле. Это наблюдение.
Если 12 из 30 пользователей начинают поиск с профиля, хотя функция находится в разделе настроек проекта, перед нами уже паттерн поведения.
Здесь особенно полезно сопоставлять источники данных:
Чем больше независимых сигналов указывают на одну проблему, тем увереннее можно считать ее значимой.
Сегментируйте результаты по гипотезам
Общий показатель способен скрывать различия между группами.
Допустим, успешность задания составляет 72%.
После сегментации выясняется:
Теперь интерпретация меняется. Возможно, новая навигация сама по себе достаточно понятна, но конфликтует с привычками пользователей старой версии.
Именно поэтому сегменты стоит определить еще до запуска исследования.
Полезными могут быть сравнения по опыту использования продукта, роли, частоте выполнения задачи, устройству или версии прототипа — если эти признаки были связаны с исходными гипотезами.
А вот делить данные на десятки групп после сбора в надежде найти интересное отличие я не рекомендую. Чем больше сравнений, тем выше вероятность обнаружить случайную разницу.
Средняя оценка интерфейса редко дает ответ сама по себе
Представим результат:
Выглядит хорошо. Но что продуктовой команде делать с этим числом?
Без контекста — почти ничего.
Возможно, большинство поставило 5, а определенная группа — 2. Возможно, пользователи высоко оценили интерфейс в целом, но треть выборки не смогла выполнить критически важный сценарий.
Поэтому среднюю оценку я воспринимаю как один из индикаторов, а не как итог исследования.
Намного полезнее связка:
Она позволяет перейти от отчета к решению.
Составьте карту проблем
После первичного анализа я рекомендую собрать обнаруженные проблемы в отдельную таблицу.
Для каждой можно зафиксировать:
Например:
Пользователи ищут изменение способа оплаты в профиле, хотя функция находится в настройках подписки. Проблема встретилась преимущественно среди новых пользователей и в нескольких случаях привела к незавершению задания.
Такая формулировка гораздо полезнее, чем «раздел оплаты непонятный».
Отделяйте наблюдение от интерпретации
Это один из принципов анализа, который я считаю особенно важным.
Эти три уровня не стоит смешивать.
Наблюдение непосредственно следует из данных. Интерпретация объясняет возможную причину. Рекомендация предлагает действие.
Когда они разделены, команде проще обсуждать выводы. Можно согласиться с наблюдением, но предложить другую интерпретацию или другое решение.
Итог исследования — не отчет, а список проверяемых решений
Хороший анализ заканчивается не страницей со средними значениями, а набором приоритетных проблем и гипотез для следующей версии.
Для каждой значимой проблемы команда должна понимать:
И здесь исследование возвращается в продуктовый цикл. Мы не просто обнаружили, что пользователям трудно выполнить определенное действие. Мы сформулировали проблему, изменяем прототип и можем снова проверить тот же сценарий.
В финальной главе разберем, как расставлять приоритеты между найденными проблемами, какие результаты требуют немедленного изменения интерфейса, а какие лучше проверить дополнительно, и как превратить немодерируемые исследования из разовой проверки в повторяемый процесс работы с продуктом.
После анализа обычно возникает новая проблема: замечаний больше, чем команда способна исправить за одну итерацию. Один участник не заметил кнопку, несколько человек искали функцию в другом разделе, часть пользователей сомневалась после подтверждения операции, а кто-то предложил полностью изменить структуру экрана.
Переносить все замечания в бэклог как отдельные UX-проблемы — плохая стратегия. Результат исследования должен помочь команде определить, что действительно требует изменения, насколько мы уверены в выводе и что необходимо проверить повторно.
Отделите системную проблему от единичной реакции
Сам по себе комментарий участника еще не доказывает наличие проблемы интерфейса.
Представим, что один человек говорит:
Это полезное наблюдение, но недостаточное основание для редизайна.
Смотрим глубже. Пользователь долго искал действие? Другие участники испытывали похожее затруднение? Кто-нибудь вообще не смог закончить задачу? Встречаются ли в открытых ответах комментарии о незаметности кнопки?
Если несколько источников данных сходятся, сигнал становится сильнее.
Я обычно оцениваю проблему по трем вопросам:
При этом редкая проблема не обязательно незначительна. Если один участник столкнулся с ошибкой, которая в реальном продукте может привести к потере данных или неправильному платежу, ее критичность может быть выше, чем у часто встречающегося небольшого неудобства.
Используйте частоту вместе с критичностью
Для первичной приоритизации удобно использовать простую матрицу:
Частота показывает, насколько регулярно проблема встречается среди участников.
Критичность — насколько сильно она мешает достижению пользовательской цели.
Стоимость исправления помогает понять, сколько ресурсов потребуется команде.
Представим две проблемы.
Если смотреть только на частоту, первая проблема кажется важнее. Если учитывать последствия, приоритет может измениться.
Я бы не превращал такую матрицу в псевдоточную формулу с десятками коэффициентов. Ее задача — создать единые основания для обсуждения приоритетов, а не вычислить математически «правильное» решение.
Какие проблемы исправлять сразу
Некоторые результаты достаточно однозначны, чтобы перейти к изменению прототипа без дополнительного исследования.
Например, если участники систематически не замечают критически важное действие, потому что оно визуально выглядит как обычный текст, команда может подготовить более заметный вариант.
Или большинство пользователей ищет определенную функцию в одном разделе, а текущая структура помещает ее в совершенно неожиданное для них место.
Но даже здесь важно разделять проблему и решение.
Исследование может достаточно уверенно показать:
Но из этого еще не следует единственное решение:
Возможно, подойдет изменение состояния кнопки, отдельный экран подтверждения, текстовое сообщение или другой паттерн.
Исследование диагностирует проблему. Конкретное дизайнерское решение остается гипотезой, которую в важных случаях стоит проверить.
Когда нужно дополнительное исследование
Иногда данные показывают, что проблема существует, но не объясняют ее достаточно хорошо.
Например, значительная часть пользователей покидает определенный экран, однако открытые ответы не позволяют понять причину.
В такой ситуации я не рекомендую сразу переделывать интерфейс на основании предположений команды.
Полезнее провести несколько модерируемых сессий. Исследователь сможет увидеть поведение пользователя и задать уточняющий вопрос именно в момент затруднения.
Это хороший пример того, почему модерируемые и немодерируемые методы не нужно противопоставлять.
Немодерируемое исследование может показать масштаб и повторяемость проблемы, а модерируемое — помочь глубже разобраться в ее механизме.
После этого новую гипотезу снова можно проверить без модератора на более широкой выборке.
Не исправляйте интерфейс по принципу голосования
Если 12 участников попросили добавить определенную функцию, это не означает автоматически, что ее нужно добавить.
То же касается дизайнерских предложений.
Пользователь может точно описать собственную проблему:
Но предложенное им решение:
Сделайте огромную красную кнопку сверху,
— лишь один из возможных вариантов.
При анализе я стараюсь переводить пожелания участников в потребности или проблемы.
Не «добавить кнопку на главный экран», а:
Такая формулировка оставляет команде пространство для проектирования.
Сохраняйте связь между изменением и исходной проблемой
После исследования дизайнеры могут внести десятки изменений одновременно. В следующем тесте показатели становятся лучше — но мы уже не понимаем почему.
Поэтому для значимых изменений полезно вести простую цепочку:
Например:
Так исследовательский процесс становится накопительным: каждая следующая итерация связана с предыдущей.
При повторном тесте сохраняйте сопоставимость
Если мы хотим понять, помогло ли изменение, условия исследований должны быть достаточно похожими.
Желательно сохранить:
Если одновременно изменить прототип, задание, аудиторию и способ измерения результата, сравнивать две волны будет сложно.
Допустим, в первой версии 62% пользователей нашли функцию, а во второй — 81%. Разница выглядит убедительно.
Но если в новом исследовании мы дополнительно написали в задании название нужного раздела, улучшение может объясняться подсказкой, а не новым дизайном.
Не пытайтесь доказать, что новая версия «победила»
Повторное исследование полезнее воспринимать как проверку конкретной гипотезы, а не защиту работы команды.
После нескольких недель проектирования новой версии естественно хотеть увидеть улучшение. Именно поэтому критерии успеха лучше определить заранее.
Например:
Теперь после исследования мы проверяем конкретное ожидание.
Если результат не изменился, это не «провал теста». Мы получили данные о том, что выбранное решение не устраняет исходную проблему, и можем сформулировать следующую гипотезу.
Превратите исследование в повторяемый цикл
Наиболее полезным немодерируемое тестирование становится не тогда, когда проводится один раз перед большим релизом, а когда встраивается в процесс проектирования.
Рабочий цикл выглядит так:
На ранней стадии можно тестировать структуру и основные сценарии. Затем — более детальные взаимодействия. После запуска продукта исследовательские данные можно сопоставлять уже с реальным поведением пользователей.
При этом не каждое изменение требует отдельного масштабного исследования. Задача команды — соотносить стоимость проверки с риском решения.
Чем дороже потенциальная ошибка, тем больше оснований проверить гипотезу до разработки.
Итоговый чек-лист перед немодерируемым исследованием
Перед запуском я рекомендую проверить несколько пунктов:
Главное — не количество данных, а качество решения
Немодерируемое исследование дает возможность относительно быстро собрать данные от большого числа участников, но именно эта доступность иногда создает ложное ощущение надежности. Можно получить сотни ответов и все равно не узнать ничего полезного, если задание содержит подсказку, аудитория выбрана неправильно или вопросы не связаны с продуктовым решением.
В своей работе с исследованиями в Тестографе я стараюсь возвращать команду к простой последовательности: сначала определить решение, для которого нужны данные, затем сформулировать исследовательский вопрос и только после этого проектировать опрос.
Для организации такого исследования можно использовать Тестограф (https://testograf.ru/): собрать скрининг, задания и вопросы после взаимодействия с прототипом в единую последовательность, настроить необходимую логику и затем работать с полученными ответами. Но инструмент не заменяет методологию — качество результата по-прежнему определяется тем, кого мы исследуем, что именно спрашиваем и как интерпретируем полученные данные.
Хорошо проведенное немодерируемое исследование не должно заканчиваться формулировкой «пользователям понравился новый прототип». Более полезный результат звучит иначе: мы знаем, какие сценарии пользователи проходят самостоятельно, где возникают системные затруднения, почему они могут возникать и какие гипотезы необходимо проверить в следующей версии.
Именно в этот момент прототип перестает быть просто макетом для демонстрации, а исследование становится рабочим инструментом принятия продуктовых решений.