UX-исследование перед A/B-тестом: как не проверять очевидную поломку

UX-исследование перед A/B-тестом: как не проверять очевидную поломку

A/B-тест не должен отвечать на вопрос «понимает ли пользователь форму». Если 5 из 6 респондентов в тестировании удобства застревают на одном поле, это не гипотеза про лифт, а дефект интерфейса. Сначала чинится понятность, потом измеряется влияние на метрику.

Минимальный протокол:
— задача формулируется без подсказки решения;
— модератор не объясняет интерфейс и не спорит с участником;
— фиксируются не мнения, а события: пауза, возврат, ошибка, уточняющий вопрос;
— после сессии проблемы группируются по шагу в воронке и критичности.

Хороший результат UX-исследования — не список «пользователям не нравится». Это бэклог проверяемых причин: где теряется намерение, где ломается ожидание, где текст создаёт неверную модель действия.

Дальше можно ставить эксперимент: одна проблема, одно изменение, заранее выбранная основная метрика и минимальный эффект, ради которого тест имеет смысл запускать. Иначе A/B-тест превращается в дорогой способ подтвердить, что интерфейс был непонятен.