Что бы вы почувствовали, если бы купили билет, а вам отказали в посадке из-за отсутствия визы? Корили бы себя за невнимательность? А что мог бы сделать сервис бронирования билетов, чтобы этого не произошло?

OneTwoTrip — онлайн-сервис для организации путешествий, поэтому задачи продакт-менеджеров сервиса часто связаны именно с тем, как помочь путешественникам разобраться в сложных маршрутах. Анастасия Мухина, продакт-менеджер в OneTwoTrip, рассказала студентам программы «Продакт-менеджер» реальный кейс из ее работы и описала весь путь продакта: от первых пользовательских сигналов до решения.


Кейс: «Мне отказали в посадке из‑за визы»

«Меня не пустили на рейс, потому что пересадка была в Лондоне, а я не знал, что нужна виза. Потерял деньги и полдня».

Формально пользователь сам не проверил правила транзита, но как продакт я сразу задаюсь вопросом: могли ли мы это предотвратить? Ведь незнание пользователя может обернуться для компании двумя негативными последствиями. Во-первых, из-за страха ошибиться и непонимания, нужна виза или нет, подходит такой билет или нет, человек может быстро уйти к конкурентам, у которых есть вся информация, или выбрать неудобный для себя перелет. Во-вторых, даже если пользователь все-таки приобрел билет без нужной визы и пропустил перелет, для компании это — потеря доверия и возвраты. Я расскажу, по какому продуктовому флоу мы двигались, чтобы решить эту проблему.

Сигнал

Жалобы, данные, поведение

Четыре главных источника сигнала в этом кейсе для нас были:

  1. Отзывы.
    «Меня не пустили в Лондон из-за визы и меня никто не предупредил!»
  2. Поведение, которое мы можем увидеть на данных.
    Показываем рейс — нет покупок — пользователь уходит.
  3. Поддержка.
    Возвраты, жалобы, вопросы по визам.
  4. Личный опыт.
    Мы сами бы не купили билет, не зная визовых правил.

Проблема

Что мешает пользователю?

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

На картинке — текст формулы: Пользователь не может [действие], потому что [барьер/отсутствие/непонимание].

В нашем случае пользователь не может принять решение о покупке, потому что не понимает, нужна ли виза при пересадке.

Что мы теряем, когда начинаем с фичи, ведь кажется, что решение на поверхности — просто предупредить о визе. Просто добавляем предупреждение → реализуем баннер «На пересадке может потребоваться виза» → показываем его для всего маршрута → пользователь пугается, закрывает бронирование → CR падает → команда: «Ну ок, не работает».

Решение через формулировку проблемы выглядит так:

Проблема
Пользователь не может понять, нужна ли виза на пересадке, и боится рисковать деньгами.

Гипотеза
Если объяснить, где нужна виза, и показать это в контексте выбора маршрута, пользователь примет более уверенное решение.

Решение
Показываем визовое предупреждение только там, где точно требуется виза: «Для пересадки в Лондоне вам потребуется британская виза» → добавляем ссылку «Как оформить».

Гипотеза

Как из проблемы получить рабочую гипотезу?

Чтобы ничего не потерять, я пользуюсь такой схемой:

Если мы покажем предупреждение о необходимости визы для пользователей, выбирающих рейсы с пересадкой в визовых странах, то снизится доля возвратов и вырастет CR, потому что пользователи будут заранее понимать визовые требования и принимать решение осознанно.


Решение

UX, логика, текст и продукт

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

  1. Показ в нужный момент, а не когда пользователь на этапе оплаты уже принял решение о перелете, а также только там, где есть реальный визовый риск.
  2. Понятная формулировка без лишней тревожности и онбординг по новой фиче.
  3. Реальная помощь пользователю. Если виза действительно нужна, то нам нужно рассказать, какие шаги и документы понадобятся для ее получения.
  4. Возможность измерения эффекта: CR, возвраты, жалобы, клики по сообщению.

Метрики

Как их выбрать и понять, что все сработало?

Принципы выбора метрики:

  • привязана к цели гипотезы
  • отражает поведение пользователя
  • изменяется при успехе
  • доступна и измерима

В этом кейсе мы отдали приоритет конверсии в бронирование маршрутов с пересадкой в стране, где нужна виза. При этом, добавив информацию о визе, мы могли оттолкнуть пользователей, ведь раньше кто-то из них даже не задумывался о таком. Если будет падение этой материки, мы сможем понять, что фича скорее отпугнула, а мы слишком негативно подсветили информацию.

Итерация

Что произошло после запуска?

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

Появились и косвенные сигналы: стало меньше вопросов в поддержку о визах, меньше негативных отзывов с формулировкой «никто не предупредил», а вовлеченность в дополнительную информацию по визам выросла. А наша основная конверсия в итоге не упала.

Что отличает продуктовое мышление?


Начинать с проблемы, а не с решения.
Не «что бы такое сделать?», а «в чем реальная трудность у пользователя?» И только потом — «а как именно помочь?»

Оценивать не фичу, а поведение.
Считаем не только клики, а изменения в действиях: доверился ли пользователь, сделал ли выбор, вернулся ли позже. Метрика — это зеркало поведения.

Думать о влиянии, а не о реализации.
Не «какую задачу мы закрыли в Jira?», а «какую проблему мы реально решили?» Даже маленькое улучшение может сильно повлиять на пользовательский опыт.


Поделиться