Десять ошибок, которые провалят разработку мобильного приложения

Мобильное приложение может стать для интернет-магазина или онлайн-сервиса как драйвером роста, так и неэффективной инвестицией. Увы, большинство мобильных приложений остаются невостребованными у потенциальной аудитории и не приносят ни денег, ни лидов, ни удовлетворения владельцам бизнеса. О том, каких ошибок нужно избежать при планировании и разработке мобильного приложения, рассказал директор по развитию компании WOXAPP Юрий Прудиус.

Думаете, что мобильное приложение - это быстрый и дешёвый способ получить новый канал продаж? Вы разочаруетесь. Проследите, есть ли в цепочке поиска и принятия решения о покупке товара мобильное приложение? Будет ли покупатель искать информацию о вашем товаре в App Store или Google Play?  

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

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

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

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

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

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

• Применяют ненативные элементы и неуместную анимацию, что также увеличивает срок и стоимость разработки.
  
  

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

• Делают навигацию через «гамбургер-меню», что влечёт за собой проблемы. Например, для iOS нативно строить архитектуру через TabBarmenu. Про «гамбургер-меню» хорошо написано на  Econsultancy и  TechCrunch. 

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

Заказываете приложение для Android, но хотите там видеть «фишки» из iOS? Или дизайнер с айфоном считает, что так будет лучше в Android? Это проблема. 

Дизайн Android отличается от дизайна iOS. Использовать элементы одной операционной системы для другой - плохая идея. Во-первых, это сбивает с толку пользователей, во-вторых – сюрприз! - увеличивает сроки и стоимость разработки проекта. 

Иногда клиент приносит вместо технического задания готовый дизайн 10-12 основных экранов, считая, что остальное «и так понятно». Увы, разработчики приложений – не телепаты, и без подробного технического задания не могут сделать хороший продукт.

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

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

Программы бухгалтерского и складского учёта, CRM и ERP, телефония - приложение нужно встроить в системы, с которыми работает ваша компания. 

Сложность состоит в том, что: 

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

Например, для получения данных об одном товаре надо сделать восемь (!) запросов. Отсюда последствия: медленное получение данных - клиенты ставят «колы»; превышение лимита на сервере или любая серьёзная нагрузка - сервер лежит. 

Мобильное приложение - только небольшая часть системы: 

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

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

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

Не стоит гнаться за всеми платформами сразу. 

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

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

Как избежать разработки ненужных функций: 

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

• Тестируйте приложение на реальных пользователях как можно раньше. Опросите пользователей на стадии дизайна. Опрос можно провести среди клиентов, сотрудников вашего офиса или знакомых. Используйте  A/B-тестирование страниц приложений.

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

Используйте доступные каналы привлечения: 

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

• Привлекайте посетителей с помощью рекламы: контекста (Google AdWords, «Яндекс.Директ»), рекламы в магазинах приложений, баннерной рекламы или рекламы в социальных сетях. 

• Используйте  ASO-оптимизацию - работу с описанием, ключевыми словами, названием и визуальным оформлением.

С помощью ASO всего за два месяца мы увеличили количество посетителей страницы приложения в маркете с 49 до 173 тысяч в месяц. 

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

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

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

• развитие и поддержку продукта;
• продвижение и рекламу;
• стоимость аренды хостинга или сервера;
• стоимость размещения в магазинах Google Play и App Store.

Системы аналитики встраивайте в приложение ещё на этапе разработки. Начните с бесплатных систем (Google Analytics или Firebase). Рекомендуем внедрить Google ecommerce для мобильных приложений интернет-магазинов. Так вы сможете следить за поведением пользователей и опираться на полученные показатели при выпуске новой версии. 

Источник: Cossa.

Что такое CRM и зачем они нужны малому бизнесу.
Реальная автоматизация: что это такое и зачем она нужна малому бизнесу. 
Как сделать сайт более продающим: восемь полезных лайфхаков.
biz360