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

Понимание целевой аудитории

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

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

Сейчас растет проникновение мобильного интернета и формируется значительная аудитория из тех, кто не привык пользоваться компьютером. По данным КМИС, 40% украинских пользователей хотя бы раз в месяц заходят в интернет с мобильного. Варианты «с домашнего ноутбука» и «с домашнего стационарного ПК» выбрали по 30% респондентов. Есть много людей, которые могут позволить себе современный смартфон на базе Android, но вряд ли будут покупать компьютер. Бизнесу стоит задуматься: возможно, среди этих людей есть потенциальные покупатели?

Выбор платформы: iOS vs Android

Не каждая компания может позволить себе создание приложений одновременно на Android и iOS, потому как это два разных приложения. Выбрать одну платформу сложно, так что X денег, необходимых на разработку, превращаются в 2Х. Мы нашли компромиссное решение еще на старте: им стала технология React Native — фреймворк для разработки кроссплатформенных приложений, подходящих и для Android, и для iOS. Технология не без изъянов, но она позволяет существенно сэкономить: разработка на React Native обойдется примерно в 1,25X или 1,5X.

Конкретная стоимость и сроки зависят от набора функций, который необходим вашему бизнесу. Простой MVP можно реализовать за месяц-два. Стоимость формируется в основном из зарплат команды. В нашем случае в проекте заняты три разработчика, продуктовый менеджер, дизайнер и аналитик. Зарплата разработчика на React Native в Киеве на фуллтайм сейчас стартует с $1000, для миддл-специалиста — $2500–3000. UI/UX-дизайнер — около $1000 для миддл-уровня, product-менеджер и аналитик — примерно столько же, но они, скорее всего, у бизнеса уже есть. Что касается самого фреймворка, developer account стоит $100 на год. Работая только над приложением, такая команда сделает его за месяц, а значит, можно уложиться в $8000. Но важно понимать, что это приблизительная оценка (и по времени, и по финансам), потому что приложения могут сильно различаться в зависимости от нужд бизнеса.   

В нашем случае все началось с того, что четверо разработчиков, которые поддерживали в компании веб-разработку, сходили на хакатон по React Native. Вернулись с новыми знаниями, интересом к теме и желанием помочь любимой компании — и создали приложение буквально «на коленке». Мы опубликовали его в Play Market и App Store, но рассматривали скорее как приятную и полезную самодеятельность команды.

Серьезная работа над приложением началась, когда в компании изменились подходы к работе с клиентскими продуктами. Тогда мы начали более осознанно развивать это направление и приступили к проектированию новой версии, которая работала бы без багов, выглядела презентабельно, содержала необходимые и желательные клиентские функции. Именно ее, в эволюционировавшем виде, можно видеть сейчас в App Store и Play Market.

Короткий путь от задачи к решению

Следующий шаг — прототип с его набором функций. Здесь важно начинать с основной задачи пользователя. Вопрос «какое приложение нужно пользователю?» неправильный, потому что пользователю вообще не нужно приложение, ему нужен, например, билет на автобус. Но мы не можем сделать так, чтобы билет появился из воздуха. Понадобится телефон, в нем — приложение, а в приложении — условная «кнопка». То есть в любом случае будет какой-то интерфейс.

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

Дальше мы говорим о том, что пользователю, возможно, надо вернуть билет и получить обратно деньги. Но это уже вторая задача. Да, она важная, но другая, с ней надо работать отдельно. Определив список таких жизненно важных задач и решений для них, можно создать MVP, в котором путь от задачи к решению будет максимально коротким. Уже потом, поверх этого, стоит добавлять фичи, делающие путь более комфортным: указать название перевозчика, рейтинг, условия на рейсе. Сейчас мы работаем над тем, что даст пользователю ответ на вопрос «почему цены разные?» и поможет сделать выбор. Через пару лет приложение, вероятно, будет содержать фотографии, карту от точки отправки до точки прибытия, детализированный рейтинг, статистику перевозчика и другие подробности.

User-, task- и conversion-centered design

Мы используем три подхода к проектированию. Первый основан на эмпатии и так называемом task-centered design. Суть его в том, что мы определяем задачи пользователя и создаем максимально простое и эффективное решение. Чтобы понять задачи клиента, нужно идти на рынок и проводить интервью с целевой аудиторией, но мы, признаться, на первых этапах обошлись без исследования. Ресурсов на рисерч не было, так что мы просто опирались на свои знания о рынке и опыт разработки интерфейсов. Это самый экономный путь, который позволяет создать MVP с достаточным для покупки набором функций.

Далее уже стоит обратиться к user-centered design и опрашивать пользователей. Юзеры регулярно сообщают о том, что бы им хотелось улучшить в приложении. Мы рассматриваем каждую идею на предмет того, соответствует ли она бизнес-цели приложения. Здесь приходит время conversion-centered design. На каждом этапе есть конверсия пользователей из одного состояния в другое: скачал приложение — совершил поиск — перешел в подробности — в оформление — в оплату — совершил транзакцию. Оптимизируя приложение по запросу аудитории, мы ориентируемся на конверсию каждого узла. Все, что может увеличить конверсию, фиксируем. Так мы собираем набор гипотез с рынка, которые затем тестируем.

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

Платежи в приложении

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

Второй путь — оформить собственную лицензию. За 2-4 недели можно получить сертификат PCI DSS, который юридически позволит компании обрабатывать платежи и общаться с банком напрямую. Также нужно будет реализовать техническое решение, которое обеспечит безопасность платежных данных пользователей.

Решение зависит от целей компании и объемов платежей. К услугам Busfor прибегает порядка 3,5 млн посетителей в месяц, многие из которых в итоге приобретают билеты. При таких немалых объемах нам вполне хватает функционала сторонних платежных систем. 

Работа над ошибками: тесты и обновления

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

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

Кому это нужно?

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

Автор: Сергей Мулярчук, CTO маркетплейса для поиска и покупки автобусных билетов Busfor