Мобилизация. Как создать приложение, которым будут пользоваться [Вадим Файнштейн] (fb2) читать онлайн

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

1

Прочитав эту книгу, вы:

○ поймете, как сделать приложение, которое не сотрут сразу после скачивания

○ подберете профессиональную команду

○ составите точное ТЗ для будущего продукта

○ монетизируете приложение и выведете его в топ Арр Store и Google Play

○ познакомитесь с трендами, которые повлияют на ваш бизнес

© Университет «Синергия», 2019

Погоня за будущим

Мобильная революция завершилась.

Мобильные приложения – давно уже не новый тренд, это стандарт ведения бизнеса.

Еще несколько лет назад концепция Mobile First была двигателем этой революции в ведущих корпорациях, а сегодня произошел сдвиг и такие гиганты, как Google и Apple, повернулись в сторону Al First. Для них мобильная революция – пройденный этап, ведь мобильные приложения захватили все сферы нашей жизни.

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

Футурологи много говорят об объединении человеческого мозга и компьютера, спорят лишь о том, когда оно произойдет, через 20 или через 50 лет.

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

И поскольку объединение уже произошло, напрашивается очевидный вывод: если ваш бизнес не имеет прямого доступа к мозгу клиента (посредством приложения, конечно же), скоро вы этого клиента потеряете. А возможно потеряете не клиента, а работника, так как доступ к его мозгу получит ваш конкурент.

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

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

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

В магазине приложений Google существует 3,8 млн приложений. Но поражает воображение не это число, а другое. 24 % приложений (то есть каждое четвертое) были открыты всего один раз после скачивания.

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

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

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

Общая оценка стартапов, с которыми мы работаем, превысила миллиард долларов.

Более 200 миллионов пользователей наших продуктов говорят, что мы знаем, что делаем.

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

Меня часто спрашивают: как сделать мобильное приложение, на что нужно обратить внимание в первую очередь?

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

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

Кому нужна эта книга?

Всем, у кого есть идея для разработки мобильного приложения

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

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

Собственникам бизнеса, менеджерам по внутренним процессам (HR, Operations и т. д.)

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

Примеры.

Решение проблемы дефицита рабочей силы

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

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

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

Оптимизация HR-процессов

Компания в сфере IT. Набор профессионалов высокого класса проходил несколько этапов:

1. Отбор кандидатов

2. Телефонное собеседование с руководителем группы

3. Фронтальное собеседование с руководителем группы

4. Технический экзамен с одним из технических руководителей

5. Собеседование с директором отдела

6. Собеседование с HR

После каждого этапа всю информацию о соискателе нужно было передать дальше.

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

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

Создали открытое приложение и для кандидатов, и для работников компании.

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

Процесс набора сократился на 5 недель!

Продвижение инноваций

Мы создали приложение для продвижения инноваций внутри компаний корпорации «Медтроник» – одной из крупнейших компаний в мире по производству медицинских девайсов.

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

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

Руководителям, отвечающим за ПО в корпорациях

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

Менеджерам по маркетингу

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

Инвесторам в IT

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

Разработчикам, графическим и UX-дизайнерам, менеджерам продуктов и софтверных проектов —

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

Пять уровней для создания приложения

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

Модель состоит из пяти уровней^[1].

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

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

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

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

Процесс разработки и планирования опыта взаимодействия начинается с верхнего уровня (стратегии) и постепенно проходит через все уровни до самого нижнего (поверхности).

1. Стратегия

Вы определяете, насколько удобно пользователю взаимодействовать с приложением.

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

2. Возможности

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

3. Структура

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

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

4. Компоновка

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

5. Поверхность

Внешний вид. Вы определяете, как будет выглядеть приложение внешне. Какие в нем будут картинки, кнопки и т. д.

5 УРОВНЕЙ ПОСТРОЕНИЯ УСПЕШНОГО ПОЛЬЗОВАТЕЛЬСКОГО ОПЫТА

Ищите кочерыжку!

Представьте себе два стартапа.

Один хочет создать идеальное приложение. На его разработку нужен год. За этот год рынок немного меняется, рождаются новые идеи. Еще полгода уходит на доработку. И вот через полтора года есть приложение – идеальное, по мнению его создателей.

Другой стартап за два месяца выпускает минимальную версию, которая решает только одну задачу. Он вкладывает немного денег в рекламу и внимательно следит за реакцией пользователей. Добавляет новые фичи^[2] в соответствии с их пожеланиями. Меняет свой продукт вслед за веяниями рынка. И через полтора года у него есть приложение, проверенное на деле, и пользовательская база.

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

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

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

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

Мы повстречали Нира Эреза (сегодня Нир – CEO Moovit), который стал нашим консультантом, адвайзером. Нир помог нам найти ядро нашего бизнеса. Как у капусты есть кочерыжка, основа для всех листьев, так же у каждого бизнеса, у каждого приложения или сайта есть ядро, которое держит все остальное. И мы стали аккуратно, листик за листиком, «раздевать» наш стартап, пока не нашли нашу основу-кочерыжку. У нас этой базой стало экскурсионное приложение, которое заменяет туристических гидов. С помощью GPS приложение водит пользователя по городу и рассказывает ему о достопримечательностях. Но мы на этом не остановились. Продолжали убирать листы, пока не остались с голым стеблем. Убрали чаты между пользователями. Потом чаты с гидами. Потом мы убрали умную фильтрацию экскурсий и оставили по десять экскурсий в каждом городе. Потом убрали еще и возможность добавления пользовательского контента.

К тому времени появились еще две команды, которые работали над похожими продуктами, – одна в Англии, другая в ЮАР. На разработку приложения понадобилось два месяца. И мы победили – первыми вышли на рынок, победили в нескольких конкурсах, о нас узнали, приложение было установлено на половине смартфонов в Израиле.

У маркетологов есть такой термин – minimum viable product (минимальный жизнеспособный продукт). Это самая ранняя версия продукта, у которой есть только самые необходимые функции. Такой продукт поможет собрать первую обратную связь.

MVP – это ваша кочерыжка. Без листьев. Без цветов и семян. Только белый стебель.

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

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

Миссия и цель

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

Например, миссия компании Kickstarter – помогать в разработке креативных проектов.

Миссия компании Moovit – облегчить передвижение по городу.

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

Но сегодня вы начинаете работать над своим продуктом, над его конкретной версией. Сформулировав миссию, переходите к определению целей. У каждой версии приложения должна быть конкретная цель: легкая, доступная и понятная каждому члену команды.

Цели очень простые. Обычно это конверсия, сохранение пользователей и виральностьдо есть способность продукта распространяться самостоятельно, без намеренного воздействия кого бы то ни было. В первой версии любого нашего приложения мы всегда хотим достичь максимальной виральности, чтобы каждый, кто скачал его, рассказал своим друзьям: «Все, все, скачивайте, используйте».

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

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

Нужно понять эту нужду и сформулировать ее в виде предложения.

Например:

Людям нужно удобнее передвигаться по городу

Людям хочется проще заказывать такси.

Затем эту нужду предстоит перевести в ваш продукт. Это и есть оставшийся процесс создания мобильного приложения.

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

Чтобы понять, какие цели у вашего приложения, спросите себя: чего мы хотим?

Ответ может быть таким, например:

Хотим, чтобы пользователь, который скачал приложение, заказывал такси только через него и вообще забыл про то, что такси вызывают по телефону.

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

У Самры была миссия. Ее песня называлась «Мир – это чудо». Ее миссия – создание чуда, воплощение мечты.

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

После того, как мы определили миссию, конкретную и понятную цель, задумались о пользователях (подробнее о том, насколько они важны, поговорим чуть ниже). Целевая аудитория Самры – подростки от 13 до 20 лет. Она пела для них.

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

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

И мы решили сделать приложение с постоянным полноэкранным видео в прямом эфире. Придумали двух идеальных пользователей (о том, зачем это нужно, – чуть ниже).

Пользователь #1 – это Паула, она живет в Польше. У нее есть мечта: стать певицей. Она хочет побеждать в конкурсах так же, как хочет победить Самра. Паула смотрит на нее и думает: «Я тоже так могу. Я тоже так хочу».

Пользователь#? – это Мигель,20-летний испанец. И у него есть мечта: Самра. Он смотрит на нее и думает: «Какая красивая, успешная, талантливая девушка. Я хочу быть рядом с ней».

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

Метрика удержания пользователя у нас была очень высокой.

Паула открывала приложение и смотрела, как Самра репетирует. Она говорила: «Я тоже так могу. Пусть она победит, потому что потом точно так же кто-то захочет, чтобы победила я».

И когда Самра у нее спрашивала: «Какую кофточку мне сейчас надеть – вот эту красную или эту желтую?», Паула ей писала: «Конечно, надевай желтую. Она подходит под цвет твоих глаз».

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

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

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

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

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

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

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

У нас были курьезные случаи, о которых писали в Facebook. Подросток ходил по младшим классам, показывал им приложение и говорил: «Так, смотрите сюда, мелюзга: берешь и скачиваешь сейчас это приложение с моим промокодом. А если ты его не скачаешь – ты…» И это работало. Это работало замечательно.

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

Есть одна распространенная ошибка, с которой мы сталкиваемся довольно часто. К нам приходят очень много людей, которые говорят:

– Мы хотим приложение, как Uber. Мы хотим приложение, как Airbnb. Это отличные продукты. Сделаем нечто похожее для наших клиентов, правда, у нас идея совсем другая.

Но мы сделаем похожую разработку – значит, у нас тоже будет работать.

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

Но почему этот подход в корне неверный? Потому что последняя версия Uber вышла год назад. Еще парулет над ней работали до выпуска. Начали придумывать еще где-то за год до этого. Итого года четыре.

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

Однажды к нам пришел именно такой клиент, произнес: «Хочу Uber». Нам не удалось переубедить его, уговорить сделать нечто инновационное. Мы писали приложение, похожее на Uber.

В это время выходит новая версия Uber. Клиент понимает, насколько новая версия оригинальнее предыдущей, насколько лучше того, что мы сейчас делаем.

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

Придумайте жизнь для Валеры

После того, как сформулирована «далекая» миссия и определена конкретная цель, вы должны задуматься о… Нет, все еще не о фичах, не о тех конкретных характеристиках, которыми наполнится приложение.

Как вы думаете, что важнее: ваша идея или ваш пользователь?

Если на одну чашу весов положить постоянную заботу о пользователе, а на другую суть вашей идеи – какая сторона окажется тяжелее для успеха приложения?

Независимо от того, что вы думаете, нет ничего важнее, чем ваш пользователь.

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

Мы создаем приложение только для него, он скачивает – и счастлив:

– Опа, я нажимаю на кнопку – и моя проблема решена по-настоящему. Мне не нужно путаться среди множества функций.

Знаете, почему это так важно? Возьмите самую удивительную и инновационную идею, которой раньше не существовало. Даже если вы выпустите такой продукт, через шесть месяцев вас «окружат» конкуренты. Скопируют и выпустят аналоги.

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

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

Людям больше не нужны приложения, и им точно не нужно ваше приложение, пока вы не убедите его в обратном. В среднем у взрослого на телефоне установлено 35 приложений: калькулятор, банковское приложение, дневник, почта, WhatsApp, Facebook, карты, музыкальный проигрыватель, YouTube, фотографии, Instagram, Amazon, кошелек, камера и некоторые другие. Для вашего приложения просто не хватает места.

8 среднем у взрослого на телефоне установлено 35 приложений.

А это значит, что ваши конкуренты сделают все, чтобы захватить это место.

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

Так что же делать?

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

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

Нужно проделать весь путь, «встать на поверхность Луны». Дойдите до пользователя, решите все его проблемы без того, чтобы он сам догадывался о действиях, нажимал три раза вместо одного.

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

Проиллюстрирую вышесказанное на примере.

Несколько недель назад я решил медитировать полчаса вдень.

Что было первым, что я сделал? Очевидно, что я установил соответствующее приложение.

Первым делом меня спросили, в какое время я хотел бы медитировать. Я принял героическое решение делать это в 7 утра. На самом деле не было ни одного дня в течение двух недель, когда я проснулся бы в семь. Что в итоге? Я не медитирую, мне больше не нужно приложение, и я начинаю думать о его удалении. В конце второй недели приложение присылает сообщение: «Мы заметили, что вы не можете проснуться в 7 часов. Хотите назначить другое время для ежедневной медитации?»

Подумайте за пользователя. Будьте на шаг впереди него, как бабушка, которая обеспокоена тем, что внук будет голоден, если его не накормить. Разве не было весело проводить время с бабушкой, когда вы были маленькими? Вы с удовольствием вспоминаете то время, потому что о вас заботились.

Истинная забота о клиенте в бизнесе конвертируется в его лояльность. Он останется с вами на долгие годы.

Я уже применил слово «пользователь» 32 раза. Но правда заключается в том, что не существует такого понятия, как «пользователь». Вашим приложением пользуются люди, и потребности, способности и восприятие вашего продукта у разных людей будут разными.

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

Если вы действительно поставите реальную и максимальную заботу о человеке на первое место в своих разработках, считайте, вы сделали 90 % того, что необходимо для успеха проекта.

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

Наши клиенты всегда много говорят о фичах (то есть функциях приложения), об идеях:

– Мы хотим сделать такое замечательное приложение, с большим набором функций…

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

– Все пользователи будут очень радоваться, используя наше приложение…

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

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

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

Однажды к нам пришел клиенте идеей сделать инстаграм-приложение, посвященное кошкам: всем нравятся котики.

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

Итоговая версия приложения значительно отличалась от первоначальной задумки.

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

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

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

Мы не говорим: «Все таксисты Москвы», а только: «Таксист Валера». Мы приходим к нему домой. Здесь у него трое детей, шумных и наглых. А еще – сварливая жена. И поэтому таксист Валера старается пораньше улизнуть из дома, в 6 утра уже уходит и возвращается к 23. Дома практически не живет.

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

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

Он сидит, листая страницы в телефоне. Устанавливает приложение, которое мы сделали только для него. Смотрит и думает: «А ведь это приложение для меня». Нажимает на кнопку, и приложение совершает то, что ему нужно. Его конкретная проблема прямо сейчас решена.

Валера берет это приложение и бежит к своим друзьям:

– Смотрите, что у меня есть. Нажал, и то, что мне нужно, произошло.

Друзья Валеры – такие же, как и он. Они устанавливают приложение. Так начинается виральное распространение продукта.

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

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

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

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

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

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

Люди ленивы. И в итоге они решат все свои ленивые проблемы. И это идеальная модель.

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

И снова: если этого не сделаете вы, всегда найдется кто-то другой. Именно его магазин, услугу, продукт и выберут пользователи.

Такие «магазины будущего» есть уже сегодня. Например, Walmart из США.

Они обнаружили, что у сервиса доставки есть одна существенная проблема. Даже если он работает замечательно, в короткие сроки. Покупателю обязательно нужно быть дома в тот момент, когда ему принесут пакеты с продуктами. Согласитесь, с точки зрения пользователя не совсем удобно. Нужно специально выбирать время, торопиться успеть домой, чтобы не пропустить курьера.

Что сделал Walmart? Здесь разработали и выпустили специальные кодовые замки, которые можно поставить в квартиру.

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

Walmart дает страховку на случай пропажи или порчи имущества.

Удобно? Очень. Пользователю мобильного приложения больше не нужно быть дома с 14 до 17, он может посвятить это время работе или другим делам.

Но и на этом Walmart не остановился. Это одна из первых компаний, которая продает продукты по подписке.

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

Сейчас уже можно так купить многие и многие продукты. Услугу предоставляет не только Walmart, но и Amazon.

Вернемся к нашему идеальному интернет-магазину и удобству пользователя. Помните? Именно его нужно всегда ставить на первое место при разработке любого мобильного приложения.

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

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

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

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

Может быть, приложение спрашивает: «Собираетесь ли вы купить выбранный шампунь и 5 товаров?» И в случае его положительного ответа сообщает, что товар ждет его на кассе. Потому что в магазине есть люди, которые собирают эти продукты и приносят на кассу.

Можно обойтись и без таких людей. У кассира на экране выскакивает форма, в которой написано: «У него в корзине в интернете лежит шампунь и 5 товаров. Спроси, не хочет ли он их приобрести сейчас». И кассир мог бы сказать:

– Мы зноем, что вы хотите купить. Возможно, вы забыли?

Если до, мы очень быстро вам это принесем //товар лежит там-то, идите и возьмите, не волнуйтесь, я вас подожду.

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

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

Пользователь выбрал что-то на сайте. У сайта нет возможности обратиться к нему напрямую (возможно, только через e-mail), а у приложения – есть:

– Валера, ты вчера положил в корзину шампунь.

Хочешь оплатить и забрать его?

Если я приобрел товар, то хочу знать, в каком статусе он находится по пути ко мне. Упаковали его? Сообщите мне об этом. Передали курьеру – и об этом сообщите. Находится в пути, приедет ко мне через два часа? Хочу и это знать.

Все время, начиная с момента, когда пользователь отдал свои деньги, он пребывает в растерянности, неведении до тех пор, пока не получит товар. У него в голове постоянно сидит мысль: что происходит? Даже если он не думает об этом активно, какая-то часть в подсознании контролирует процесс и не отпускает.

Облегчите жизнь пользователю. Он оценит эту заботу.

Вы знаете, куда мне идти. Потоки пользователя

Бывают ситуации, когда приложение нужно создать не для одного персонажа, а для нескольких. Как быть? Создать разные потоки. Один пользователь направо пойдет, другой налево, а третий – прямо. И везде дорога должна быть удобной и освещенной.

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

Скажем, ваша цель – покупка, конверсия в деньги.

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

Заполняются поля доставки, адреса, способа оплаты… Только теперь покупка состоялась.

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

Если человек положил какой-то продукт в корзину и вышел из приложения, то логично, что ваша цель – заставить его в тот момент, когда он откроет приложение в следующий раз, оплатить товар. Очевидный факт, но многие магазины, сайты, приложения этого не делают. Человек возвращается в приложение, на значке корзины горит цифра «2» (два товара он хотел приобрести). Разработчик не озабочен тем, чтобы человек зашел и оплатил корзину. Это можно сделать разными способами. Например, при открытии приложения выскакивает pop-up: «У вас в корзине находятся 2 продукта, нажмите здесь, чтобы завершить покупку». Или еще более грубо: приложение сразу открывается на корзине. Не на первом экране или, что бывает часто, на том месте, где человек был до ухода. Вы можете регулировать, где откроется приложение, куда направить пользователя. Это и есть поток, который вам нужен.

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

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

Тогда вводите новых пользователей и новые фичи для них.

Приведу пару кейсов.

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

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

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

Еще один кейс о потоках для разных пользователей.

Компания Espresso Club является одним из лидеров на израильском рынке кофе. Израильский рынок кофе очень интересен. Мы, как вы знаете, не очень в ладу с окружающим нас арабским миром. Но как хитрые евреи, мы у них постоянно забираем какие-то хорошие вещи. Так, мы у них забрали культуру кофе.

Чтобы выпить кофе, мы берем (раньше, по крайней мере, брали) турочку на одного человека – для маленькой чашки. А если кофе хотят попить несколько человек, мы брали несколько турочек.

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

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

Поэтому когда компания Espresso Club провозгласила своей миссией «просто пить кофе» и предложила капсулы для кофе-машин, то завоевала рынок очень быстро.

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

Но была одна загвоздка. Пить кофе стало очень просто. Но заказывать его было непросто.

Нужно было позвонить оператору и назвать номер своей учетной карточки. Хорошо, если человек, который хочет выпить кофе, его помнит. А если нет?

Оператор не мог найти запись в системе. Человек начинал нервничать:

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

В следующий раз, когда этот человек хотел заказать кофе, он откладывал звонок на день, потом еще на один, на неделю…

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

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

Мы сделали максимально удобное приложение, в котором есть только одна кнопка. Человек нажимает на кнопку и через 24 часа получает именно то, что хотел.

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

Когда наша секретарша должна заказывать кофе, то спрашивает каждого нашего программиста (они все разбалованы): «Какой кофе тебе заказать? Ты любишь такой или такой?»

Получает список и заказывает определенное количество разных сортов.

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

Топ-менеджеру нужно все эксклюзивное. Дорогая кофемашина, элитный сорт.

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

В системе онлайн-заказов, которая была создана для Espresso Club, мы определили 8 различных типов пользователей, и для каждого из них мы создали отдельные потоки (процессы) использования. Получилось 8 различных приложений, которые мы объединили в одной структуре.

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

Приложение меняется в зависимости от поведения пользователя. Если оно «понимает», что перед ним не секретарша, а человек, который хочет заказать кофе домой, то ведет пользователя по другому пути.

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

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

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

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

Но вам-то надо сейчас. Можно послать Push-уведомление, отправить смс-сообщение в случае, если пользователь удалил приложение и т. д.

Это очень важно: продумать заранее потоки пользователей, сделать под них фичи на первом, втором, третьем экранах.

С чего начинается сценарий поведения? Человек скачал приложение, открыл. Зарегистрировался.

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

В третий раз открыл – должен еще что-то. И так далее.

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

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

Хороший пример – приложение с игрой. Цель игры – заставить пользователя платить, покупая какие-то ресурсы, статусы и т. д. Но когда он первый раз открывает приложение, вам предстоит объяснить правила игры. Дать возможность поиграть.

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

Таким образом вы и строите потоки.

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

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

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

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

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

Путь от формулировки миссии и целей до сценариев может занимать от нескольких недель до нескольких месяцев (для крупных проектов).

После этого начинается традиционная разработка приложения. Но сначала вновь пересмотрите ваш MVP. Не добавили ли вы лишние листья к вашей кочерыжке?

Традиционная разработка приложения начинается с выстраивания юзабилити. Юзабилити (от англ, usability – «удобство использования») – это качественная оценка простоты и комфорта работы с сайтом. Пользователь легко находит нужную информацию, не теряясь в многочисленных функциях и кнопках. Желательно, чтобы при этом он испытывал еще и эстетическое удовольствие от пользования продуктом.

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

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

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

Натив или гибрид? Немного полезных технических знаний

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

О чем спорят? Объясню, максимально упрощая.

В 2007 году Стив Джобс придумал iPhone, в 2008-м Apple дала возможность под него делать приложения – на определенном языке программирования. Когда Google выпустил Android, приложения под него стали писать на другом языке.

Это и есть нативная разработка – прикладная программа, которую можно использовать на определенной платформе или определенном устройстве. Для iOS используются такие языки программирования, как Objective-C и Swift, для Android – Java и Kotlin.

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

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

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

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

Чтобы понять плюсы и минусы, проведем дуэль.

Раунд 1: опыт пользователя (user experience, UX)

Если для вас критично, чтобы ваш пользователь испытывал приятные ощущения от приложения, чтобы ему было удобно, добавляем очки в пользу натива. Например, если у вас интернет-магазин, комфорт пользователя – на первом месте (об этом мы говорили выше). Он либо купит у вас, либо не купит. Иначе говоря, либо случится конверсия, либо нет.

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

Результаты поединка: 1–0 в пользу натива.

Раунд 2: использование функций телефона

Если приложению требуются функции смартфона: камера, акселерометр (более точный, чем GPS-датчик измерения ускорения) и т. д. – то вам потребуется натив.

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

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

Результаты поединка: по одному очку в пользу натива и гибрида.

Результаты поединка: 2–1 в пользу натива.

Раунд 3: сроки разработки

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

Результаты поединка: 2–2 – ничья.

Раунд 4: быстродействие

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

Результаты поединка: 3–2 в пользу натива.

Раунд 5: стоимость разработки

При нативной разработке, которая работает в разных средах, в большинстве случаев вам понадобятся как минимум два отдельных программиста. Если вы решите разработать веб-сайт в дополнение к iPhone и Android, команда увеличится еще по крайней мере до трех программистов. Кроме того, каждый код (если говорить о нативной разработке) требует адаптации к различным версиям устройства при сохранении совместимости с прошлыми версиями.

Гибридные приложения требуют минимальной адаптации к каждому устройству. Здесь гибриды обязательно победят.

Результаты поединка: 3–3. Ничья.

Подытожим еще раз.

Итак, как же выбрать?

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

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

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

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

Задайте себе следующие вопросы:

1. Является ли UX неотъемлемой частью приложения?

2. Важна ли скорость выхода на рынок? (Например, попытка попасть в Арр Store перед потенциальными конкурентами)

3. Нужны ли вам различные уникальные функции?

4. Ограничен ли бюджет разработки?

5. Будут ли пользователи и приложение много взаимодействовать, что потребует высокой производительности?

6. Должен ли я начать с MVP, а затем разработать версию с другими функциями?

Если вы ответили «да» на четные вопросы, для вас подойдет гибридный способ. С другой стороны, если вы ответили «да» на нечетные вопросы, выбирайте нативную разработку.

Делать самому или выбрать исполнителя?

Это замечательно, если у вас уже есть слаженная техническая команда, обладающая нужными знаниями. Но что делать, если такой команды нет?

Вариантов всего два: набрать свою команду или обратиться к стороннему исполнителю.

Вариант первый. Набираете команду

Для разработки мобильного приложения нам нужны следующие специалисты:

1. Дизайнер UX

2. Графический дизайнер

3. 1 или 2 клиентских программиста (зависит от выбора гибридной или нативной платформы)

4. Программист серверной части

5. QA-менеджер – тот, кто отвечает за качество продукта (quality)

6. Руководитель проекта

7. Технический руководитель (может быть одним из программистов)

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

На первых порах не все специалисты нужны на полную ставку. Так, обычно дизайнер UX и графический дизайнер полностью заняты в начале проекта, но их время освобождается через несколько месяцев. Занятость руководителя проекта и QA-менеджера в небольших проектах не превышает 30 %. Например, проверка качества на первых этапах не нужна. По-разному заняты серверные и клиентские программисты.

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

Часто для создания команды нужен HR-специалист, что еще увеличивает бюджет проекта.

И все же у работы с собственной командой есть плюсы. Вот они:

• вы полностью контролируете разработчиков, а значит, и бюджет проекта;

• команда находится в одном офисе с маркетологами, бизнес-девелоперами, техподдержкой и «чувствует» ваш бизнес;

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

Теперь рассмотрим минусы.

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

• бюджет разработки увеличивается во много раз за счет простоя некоторых сотрудников из команды;

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

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

Вариант второй. Обращаетесь к подрядчику

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

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

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

Но не во всех компаниях есть такой специалист. Его иногда называют «адвокатом дьявола». Потребуйте, чтобы в команде был такой человек.

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

Теперь разберем плюсы работы с подрядчиком, их немало.

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

• Подрядчику гораздо легче оценить бюджет и время разработки, чем менеджеру, который только начинает работать с новыми работниками. В моей компании GLobalbit разница между предварительным расчетом бюджета и его окончательным вариантом в стандартных проектах колеблется в пределах 10 %.

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

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

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

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

Минусы в таком выборе тоже есть.

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

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

Что же делать? Правильнее применять комплексный подход.

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

Как найти «правильного» подрядчика?

В разработке программного обеспечения поговорка «скупой платит дважды» действует с непреодолимой точностью.

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

Разница в зарплате отличных программистов и начинающих или плохих достигает порой 500 %. А вред от плохого программного кода можно расхлебывать много лет (если вообще продукт попадет на рынок).

Порой решающим фактором в выборе подрядчика является цена.

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

Хотя правильнее все же смотреть не на бюджета на ROI – возврат инвестиций.

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

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

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

В конечном итоге все зависит от непосредственных исполнителей: от программиста, от дизайнеров, от дизайнера UX. Если они создают хороший продукт раз за разом, а не единожды, – значит, у них есть какой-то рецепт. Рецепты могут быть разными.

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

Количество скачиваний – критерий, к которому апеллируют многие подрядчики. Но он важен в первую очередь для коммерческих продуктов b2c, которые предназначены для конкретного пользователя, таких как Moovit, Instagram, Facebook и так далее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чем более опытен специалист, чем больше ошибок и прорывов он совершил в прошлом, тем больше верных предположений он сделает сейчас.

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

Я бы проверял каждый экран: заходит или не заходит пользователь, сколько времени находится на каждом экране, где «залипает», где выключает приложение.

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

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

Поэтому аналитикой занимаются специалисты-маркетологи (как правило), пытаясь детально ответить на возникающие вопросы. Где пользователь вышел из приложения, почему, совершая покупку, на экране «заполните адрес» пропал. Может быть, он отвлекся, потому что ему позвонили? Или не захотел заполнять слишком много полей, решил отказаться от товара, который уже лежит в корзине? А может, приложение ему показалось настолько неудобным, что он, раздражаясь, тут же удаляет его? Или он удалил его, потому что с его помощью быстро решил задачу? Важно понять разницу и решить, что с этим делать.

Знаете ли вы, что большинство людей стирают приложения во второй половине дня? Одной общей причины, почему это происходит, нет. Каждый раз мы выясняем ее снова и снова.

У нашего клиента из сферы электронной коммерции был очень высокий откат пользователей с сайта.

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

Мы объединили корзины на сайте и в мобильном приложении, и в 8 вечера посылали уведомление с напоминанием завершить покупку. Пользователю оставалось только нажать на кнопку «оплатить». Количество законченных заказов увеличилось в несколько раз.

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

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

После выпуска продукта на рынок очень важен контроль качества, и это отдельный этап. Существует два подхода.

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

Второй подход – работа с контрольными группами или с минимальным количеством пользователей.

После проверки мы выпускаем продукт на рынок для минимального количества пользователей. Сначала предлагаем его только своим друзьям и знакомым, это 100–200 человек, и просим их дать сигнал.

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

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

После этого выпускаем продукт для всех.

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

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

На что стоит еще ориентироваться, чтобы оценить эффективность приложения?

1. Количество скачиваний

Выше отмечалось, что показатель не очень информативный в некоторых случаях, но все же именно на него все смотрят в первую очередь. Если метрика высока, приложение попадает в топ Арр Store и Google Play.

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

2. ROI – коэффициент возврата инвестиций

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

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

3. Retention Rate (RR) – коэффициент удержания пользователя

Эта метрика показывает процент пользователей, которые вернулись к вам после скачивания. Показатель Retention Rate со временем падает, ведь часть людей от вас уходит, и ваша задача – сделать это падение более медленным. Чтобы рассчитать RR, нужно количество пользователей, запустивших приложение на первый (второй, третий, четвертый и так далее) день после скачивания, разделить на общее количество скачавших.

Эту метрику можно определить с помощью специальных сервисов сбора статистики.

Смотрим на примере.

Пользователи активно пользуются приложением в первую неделю запуска. Но спустя месяц в него возвращается лишь 20 % пользователей. Это говорит о том, что продукт содержит фичи, удерживающие пользователя вначале, но дальше потребность обращаться к приложению у него не формируется.

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

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

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

4. Количество / доля транзакций

Как и предыдущие два критерия, не всегда однозначная метрика.

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

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

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

Обратная связь

Обратная связь необходима.

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

Наверняка все видели под приложением нечто похожее:

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

Почти всегда такой пользователь эмоционально «прилепляется» к приложению.

Как настроить обратную связь?

Во-первых, когда вы знаете, что пользователь может быть недоволен, разочарован, не удовлетворен, – попросите его в приложении написать вам об этом: «Хочешь ли ты нам что-то написать, что-то сказать?»

Обнаружился какой-то баг, который видит пользователь? Приложение упало? Товар закончился на складе?

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

Человеку хочется, чтобы его замечали, хочется быть важным.

Почему обратная связь необходима? Потому что если пользователя что-то разозлило, ему нужно дать возможность выговориться. Если вы не предоставите такую возможность внутри приложения, то он пойдет в Арр Store, Google Play, и расскажет о наболевшем там.

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

Часто пользователи готовы и хотят помочь. Опубликуйте свой комментарий и e-mail:

– Пожалуйста, напиши нам такие-то данные. Мы будем рады, если ты сможешь нам помочь. Мы хотим это починить.

После того, как починили, не забудьте сказать об этом пользователю.

– Мы будем рады, если ты изменишь свой рейтинг и поставишь более высокую оценку.

Пользователи любят это делать.

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

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

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

А дальше негатив распространяется по цепочке.

Плохие отметки уменьшают рейтинг. Это значит, что, когда в следующий раз кто-то в Арр Store, Google Play начнет искать определенное приложение, среди множества похожих ваше не окажется наверху.

Обычно пользователь скачивает 3–4 приложения и выбирает между ними. Высокие оценки – первое, в пользу чего он сделает свой выбор.

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

Уменьшение количества скачиваний ведет к увеличению затрат на рекламу.

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

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

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

И это лучше всего сделать тогда, когда пользователь доволен.

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

В этот момент стоит показать человеку форму и обратиться с просьбой:

– Если ты доволен приложением, пожалуйста, оставь отзыв в магазине.

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

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

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

– Мы даем плохой сервис, но, пожалуйста, останься с нами. Мы очень тебя хотим.

Если вы обнаружили, что этот процесс неудобен пользователю, начинайте разработку следующей версии. А пользователю можно сообщить:

– Мы улучшаем процесс. Через месяц выпустим следующую версию – тебе будет очень удобно.

И тогда есть небольшой шанс, что он не сотрет приложение, а дождется следующей версии.

Обновление: как часто

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

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

У меня перед глазами всегда Facebook-мессенджер. Я не знаю, что именно они делают, но раз в две недели они сообщают без конкретики:

– Мы починили баги и добавили улучшения.

Благодаря этому я знаю, что приложение живет.

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

И к этому приложению я буду относиться так же.

Когда еще нужно обновлять приложение?

Во-первых, это стоит делать всегда перед выходом новых версий операционных систем, чтобы приложение работало оптимально.

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

Кроме этого, нет никаких правил.

Монетизация мобильных приложений

Существует несколько видов монетизации мобильных приложений, их можно условно разделить на 4 крупных.

Эти способы широко распространены и хорошо изучены.

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

Если у вас игра, вы можете выбрать рекламу или продажу игровой валюты внутри приложения.

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

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

Смотрите, что есть на рынке, проверяйте, какие способы наиболее выгодны. Обращайтесь к аналитическим отчетам и маркетологам-профессионалам.

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

Это случилось еще до того, как Siri научилась говорить на иврите и русском языке.

Мы выпустили приложение, которое умело выполнять около 50 голосовых команд типа «Позвони маме», «Пошли сообщение жене», «Я опоздаю на полчаса»», «Найди синхрофазотрон в Википедии»…

Чтобы его скачать, нужно было заплатить доллар. Во второй версии было всего три функции: послать сообщение, позвонить и поискать в Google. Дополнительные фичи, вроде рассылки или поиска в Википедии, мы сделали платными.

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

В бесплатной версии при посылке сообщений мы ставили ограничение на приложение в Арр Store. То есть пользователь говорил: «Пошли сообщение моей жене, что я буду через полчаса дома». Жена получала сообщение от пользователя, но не знала, что именно внутри. Ей требовалось скачать приложение, чтобы его прочесть, по тут же предложенной ссылке для перехода в Арр Store.

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

И так как было очень большое количество скачиваний, было также большое количество покупок.

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

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

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

Например, часто это делают владельцы бесплатных игр. Они вставляют GPS-трекер и благодаря ему знают, где находится обладатель смартфона.

Если пользователь часто посещает магазины хозтоваров, то ему можно показывать рекламу веников и посуды. Изображения нижнего белья такого пользователя вряд ли заинтересуют, разве что к 8 марта. Если иностранец приехал в Россию, ему вовремя покажут рекламу местных сотовых операторов и т. п.

Пользователем заинтересованы многие стороны.

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

Во-вторых, непосредственно рекламодатели. Google и Facebook очень любят такую информацию.

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

Еще один способ монетизации пользователей, который использует стартап, – это продажа компании и пользователей. Здесь речь идет в первую очередь о крупных корпорациях. Объясню на примере.

Facebook купил мессенджер WhatsApp. Казалось бы, зачем? Ведь у Facebook есть свой. Но что действительно интересовало Facebook, так это аудитория WatsApp. Она была значительно моложе. Молодые люди не использовали Facebook, считая его приложением для людей старшего возраста, пользователи Facebook старели.

Эти тенденции видели вкладчики Facebook, понимали, что в какой-то момент соцсеть перестанет быть актуальной, и забирали свои деньги.

Сегодня Facebook значительно «помолодел»: приобрел еще и Instagram.

Эта история демонстрирует, что не всегда платные услуги важнее числа пользователей. Например, услуги того же WhatsApp сначала были платными. Но потом от этой идеи отказались, сообщив, что возможность общаться теперь не стоит ничего. Здесь поняли, что огромное количество пользователей гораздо сильнее, чем то количество денег, которое они могут заработать на маленькой аудитории. Кстати, Facebook купил WhatsApp за 19 млрд долларов.

Вверх и вверх. 11 фактов о рынке приложений

Когда-то основная функция телефона «позвонить» перестала ею быть, теперь это лишь одна из многих возможностей смартфона. Мобильные устройства, а вместе с ними и приложения, прочно обосновались в жизни пользователей. Сегодня в магазинах Арр Store и Google Play насчитывается около 3,5 млн приложений.

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

1. 500 млн долларов потратили российские пользователи на мобильные приложения в 2017 году (по данным исследовательской компании Арр Annie). За год расходы россиян на мобайл выросли на 40 %!

2. В 2018 году рынок мобильных приложений вырос на 20 % – до 76 млрд долларов. Зафиксировано 113 млрд загрузок игр и приложений (по данным все той же Арр Annie). Рынок растет в первую очередь за счет расходов пользователей на игры. Именно игры приносят больше всего прибыли их владельцам. На втором месте по популярности такой способ монетизации, как подписки: пользователи охотно ежемесячно платят за доступ к каким-либо функциям или контенту.

В России самыми популярными и быстрорастущими стали категории «напитки» и еда», «здоровье и фитнес», «спорт» и «финансы». Россия вошла в топ-5 стран по количеству загрузок приложений, уступая Китаю, Индии, США и Бразилии.

Топ-5 стран по количеству загрузок приложений

3. До 6,3 млрд человек вырастет количество пользователей приложений во всем мире к 2022 году. Для многих потребителей мобильная платформа станет основным способом совершения покупок, независимо от канала продаж. Уже сейчас объем транзакций в приложениях растет за счет мгновенных банковских переводов и платежей третьим лицам, причем популярность последних еще больше укрепится за счет широкого распространения этих услуг как способа оплаты среди ритейлеров и продавцов, считают в Арр Annie.

Из-за того, что время, потраченное в приложениях, увеличится более чем в два раза, оборот денег на рынке приложений также возрастет. Уже через 4–5 лет траты в приложениях вырастут от 380 долларов до 1000 долларов на человека.

4. 6 трлн долларов может достичь оборот рынка мобильных приложений через три года. В 2016 году этот показатель составлял 1,3 трлн долларов. Драйвером роста станет рост объема покупок товаров и услуг в гипермаркетах, сервисах такси и туристических приложениях, к которым пользователи «привязывают» карты.

Огромное влияние на статистические показатели оказали такие гиганты, как Amazon и Alibaba, а также оплата сервисов такси Uber и путешествий, забронированных через приложения и содержащих кредитную информацию пользователя. Эксперты предрекают, что люди переключатся с покупок в физических магазинах на покупки через приложения. Все это приведет к тому, что мобильная коммерция (то есть оплаты товаров и услуг в приложениях) будет занимать до 95 % всего объема платежей уже через несколько лет.

5. 140 минут в день тратит на приложения среднестатистический пользователь смартфона. Нехитрый подсчет показывает, что это месяц в течение года. Ежегодный рост этой цифры составляет 10 %. К 2022 году аналитики прогнозируют рост в 2 раза.

6. Более 50 % пользователей смартфонов берут свои смартфоны в руки сразу после пробуждения.

7. 80 % пользователей заходят в соцсети с мобильных устройств.

8. Средние показатели конверсии смартфонов выросли на 65 % по сравнению со средними показателями конверсии на десктопах. И это еще одна причина уделить дополнительное внимание мобильному приложению.

9. В 2019 году мобильная реклама составит более 70 % всех расходов на цифровую рекламу.

10. 68 % западных компаний интегрировали мобильный маркетинг в свою общую маркетинговую стратегию. Кроме того, две трети маркетологов (70 %) считают, что мобильный маркетинг является основой их бизнеса. Более половины опрошенных компаний в одном из исследований сообщили, что набрали специальную команду для мобильного маркетинга.

11. По состоянию на начало 2018 года, Samsung – ведущий производитель телефонов (с долей 32 %), за ним следуют Apple и Huawei. Даже если все в вашей команде фанаты iPhone, помните, что на самом деле во всем мире устройства Samsung более популярны. Обязательно протестируйте и этот опыт тоже.

Рейтинг производителей смартфонов

Данные на январь 2018 г.

Источник: агентство StatCounter

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

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

Также аналитики предрекают успех «визуальным» приложениям – наслоение контекстной информации на картинку реального мира становится все популярнее. Дополненная реальность (Augmented Reality, AR) выходит за рамки развлечений.

Google и Apple вывели AR на новый уровень и сделали ее доступной. Обе компании выпустили киты для разработчиков – Apple запустил свой ARKit, a Google – платформу ARCore. А это означает, что разработка и использование приложений на базе AR многократно возрастут. Люди будут пользоваться AR с удовольствием, поэтому те, кто будет создавать такие приложения, получат преимущество на рынке.

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

Становятся все популярнее мгновенные приложения (Instant Apps). Пользователям не нужно будет загружать приложение, чтобы понять, насколько оно полезно. Цифровые магазины обеспечат простую платформу, где пользователи смогут легко попробовать приложение и оценить его функциональность и удобство. Нововведение поможет решить проблемы с памятью в смартфонах.

Что готовит нам будущее?

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

Давайте задумаемся, в каком настоящем мы живем.

В своем кармане я ношу телефон. И это не тот аппарат с дисковым набором, которым пользовались наши родители. Мой телефон – это суперкомпьютер с доступом к практически любой информации, которая есть у человечества. Этот суперкомпьютер в 120 миллионов раз более мощный, чем тот, который послал человека на Луну. И все это находится у вас в кармане!

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

И в эти альбомы и истории он включит места, в которых я побывал, и людей, с которыми я повстречался.

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

Сегодня люди работают над колонизацией другой планеты. Это звучит нереально. Компания «Спейс Икс» запланировала через 10 лет посадить человека на Марсе. И это наше настоящее, уже не будущее. Это не зеленые человечки откуда-то прилетают к нам. Это мы – вот эти зеленые человечки. Это мы летим к ним.

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

Тренд #1. Голос

Общайтесь со своим пользователем не только посредством картинок и текста, но и с помощью голоса. И не только говорите ему, но и слушайте.

Ваш пользователь должен не только иметь возможность вбивать текст в поисковую строку. Предоставьте ему право голоса. Это можно делать внутри приложения и посредством Siri или Google Duplex.

Чтобы заказать такси, уже сегодня мне не нужно открывать Uber. Мне достаточно сказать: «Siri, закажи мне такси». Мне для этого даже не нужно поднимать телефон. Он лежит у меня в кармане, Siri постоянно меня слушает. Siri уже связывается с сервисами Uber, и через несколько минут такси ждет меня около дома.

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

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

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

Те из вас, кто владеет английским языком, обратят внимание еще и на то, что робот так же, как и человек, вставляет лишние слова. Вместо того, чтобы сказать, например, «женская стрижка», робот говорит: «Ну пока, наверное, просто женская стрижка».

В первых прототипах Google голос не был столь естественным и «человекоподобным» (да, да, Google тоже проводит бесконечные тестирования для того, чтобы улучшить продукт для своего пользователя). Людям не нравилось, как неестественно звучала синтезированная речь. Поэтому после нескольких прототипов и многих-многих брошенных трубок у Duplex появились такие речевые недостатки, как «ахи» и «хмыканья», играющие важную роль в коммуникации людей.

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

На презентации был представлен реальный диалог робота с администратором салона:

– Здравствуйте, чем я могу вам помочь?

– Привет! Я звоню, чтобы записать свою начальницу на стрижку. На третье мая.

– Да, конечно, одну секунду.

– М-м-м…

– На какое время?

– На 12 часов.

– В 12 не получится, но можно записаться на 13:15.

– А есть что-то между 10 и 12?

– Зависит от процедуры. Что ее интересует?

– Ну пока, наверное, просто женская стрижка.

– Хорошо, есть время в 10.

– В10 устроит.

– Как ее зовут?

– Лиза.

– Хорошо, записала Лизу на третье мая в 10 утра.

– Отлично, спасибо.

Вы все еще уверены, что сумеете по телефону отличить робота от человека?

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

Тренд #2. Искусственный интеллект

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

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

Тренд #3. Настроение

Работайте с настроением пользователя. Есть системы, алгоритмы, которые помогают понять настроение у пользователя телефона: грустный он, веселый, энергичный или меланхоличный.

Дайте своему пользователю соответствующий контент. Он грустный? Развеселите его. Ему нужна поддержка? Поговорите с ним. Если он веселый, энергичный – скорее всего, значительно повышаются шансы, что он сейчас совершит покупку. Продавайте ему в этот момент.

Тренд #4. Хабы

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

Например, приложение Moovit, которое ищет маршруты передвижения с помощью общественного транспорта (метро, автобусы, трамваи и так далее), является хабом для любого передвижения по городу. Через приложение можно вызвать такси, взять в аренду велосипед и еще много всего.

Тренд #5. Делайте ваше приложение персонализированным для каждого пользователя

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

Говорите на языке пользователя, и вы достигнете своих целей.

Заключение

Я хотел бы вас кое о чем попросить.

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

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

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

Спасибо!

Примечания

1

Модель предложена специалистом по информационной архитектуре, сооснователем консалтинговой фирмы Adaptive Path Дж. Гарреттом.

(обратно)

2

Фича – (от англ, feature особенность, необычное свойство, «фишка») – сленговое обозначение каких-либо необычных признаков; функция, способность делать что-то.

(обратно)

Оглавление

1

Погоня за будущим

Кому нужна эта книга?

Пять уровней для создания приложения

Ищите кочерыжку!

Миссия и цель

Придумайте жизнь для Валеры

Вы знаете, куда мне идти. Потоки пользователя

Натив или гибрид? Немного полезных технических знаний

Делать самому или выбрать исполнителя?

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

Дизайн

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

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

Обратная связь

Обновление: как часто

Монетизация мобильных приложений

Вверх и вверх. 11 фактов о рынке приложений

Что готовит нам будущее?

Заключение

*** Примечания ***