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

Прочтёте за 4 мин.

Юрий Прудиус – о том, что может угробить ваш апп ещё до старта

IT-инструменты, которые использует Юрий Прудиус

  • Slack
  • Trello
  • Facebook

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

Досье

Юрий Прудиус, директор по развитию компании  WOXAPP, специализирующейся на разработке мобильных приложений. Образование: Национальный горный университет (Днепропетровск), специальность «системный анализ и управление». Компания WOXAPP работает на рынке мобильной разработки с 2011 года, у неё открыты офисы в Москве, Киеве и Днепропетровске.  

Юрий Прудиус

Ошибка первая: приложение - это новый канал продаж

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

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

App I

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

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

Ошибка вторая: а давайте закажем дизайн у веб-дизайнера

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

App II

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

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

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

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

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

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

Ошибка третья: сделайте как в айфоне

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

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

Ошибка четвёртая: зачем вам ТЗ, там же всё понятно?!

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

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

App III

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

Ошибка пятая: про синхронизацию подумаем в конце

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

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

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

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

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

App IV

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

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

Ошибка шестая:
смарт-часы, смарт-ТВ и Windows Phone посчитайте!

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

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

Ошибка седьмая: нужно всё предусмотреть в первой версии!

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

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

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

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

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

App V

Ошибка восьмая: о продвижении подумаем потом

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

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

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

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

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

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

App VI

Ошибка девятая: дайте оценку проекта сегодня

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

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

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

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

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

Источник: Cossa.

App Development


Читайте также:

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

04 июля 2017

Комментарии

1
  • Виктория Совина 11.03.2021 14:12

    На тему "не надо гнаться за всеми платформами сразу" - а что насчет кроссплатформенных приложений? Что, если разрабатывать приложения на Flutter - и релизиться сразу и на андроид, и на айос с меньшими затратами? Насколько это будет эффективно?

  • Задайте вопрос
    по автоматизации бизнеса

    Наши эксперты ответят на вопросы по автоматизации бизнеса


    Задать вопрос
    Ваш вопрос отправлен

    Ваш вопрос

    Введите Имя
    Введите E-mail
    Отправить Очистить
Возможно, вас заинтересуют другие наши материалы
Загрузить ещё
Идёт загрузка материалов