Контекст и команда
Я работал продуктовым дизайнером в юните Путешествий — части вертикали Недвижимости Авито. Юнит был разделён на команды по воронке: одна отвечала за верх (acquisition), вторая — за середину и низ; отдельная команда занималась персонализацией. Этот кейс сделан в рамках трека отелей, я работал на две команды сразу. Вокруг — два продакт-менеджера, исследователи, дизайнеры, frontend- и backend-разработчики. Полный цикл — от дискавери до результатов A/B-теста — занял три месяца.
Как устроена воронка
Пользователь попадает в Авито Путешествия через прямые переходы, рекомендации на главной или ссылки «поделиться». Дальше две точки входа: вертикальная главная (оттуда на страницу отеля приходят с заполненными датами) или сразу страница айтема — без дат. Со страницы отеля на мобильной версии можно либо быстро забронировать самый дешёвый номер, либо перейти на отдельную страницу офферов со всеми конфигурациями. На десктопе всё это — одна страница. Дальше — бронь и оплата.
Дискавери: сначала метрики, потом люди
В Авито регулярно проводятся Key-CJM — встречи с пользователями, на которых проверяются основные сценарии продукта. Мне выпало вести интервью по середине и низу воронки. Перед интервью я пошёл в метрики — чтобы прийти к респондентам с гипотезами, а не с открытыми вопросами. Нашлись две аномалии:
- Конверсия в страницу офферов на мобилках — около 3%. Страница, где живут все конфигурации номеров, практически не существовала для пользователей
- Разрыв среднего чека: 4 932 ₽ на мобилках против 6 423 ₽ на десктопе
Ключевая догадка: это не две проблемы, а два симптома одной. На десктопе конфигурации всех номеров видны сразу на странице отеля — и человек выбирает номер, который ему действительно подходит, часто дороже дефолтного. На мобилке конфигурации спрятаны за страницей, куда доходят 3%, — остальные видят только самый дешёвый номер.
Скрипт Key-CJM я составлял вместе с исследователями команды. Из 16 респондентов:
- 12 из 16 никогда не пользовались страницей офферов — большинство не знало о её существовании
- 5 из 16 отказывались от бронирования отеля на Авито, потому что не могли найти нужную конфигурацию: формат кроватей, питание, условия возврата. В отзывах пользователей — те же жалобы
Диагноз сложился: мобильный флоу физически прятал от пользователя выбор номера — и это резало и конверсию, и чек.
Дизайн-решения
Страница отеля
1. Убрать быструю бронь на самый дешёвый номер — все идут на страницу офферов. Самое спорное решение кейса: я добавил шаг в воронку. Интуиция подсказывает обратное — сокращай путь до оплаты. Но данные говорили, что шорткат вредил: он вёл на номер, который человеку не подходил, а страница с реальным выбором оставалась невидимой (3% конверсии, 12 из 16 о ней не знали, 5 из 16 уходили, не найдя конфигурацию). Быстрая бронь экономила тап тем, кто в итоге не покупал.
2. Звёздность — в заголовок. Ключевой параметр выбора отеля был закопан в глубине страницы. Сам паттерн мы переиспользовали из другой вертикали Авито (Авто) — внутри компании работает обмен проверенными решениями, и это дешевле, чем изобретать своё.
3. Фактоиды — быстрый обзор удобств отеля. Компактный формат, отвечающий на вопросы «что тут есть» без чтения простыни описания. Под фактоидами лежит отдельное большое исследование — оно тянет на самостоятельный кейс.
4. Перераспределение блоков по данным карточной сортировки. Мы провели карточное исследование: какие блоки важнее всего при просмотре страницы отеля — и пересобрали порядок страницы под реальные приоритеты пользователей, а не под исторически сложившийся.
Страница офферов
1. Пересекающаяся информация типа номера — в фактоиды. Убрали дублирование, характеристики читаются на скане.
2. Параметры конфигурации — отдельным блоком; отсутствующее — дизейблим, а не скрываем. Осознанный выбор: пользователь сравнивает номера side-by-side, и «здесь этого нет» — такая же важная информация, как «здесь это есть». Скрытие ломает сравнение: непонятно, отсутствует опция или просто не показана.
3. Квадратура — в заголовок номера. Один из первых параметров, по которым люди сравнивают номера.
Редизайн частично затронул и десктоп: перестановка блоков, логика дизейбла — паттерны выровнены между платформами.
Валидация: сначала юзабилити, потом деньги
Проверять решения сразу A/B-тестом — дорого: три месяца разработки ради гипотезы. Поэтому валидация шла в две ступени.
Ступень 1 — немодерируемые UX-тесты. Группы Control / Test1 / Test2..., два типа заданий: 400 респондентов на прохождение флоу заказа (по 100 на сценарий) и 300 на 10-секундные тесты (по 75).
Сценарии флоу: найти номер с одной двуспальной кроватью; найти самый дорогой номер без бесплатной отмены; найти самый дешёвый номер 17 м². 10-секундные тесты: найти сумму депозита и звёздность отеля — на старом и новом флоу.
Тесты на прохождение флоу заказа
- Контрольный тест со старым флоу
- Найти номер с одной двуспальной кроватью
- Найти самый дорогой номер без бесплатной отмены
- Найти самый дешёвый номер 17 м²
10-секундный тест
- Найти сумму депозита отеля (старый флоу)
- Найти звёздность отеля (старый флоу)
- Найти сумму депозита отеля (новый флоу)
- Найти звёздность отеля (новый флоу)
Контрольный (старый) дизайн проиграл по обоим типам заданий.
Ступень 2 — A/B-тест на проде. UX-тесты доказывают, что интерфейс понятнее, но не что он приносит деньги. После подготовки спецификации и передачи в разработку мы запустили полноценный A/B-тест на три месяца.
Результаты
Решение «удлинить» воронку, убрав шорткат, окупилось: пользователи, видящие реальный выбор конфигураций, бронируют чаще, чем пользователи с быстрым доступом к неподходящему номеру.