Кейс UTair: разработка мобильного приложения за полгода и рост продаж на 300%

Руководитель мобильных продуктов UTair Наталья Бурдина о создании продукта в сжатые сроки с нуля.

Первое мобильное приложение авиакомпания UTair выпустила в 2014 году, и оно неплохо справлялось со своими задачами: бронирование авиабилетов и онлайн-регистрация на рейс. Число пользователей неизменно росло, хотя на тот момент приложением мы практически не занимались.

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

Так, с 2014 года количество регистраций на рейс через приложение увеличилось в семь раз, а с момента релиза обновленного приложения показатель вырос ещё на 60%. Конверсия продаж в новом приложении выросла на 300%.

Один из первых вопросов, который мы себе задали, приступая к реализации проекта: что лучше — переработать старое приложение или сделать новое. Для этого важно было оценить предстоящий объем работ. В частности, помимо внедрения новых решений, мы планировали по максимуму учесть комментарии пользователей.

Скажем, какое-то время в приложении не был представлен самый популярный тариф «Лайт» и в целом не было информации о тарифах. Также наши пассажиры высказывали недовольство «непонятным» интерфейсом.

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

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

Оценив объем необходимых доработок, мы поняли, что гораздо выгоднее и быстрее создать новое приложение, а не дорабатывать старое.

При выборе разработчиков мы, прежде всего, опирались на имеющийся у команды опыт и на предлагаемые сроки: для авиакомпании было критически важно получить новое приложение как можно быстрее. Среди других немаловажных факторов была общая стоимость работ (не будем скрывать, что в тот период UTair переживала не лучшие времена).

Чтобы выпустить приложение в максимально сжатое время, мы планировали сначала вывести MVP-версию и впоследствии дорабатывать и улучшать её. Мы объявили соответствующий тендер, и фактически все его участники указывали нам на то, что релиз первой версии состоится не ранее чем через год.

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

Помимо уже обозначенной выше цели по выпуску MVP за возможно короткие сроки, для нас была актуальна и ещё одна — расширить функциональность нужно было так, чтобы это не нарушало работу приложения.

Соответственно, поставленные перед командой задачи по стратегии разработки логично вытекали из целей:

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

И так далее — вплоть до 2019 года. Пока же подробнее остановимся на уже внедренных преобразованиях.

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

У сайта UTair сегодня одна из лучших конверсий — до 18%. Кстати, 62% бронирований переходит в статус оплаченных, а средняя конверсия от поиска до оплаты — 65%. Доля онлайн-регистраций — 30%, и она постоянно растет.

Также мы переосмыслили интерфейс приложения: убрали с экранов всё, что могло отвлекать (тени, лишние структуры), и укрупнили важную информацию. Как видно из скриншотов, нам приходилось дважды полностью менять дизайн.

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

Чтобы показать наш подход к процессу редизайна, рассмотрим пример с регистрацией на рейс. Приступая к этой работе, первое, что мы сделали, — нарисовали вайрфреймы, отталкиваясь от нескольких главных пользовательских сценариев:

Мы подготовили экраны, максимально учитывающие все эти пожелания, и запустили первую версию в работу.

Недостаток MVP-версии: в ней не совсем верно была спроектирована сквозная регистрация на рейс. Напомним, что речь идет о ситуациях, когда пассажир летит, например, через Москву в другой город, и ему нужно зарегистрироваться до конечного пункта, при этом в системе ставится отметка, что багаж перегружается без участия пассажира.

То есть изначально мы предлагали регистрироваться на рейсы по очереди, в рамках разных сессий. Это создавало трудности для пользователей, и нужно было срочно дорабатывать флоу.

Так, итерационным путем мы создали версию с удобной сквозной регистрацией сразу на все рейсы в заказе (даже если прямая регистрация на второй и последующие рейсы еще не открыта).

Интересной также оказалась работа над обозначением рассадки пассажиров. Так как на том этапе у нас не было статистики, мы решили создать фокус-группу, но её результаты оказались нерепрезентативны. Поэтому выбор мы все равно делали фактически на свой страх и риск.

В итоге запустили приложение, где серым были выделены занятые кресла, а синим — свободные. В целом, на взгляд большинства членов команды, это было понятное цветовое решение, хотя среди коллег встречались разные точки зрения. Со временем мы собрали статистику и поняли, что при выборе кресла 90% пассажиров кликают на синие места, что подтвердило правильность гипотезы.

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

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

Модульная система — очень эффективное решение, особенно для выбранного нами формата Agile. Думаю, многие знакомы с ситуациями, когда интеграционный код API еще не готов и завершить выполнение задачи не получается. Agile позволяет заморозить её и приступить к другой части проекта или, например, остановиться, чтобы исправить найденные баги и улучшить действующие сценарии.

Безусловно, трудности возникали. Например, отмечу случай, когда были готовы логика и дизайн, но необходимой функции не было в API. Тогда мы еще раз убедились в правильности нашего решения о смене архитектуры и заодно поняли, каким образом нам стоит оптимизировать собственную работу.

Еще один важный плюс выбранной системы — безопасность: теперь у интернет-хулиганов и мошенников нет возможности обрушить систему целиком, потому как каждый её отдельный элемент обладает дополнительной защитой.

Из текущих задач, стоящих перед нами, — максимальная интеграция сайта и приложения. Пока, к сожалению, не всё, что есть на сайте, есть в API. Этот вопрос мы планируем решить как можно скорее.

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

#Интерфейсы