Какие были лернинги когда пользователи повели себя в эксперименте не так как ожидал?

Ключевой кейс: неожиданное поведение пользователей в A/B тесте новой навигации

Я помню проект, когда мы проверяли радикальную переделку главного меню в SaaS платформе для управления проектами. Гипотеза была простая: вертикальное меню займёт меньше места и улучшит видимость фич. Но реальность отличалась.

Что мы ожидали

• Пользователи будут искать функции в новом меню за 2-3 клика
• Уменьшится среднее время поиска команды/проекта на 40%
• Упадёт количество поддержки тикетов о навигации
• Конверсия в платную версию не изменится

Что произошло на самом деле

В первую неделю тестирования данные сильно удивили:

1. Время в приложении выросло на 25% — пользователи дольше искали нужную функцию, хотя структура была логичнее
2. Bounce rate увеличился на 18% — люди выходили, не найдя нужное
3. Тикеты в поддержку упали, но не потому что улучшилось — много пользователей просто перестали искать и ушли в конкурента
4. Новые юзеры адаптировались лучше — но старые фрустрировались и ходили в старый интерфейс через браузер бэкапов

Главные learnings

1. Change fatigue — реальная боль для пауэр-юзеров Старые пользователи вложили кучу когнитивной энергии в изучение старого интерфейса. Новый был даже лучше логически, но они не готовы платить цену переучивания. Я недооценил инерцию привычки.

Вывод: Для power users нужен период адаптации и обучение. Мы добавили tooltips и пошаговый гайд, которые смягчили переход.

2. Часть функций оказалась скрыта для ролей После анализа видеозаписей юзеров обнаружил, что для некоторых ролей (например, Manager) определённые пункты меню были недоступны, но люди ожидали их видеть. Контекстное меню работало не интуитивно.

Вывод: Нужно было провести пользовательское тестирование с разными ролями до запуска теста. Мы пропустили важный сегмент.

3. Отсутствие clear CTA для ключевых операций Самое важное действие (создать новый проект) требовало дополнительного клика в новом меню. Казалось мелочью, но это привело к падению создания проектов на 12%.

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

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

Вывод: Всегда сегментируй эксперименты по платформам, если это критично для продукта.

Как я это применяю теперь

• Контролируемый rollout: вместо резкого переключения делаю постепенный для разных сегментов
• Юзер рисерч до AB: провожу хотя бы 5-7 интервью перед тестом
• Гранулярные метрики: смотрю не только общие, но и per-feature metrics
• Сегментация тестов: разбиваю по user cohorts, платформам, ролям
• Feedback loop: активно собираю качественный фидбак, не полагаюсь только на цифры

Этот кейс научил меня, что "data-driven" не значит "ignore qualitative insights". Иногда ответ на вопрос "почему тест упал?" находится не в графиках, а в разговоре с пользователем.