Немодерируемые UX‑тесты
Запустила в Достависте немодерируемые UX‑тесты, чтобы проверять решения до разработки. Настроила процесс в связке Figma, Maze и Intercom, вместе с командой описала его во внутреннем гайде и обучила дизайнеров и продакт‑менеджеров проводить тесты самостоятельно.
- Бриф
- Достависта
- Роль
- руководство проектом, исследование, обучение команды
- руководство проектом
- исследование
- обучение команды
- Формат
Контекст
Достависта работала на нескольких международных рынках, и продукт был локализован на несколько языков. Это осложняло классические модерируемые исследования: на каждом рынке нужен модератор, который свободно говорит на языке пользователей и знает продукт.
Немодерируемые UX‑тесты сняли это ограничение: мы проводили их без модератора и быстро набирали нужную аудиторию на каждом рынке.
Как проводили тесты
Начинали с цели: что именно хотим понять и какое решение проверяем. Затем формулировали гипотезы – конкретные предположения о том, что пользователь заметит, поймёт или сможет сделать. Из гипотез собирали задания, а под них – прототип. Если сценарий был длинным, делили его на несколько заданий.
Для каждого задания заранее закладывали основной и альтернативные пути. Поэтому после теста можно было смотреть не только, дошёл ли человек до конца, но и каким путём. До запуска определяли аудиторию, размер выборки и критерии успеха. Модератора рядом не было, поэтому задание должно было быть понятно без объяснений.
Фрагменты внутреннего гайда. Подготовка к тесту
Рекрутинг
Участников набирали через Intercom: выбирали нужный сегмент и показывали приглашение в подходящий момент. В сообщении коротко объясняли, зачем зовём на тест, сколько он займёт и что нужно сделать.
Фрагмент внутреннего гайда. Набор участников
Как оценивали результаты
Результаты разбирали на двух уровнях. Сначала смотрели сценарий целиком: сколько участников выполнили задание и каким путём. Затем смотрели экраны, где было много ошибочных кликов. Если доля ошибочных кликов превышала 20%, проверяли, какая доля участников прошла этот шаг с первой попытки.
Для команды зафиксировали ориентиры: 80% и больше выполняют задачу – сценарий работает; 60–80% — стоит проверить, что можно улучшить; меньше 60% — сценарий нужно пересмотреть.
Фрагмент внутреннего гайда. Анализ результатов
Пример теста: выбор страны
Приложение определяло страну автоматически, но иногда ошибалось – например, из‑за VPN или настроек устройства. Мы проверяли три гипотезы: понимает ли пользователь, какая страна выбрана и как её поменять; знает ли, где искать настройки страны и региона; может ли поменять страну через профиль.
Пользователи Wefast в Индии · выборка 100 человек
1. Вернуть локацию на Mumbai, India
Приложение открывалось с неверной страной и на другом языке. Нужно было вернуть India и Mumbai. 93 из 100 участников прошли задание; 86 из них – 92,5% — по основному пути.
Первое задание. Ключевые экраны
2. Сменить регион на São Paulo, Brazil
Во втором задании нужно было найти настройку региона внутри приложения. Уже на экране Orders было 75,8% ошибочных кликов, и только 46,5% участников нашли нужный путь с первой попытки. Гипотеза о том, что пользователи понимают, где искать настройки страны и региона, не подтвердилась.
Дальше сценарий работал заметно лучше: Profile – 74,5% прошли с первой попытки, выбор города – 81%, выбор страны – 60,5%. Интерфейс смены страны оказался для пользователей не самым понятным.
Тест помог определить проблему: критично было улучшить точку входа в настройки на экране Orders.
Второе задание. Ключевые экраны
Результат
Из трёх гипотез подтвердились две; не подтвердилась только гипотеза про поиск настроек. При этом 73% участников оценили сложность задания в 1–4 балла из 10. Значит, проблема была не во всём сценарии, а в точке входа: переделать нужно было экран Orders. Исследование помогло отделить локальную проблему навигации от сложности сценария в целом и понять, где именно требуется доработка.
Шкала сложности задания