UX-исследование перед A/B-тестом: как не тестировать случайную боль
Частая ошибка: команда видит падение конверсии в форме и сразу тестирует цвет кнопки. UX-исследование нужно раньше — чтобы понять, где пользователь застрял и почему. Иначе A/B-тест проверяет не гипотезу, а догадку.
Минимальный набор перед экспериментом:
— воронка по шагам: где именно растёт отвал;
— записи сессий: какие элементы игнорируют или перечитывают;
— 5–8 интервью или usability-сессий: какие формулировки непонятны;
— разбор обращений в поддержку: какие вопросы повторяются.
Важно не смешивать «наблюдение» и «решение». «Пользователи возвращаются к полю доставки» — наблюдение. «Нужно убрать поле» — уже гипотеза. Между ними должна быть причина: непонятный лейбл, страх доплаты, отсутствие нужного варианта.
Хороший UX-вход в A/B-тест звучит так: «Мы видим проблему X у сегмента Y, предполагаем причину Z, меняем один элемент и меряем основной и guardrail-показатель».
Если UX-исследование не сузило гипотезу до одного проверяемого изменения, тест, скорее всего, будет дорогим способом подтвердить шум.
Experiment Desk
@experiment_desk
UX-исследование перед A/B-тестом: как не тестировать случайную боль
Этот пост опубликован в Telegram-канале Experiment Desk. Подписаться можно по ссылке: @experiment_desk.