Оптимизация выдачи авиа
Как создавался интерфейс OZON.travel
Страница выдачи — это настоящая главная любого ОТА. Здесь пользователи получают предложения, делают выбор и принимают решение о покупке. Неважно, какими будут оставшиеся страницы — форма поиска и страница оформления заказа — они мало на что влияют. Достаточно, чтобы они минимально функционировали. Лучше, если при этом они будут выглядеть традиционно. Но страница выдачи авиа определяет лицо ОТА и его аудиторию.
Проектируя страницу выдачи авиа OZON.travel, я видел основную задачу в том, чтобы дать пользователям необходимую информацию и помочь выбрать нужную альтернативу среди множества вариантов при принятии решения о покупке авиаперелета. Другими словами, я относил Выдачу к классу систем поддержки принятия решения при многокритериальном выборе.
После недолгих рассуждений о критериях выбора и целевой функции все попытки автоматического решения задачи были отложены на будущее. Для практических целей предлагалась следующая схема:
- представить пользователю все богатство вариантов в агрегированном, удобочитаемом виде (согласно замыслу, это должно было повысить степень доверия к системе и удовлетворенность от конечного выбора — вот все варианты и других вариантов нет, больше выбирать не из чего);
- помочь исключить все неудачные варианты, оставив минимальное число альтернатив;
- помочь принять окончательное решение, сравнивая альтернативные варианты специальным инструментом, визуализирующим существенную разницу между ними.
Заказчика такая схема не удовлетворила из-за большого количества ходов: посмотри, исключи, сравни. Рассуждения были следующие: Выдача и так уже вторая страница после Формы, и переход на нее осуществляется с существенной задержкой на запрос данных. Требуется такое решение, где пользователь сразу получает однозначное готовое предложение и может переходить к оформлению заказа. И только если его что-то не устроит, нужно предлагать ему другие варианты. Логика в таком подходе есть, но я в него никогда не верил.
Примечательно, что мы так и не пришли к единому мнению, что привело к зашкаливающему количеству итераций (более 35). Идеал так и не был достигнут, глобальные цели утонули в частных деталях, а эксперименты с аудиторией были заменены на экспертное мнение сторон. К счастью, несмотря на все это, проект был успешно запущен и нашел свою аудиторию.
Вот одно из первых принципиальных решений Выдачи для OZON.travel (очевидно, на нем и следовало бы остановиться).
Это таблица, которая позволяет сравнить 4 варианта перелетов:
- Сегменты туда и обратно представлены в горизонтальных разделах;
- Хорошо акцентирована цена и авиакомпания;
- Плашки вылета и прилета раскрашены в разные цвета в зависимости от времени суток: утро — розовое, ночь — фиолетовая. Это должно упростить зрительное восприятие;
- Горизонтальное расположение значений по одному в ячейке делает сравнение простым и эффективным. Дополнительно предусматривался режим, убирающий совпадающие значения;
- Вариант, который не устраивает, удаляется пользователем, взамен система добавляет в таблицу новый. Если интерфейсно решить простую задачу: каждый раз сообщать системе, что именно не устроило в удаляемом варианте, появляется прекрасная возможность для интеллектуальных рекомендаций;
- Клик на колонке варианта позволяет перейти к оформлению заказа.
Следующей итерацией стал список всех предложений. Здесь есть практически все необходимое, под пересадки предполагалась отдельная колонка. Основная идея была проста: если расположить один вариант полностью в одной строке, то можно понимать весь объем предложений и удобно сравнивать варианты по интересующим нас критериям.
Главным достижением итерации стало понимание, что выбрасывание неудовлетворительных вариантов в итоге дает худший результат, чем отбор перспективных вариантов для дальнейшего сравнения.
Далее закономерно следовала попытка объединить оба подхода. Получалась несколько тяжеловесная конструкция, где был список предложений, который уточнялся системой фильтров, и сравнение отобранных вариантов.
Наконец, стоило попробовать сравнивать варианты прямо в списке предложений.
В финальной итерации был оставлен акцент на списке предложений, который позволял ориентироваться одновременно по цене и времени: вверху слева утренние дешевые рейсы, внизу справа - вечерние дорогие. Такой подход оказался практичным. Кроме того, можно было помещать варианты в избранное для сравнения.
Дальнейшее развитие темы велось факультативно. Была предложена визуализация выбранных вариантов для сравнения уже не в виде таблицы, а в виде графиков. Удалось объединить время (с учетом поясов), цену, продолжительность полета и пересадки. Надеюсь, такой подход найдет свое применение.
Очевидно, у ОТА нет возможностей экспериментировать с выдачей — они боятся распугать людей и потерять объемы. У стартапов тоже нет возможностей экспериментировать с выдачей — у них нет ни пользователей, ни данных. Поэтому выдача будет развиваться предельно консервативно. Хотя, если взять API и оптимизировать выдачу на собственной аудитории под продажу стратегу — это будет хорошее понятное дело.
