Мобилизация. Как создать приложение, которым будут пользоваться

Меняем все, а потом еще раз и еще

Многие менеджеры считают, что разработка завершается, когда приложение выходит на рынок. Но релиз в Арр Store, первые пользователи – это не конец работы, а только начало. Настоящая работа начинается с момента, когда первый пользователь скачал приложение.

До сих пор вы делали предположения о правильном пользовательском опыте (UX), привлекательных особенностях и способах использования приложения.

Теперь вам предстоит проверить все наши предположения.

Является ли количество отправленных уведомлений чрезмерным и «напрягающим» или слишком низким и недостающим? Кому из ваших пользователей действительно нужна конкретная функция, не отвлекает ли она пользователя от выполнения поставленной перед ним задачи (например, покупки)?

Являются ли тексты, изображения и процессы использования оптимальными для ваших пользователей?

АВ-тесты должны проводиться снова и снова, даже после одного или трех лет использования.

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

Что это значит с точки зрения бизнеса?

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

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

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

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

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

Также нужно убирать из приложения те функции, которыми перестали пользоваться.

Кейс о том, как мы меняли приложение Moovit, посвященное общественному транспорту.

Мы придумали восхитительную фичу: возможность видеть на экране телефона, где едет автобус. Сейчас такая фича есть и в Uber, и в Яндекс. Такси, но тогда не было ни у кого.

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

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

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

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

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

В приложениях, посвященных заказу такси, он остался. Знаете, в чем разница? Автобус всегда едет по одному маршруту, а такси – по разным. Разработчики приложений такси знают расстояние между такси и тем, кто его вызвал.

Но как такси будет ехать ко мне – они не знают. Этот путь может занять минуту или десять. Приложение указывает приблизительное время: машина приедет через 3 минуты. Во время движения появляется надпись: еще 4 минуты, еще 2 минуты, еще 6 минут. И пользователю хочется знать, что происходит, почему время то увеличивается, то уменьшается.

Если к нам приходит заказчик и просит, условно, «Хочу, как в Uber. Там такси, а мы будем тоже показывать автобус», мы садимся и досконально разбираем: нужно ли показывать этот автобус. Решаем, во-первых, запускать ли его в начальной версии продукта или это недостаточно важная фича. Или вообще не выпускать, потому что в случае с автобусами, как нам помогли понять АВ-тесты, это не нужно.

Чтобы выбрать нужные фичи, мы строим концепции, макеты экранов, создаем графический дизайн, разрабатываем программное обеспечение и проводим АВ-тестирование. Проверяем все гипотезы, любое решение, принятое нами, даже если оно подкреплено настоящими контрольными группами – десятками людей, которые пытались пользоваться, но говорили: «не нравится то, другое, третье». Настоящие пользователи ведут себя по-другому.

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

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

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

Ну а если все наши усилия напрасны, внесенные благодаря АВ-тестированию изменения не улучшают показатели, – закрываем проект.

Умение вовремя убить проект – неоценимое качество в бизнесе.