Маркетинг Бизнес
#Мнения

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

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

Иллюстрация: Оля Ежак для Skillbox Media

Объяснила, в каких случаях бизнесу нужно разработать своё приложение

Ирина Любимова

Руководитель по маркетингу в IT-компании Touch Instinct.

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

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

Миф 1


Мобильное приложение — «гигиенический минимум» для всех брендов

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

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

  • Трафик сайта. Проанализируйте, какой процент пользователей заходит на ваш сайт с мобильных устройств. Как показывает практика, разработка приложения будет оправдана, если таких пользователей больше 50%.
  • Повторные продажи. Удержание постоянных клиентов — одна из ключевых задач приложения. Для этого используют, например, пуш-уведомления, промокоды, сторис, акции. Поэтому мобильное приложение будет полезно для крупных ретейлеров — еду, косметику, одежду или электронику покупают часто.

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

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

    Если предполагается, что пользователи будут использовать продукт или услугу часто, из разных локаций и без регулярного доступа к интернету, стоит задуматься о разработке приложения.
  • Программа лояльности. Если у вашего бизнеса есть бонусная система, приложение тоже будет полезно. Например, когда компания «Дикси» запустила приложение с функциональностью бонусной карты, которая сначала действовала только в Поволжье, в первую же неделю в программе лояльности зарегистрировалось 30% пользователей в регионе.
  • Размер бюджета. Если на разработке сайта можно сэкономить — например, собрав недорогой лендинг на конструкторе, — то мобильное приложение обойдётся немного дороже. В среднем расходы на разработку MVP составляют 2,5–3 миллиона рублей, а стоимость полноценного многофункционального приложения обычно в несколько раз выше.

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

Миф 2


От вида приложения ничего не зависит

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

Нативные мобильные приложения. Их создают для конкретной мобильной платформы. Например, для ОС Android приложения пишут на языках Java, Kotlin, для iOS — на Objective-C и Swift.

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

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

Обычно так разрабатывают приложения с широкой функциональностью и большим количеством пользователей. Например, нативные приложения применяют банки, маркетплейсы, крупные бренды экосистем — Google, «Яндекс», Xiaomi и так далее.

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

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

Ещё кросс-платформенные приложения сложнее поддерживать — iOS и в Android реже добавляют обновления для них. Также в этих приложениях могут не работать или работать хуже некоторые «родные» для платформы функции.

Веб-приложения. Такие приложения создают по технологии PWA (progressive web apps) — с помощью неё сайт компании трансформируют в мобильный продукт. Простыми словами, PWA-приложения работают в мобильном браузере — их не скачивают в магазинах приложений, а устанавливают с сайта компании.

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

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

  • Когда в приложении простая функциональность и тратить время на сложную разработку бессмысленно. Например, такие приложения делают для информационных сайтов или для простых сервисов по выбору и заказу услуг.
  • Когда нужна временная альтернатива нативному или кросс-платформенному продукту. Так, в последние пару лет многие российские компании столкнулись с тем, что не могут выпускать приложения, например, для платформы iOS. Поэтому сейчас они используют веб-приложения.
Веб-приложение «Сбера» на iOS — альтернатива нативному приложению банка, которое удалили из App Store
Скриншот: Skillbox Media

Считается, что PWA-приложения могут заменить нативные. Но это тоже миф.

Миф 3


PWA — замена для нативных приложений

В России веб-приложения оказались на пике популярности, когда App Store и Google Play удалили 7 тысяч приложений компаний, подпавших под санкции. Многие компании стали предлагать пользователям PWA как эффективную альтернативу, которой не грозит удаление из стора. Но такие приложения всё ещё нельзя назвать полноценной заменой нативным.

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

Во-вторых, PWA заметно уступают нативным приложениям, если нужно использовать аппаратные возможности смартфона — например, камеру или Bluetooth. Может быть урезан доступ к функциям вроде календаря и списка контактов. Также PWA заметно быстрее расходует заряд батареи.

В-третьих, для PWA невозможна монетизация с использованием нативных магазинов приложений — потребуется интегрировать собственную платёжную систему. А ещё веб-приложения плохо поддерживаются операционной системой iOS.

Миф 4


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

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

Мобильная разработка развивается динамично, поэтому каждый тип приложений хорошо справляется со своими функциями. Основные различия между ними спрятаны «под капотом» — то есть в части, которая находится на сервере и не видна пользователям. К ней относятся исходный код, архитектура приложения, процессы обработки данных. Большинство пользователей вряд ли заметят разницу — и визуально, и в части удобства работы с приложением.

Миф 5


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

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

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

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

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

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

Вот основные преимущества инхаус-разработки:

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

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

Миф 6


Мобильное приложение — это мини-копия сайта

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

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

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

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

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

Миф 7


Чем больше функций в приложении, тем лучше

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

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

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

Подводим итоги

  • Мобильные приложения не нужны каждой компании по умолчанию. Перед тем как начинать разработку, проанализируйте трафик вашего сайта и объём повторных продаж, прикиньте, какие дополнительные запросы сможет обрабатывать приложение, и рассчитайте бюджет.
  • Мобильные приложения бывают трёх видов: нативные, кросс-платформенные и веб-приложения. От того, какой вид вы выберете, будет зависеть бюджет и скорость разработки, а также дальнейшая техподдержка приложения.
  • Самые простые и дешёвые в разработке — веб-приложения. Но лучше их применять только в двух случаях: когда нужна временная альтернатива приложениям других видов или когда приложению бизнеса не требуется широкая функциональность.
  • Разработку сложных приложений лучше не отдавать на аутсорс. Желательно собрать собственную команду. Так у вас будет полный контроль над процессами, а у команды — больше времени и возможностей для обсуждения деталей проекта и оперативного исправления ошибок.
  • Приложения и веб-сайт должны выполнять разные задачи, поэтому нет смысла копировать интерфейс и функции сайта в мобильном продукте. Вместо того чтобы добавлять много функций в приложение, лучше сфокусироваться на улучшении пользовательского опыта.

Другие материалы Skillbox Media о разработке приложений

Научитесь: Профессия Директор по маркетингу Узнать больше
Понравилась статья?
Да

Пользуясь нашим сайтом, вы соглашаетесь с тем, что мы используем cookies 🍪

Ссылка скопирована