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

По данным The Standish Group, только 29 из 100 ИТ-проектов доходит до стадии успешной реализации. 52% разработок зависает в статусе «Спорные» и ещё 19% вообще никогда не добирается до этапа сдачи.

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

1. Приложение — это новый канал продаж

Думаете, что мобильное приложение — это быстрый и дешёвый способ получить новый канал продаж? Вы разочаруетесь.

Проследите, есть ли в цепочке поиска и принятия решения о покупке товара мобильное приложение? Будет ли покупатель искать информацию о вашем товаре в App Store или Google Play?

Успейте купить корпоративный пакет COSSA-2025 со скидкой!

Cossa анонсирует главный рекламный формат на весь 2025 год: сразу 8 различных опций.

Пакет идеально подходит для онлайн-сервисов, стартапов, интернет-компаний и digital-агентств.

Успейте приобрести пакет до повышения цены!

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

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

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

2. А давайте закажем дизайн у веб-дизайнера

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

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

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

  

  

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

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

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

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

3. Сделайте как в айфоне

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

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

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

4. Зачем вам ТЗ? Там же всё понятно!

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

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

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

5. Про синхронизацию подумаем в конце

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

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

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

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

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

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

Как заложить взаимодействие «клиент-сервер» со старта

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

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

Назначьте ответственных за реализацию работ.

6. Смарт-часы, смарт-ТВ и Windows Phone посчитайте!

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

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

7. Нужно всё в первой версии!

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

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

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

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

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

8. Какое продвижение? До этого ещё далеко

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

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

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

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

  

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

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

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

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

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

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

• развитие и поддержку продукта;

• продвижение и рекламу;

• стоимость аренды хостинга или сервера;

• стоимость размещения в магазинах Google Play и App Store.

10. Запустим приложение, аналитику добавим в апдейте

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

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

Не совершайте эти ошибки — и ваше приложение попадёт в те самые 29% успешно реализованных проектов. Желаем всем востребованных приложений!

Читайте также: Всё те же грабли, только в профиль, или Как избежать ошибок при развитии приложения?

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.