Мобильное приложение для стартапа

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

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

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

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

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

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

Для проверки идеи нужен лишь базовый функционал

Есть такая штука – MVP (minimum viable product, минимальный жизнеспособный продукт), к которому всегда необходимо стремиться, если это ваш первый проект. Сделать его, с одной стороны, просто, с другой – совсем наоборот.

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

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

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

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

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