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

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

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

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

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

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

Итак, очередной чек-лист: как выбрать разработчика мобильного приложения, на какие именно критерии обращать внимание?

• Опыт разработки приложений на нужной операционной системе;

• Опыт разработки приложений схожей тематики и функционала;

• Временной прогноз на реализацию проекта;

• Ценовая ниша разработчика;

• Участие и победы в отраслевых конкурсах.

Что делать, если вы все же попали на недобросовестного разработчика? Уходить. По моему опыту, попытки дать недобросовестному разработчику исправиться приводили только к затягиванию сроков и увеличению бюджета.

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

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

Если вы не можете проследить за правильностью разработки, вы можете проследить за исполнением всех протоколов в процессе.

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

Торопиться или не спешить?

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

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

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

Это и есть та самая кочерыжка, MVP.

И только после первой версии постепенно добавляются фичи: оплата с помощью кредитной карты, квитанции об оплате, рейтинг таксистов.

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

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

Чаще всего заказчик знает, какие именно функции он хотел бы сделать в течение первого года.

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

Когда предприниматели спорят и хотят выпустить доведенный до идеала продукта не «полуфабрикат», я всегда привожу один и тот же пример.

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

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

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

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

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

На второе потрачена куча денег, пользователей нет, проверки только начинаются.

Как вы думаете, у кого больше шансов победить на рынке?

Дизайн

Мода на дизайн меняется очень быстро. Я бы не рискнул тут ничего советовать. Несколько лет назад, когда вышел первый iPhone,стало модно делать приложения, которые бы повторяли физический мир.

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

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

Мода изменилась, контент стали выводить на первый план, а кнопки сгладили. Теперь это был просто квадратик с надписью «купить».

Спустя некоторое время Google вышел с дизайном, который называется material design, объединяющий предыдущие тенденции, совместивший две вещи. Выпуклость, объемность, которая достигалась не градиентом элементов, а игрой теней.

Еще совсем недавно было очень модно рисовать «пятичасовые» тени, то есть вниз вправо (как на часах расположена цифра 5).

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

Появляются новые тенденции, разработчики переходят к чему-то другому.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Анализируем это

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

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

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

Скачали тысяча человек, купили сто из них – конверсия 10 %, приложение работает отлично. Если из тысячи купили единицы – у вас низкий процент продаж, нужно что-то менять в приложении. Выдвигать новые гипотезы и тестировать.

Проверять нужно все. Буквально – все. Это ключевой момент. В этом случае вы сможете максимально точно понять нужду своего клиента.

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

Ставим иконку «Бесплатно» или «Скидка» – они повышают продажи. Но иногда мы убираем эту иконку и продажи, как ни странно, повышаются.