10 основных ошибок при разработке мобильных приложений | AppCraft | Статьи
9 мин.

10 основных ошибок при разработке мобильных приложений

Содержание

  1. Слишком много функционала
  2. Игнорирование различий между iOS и Android
  3. Плохая архитектура бэкенда
  4. Дизайн для себя, а не для пользователей
  5. Нет маркетинговой стратегии
  6. Не организовано тестирование
  7. Нет обратной связи с клиентами
  8. Нет поставленных целей
  9. Отсутствие гибкости
  10. Агрессивная монетизация

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

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

По нашему опыту наиболее часто встречаются следующие ошибки:

1. Слишком много функционала

Мы работали и с заказчиками из Германии, отличающимися, как водится, педантичностью и вниманием к деталям. Они работают так:

  1. Определяются с идеей;
  2. Неделю собирают весь возможный функционал, который можно реализовать;
  3. Еще неделю выбрасывают все лишнее;
  4. Начинают с одного-двух оставшихся пунктов.

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

Функционал мобильного приложения в начале разработки должен быть простым
Начинать с такого объема функционала – не очень хорошо

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

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

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

2. Игнорирование различий между iOS и Android

iOS и Android – разные операционные системы. Они имеют разные подходы к дизайну, навигации, монетизации и другим сторонам пользовательского опыта.

iOS и Android имеют разные принципы построение дизайна
Системы навигации iOS и Android существенно отличаются

Кроссплатформенные решения или нативная разработка – отдельный вопрос, свои мысли о котором мы подробно описывали в этой в этой статье.

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

  1. Android устройства имеют физические навигационные кнопки, iOS девайсы – нет;
  2. Интерфейс Android строится на основе Material Design, имеющего глубокую концепцию. Принципы iOS интерфейса проработаны в том числе и с учетом аппаратных особенностей устройств. Они подробно описаны в Apple Human Interface Guidelines. Это совершенно разные принципы построение UI/UX;
  3. Эти операционные системы имеют разную аудиторию, которую нужно анализировать для каждой ниши. Для какого-то приложения распределение типов ОС будет 50/50. Для другого 10/90;
  4. Монетизация строится по-разному. Пользователю Android сложно продать подписку, в то время как к рекламе он гораздо более терпелив. В iOS развиты глубокие продажи, когда подписка продается несколько раз со все более расширенными опциями;
  5. iOS устройства обновляются массово, в то время как версии Android сильно фрагментированы: более 30% девайсов используют Android 5.0 и более ранние, выпущенные до 2014 года.

Игнорировать эти особенности можно только на самых первых тестовых шагах прототипа, когда подтверждение гипотезы возможно без создание полноценных мобильных приложений.

3. Плохая архитектура бэкенда

Часто бывает так, что в проектировании делается акцент прежде всего на то, что видно. Это понятно и естественно.

Однако бэкенд – серверная логика, структура базы данных, набор подключаемых внешних сервисов – имеют не менее важное значение.

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

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

4. Дизайн для себя, а не для пользователей

Дизайн мобильного приложения – один из краеугольных камней всего процесса разработки продукта. Это единственная видимая часть результатов всей работы.

Наиболее частая ошибка в дизайне – подстраивать интерфейс под свой вкус.

Мы делаем продукт не для себя. Мы делаем его для пользователей.

Дизайн мобильных приложений стоит разрабатывать для пользователей, а не для себя
Вам может нравиться ваш дизайн. Пользователям – нет.

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

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

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

5. Нет маркетинговой стратегии

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

Мобильное приложение – это инструмент. Маркетинг – это способ его использования. Нельзя сначала сделать какую-то штуку, что-то среднее между молотком и пассатижами, а потом искать ей применение. Инструмент делается всегда под конкретную задачу.

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

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

6. Не организовано тестирование

Речь не о тестировании на наличие ошибок в коде – это само собой разумеющееся.

Часто пропускают именно методологию тестирования гипотезы. После публикации мобильного приложения в App Store и Google Play дается реклама и на ее основе через какое-то время делаются выводы.

При разработке мобильных приложений особое внимание нужно уделать продуктовому тестированию
Продуктовое тестирование – важнейший элемент разработки

Правильное же тестирование включает в себя следующие этапы:

  1. На основе маркетинговой стратегии закупаются небольшие когорты (группы) пользователей, которые имеют четкие различия, но при этом попадают в целевую аудиторию. Например, мужчины 22-26 и 27-32 лет, интересующиеся спортом и имеющие семью, в трех разных городах миллионниках;
  2. Анализируется поведение пользователей в каждой когорте: как часто они пользуются приложением, сколько стоило их привлечение, купили ли они предоставляемые товары или услуги, решили ли свои проблемы;
  3. Продолжается работа с наиболее живой когортой: в мобильное приложение вносятся необходимые изменения, она более мелко дробится;
  4. Возвращаемся на п.1 до тех пор, пока либо затраты на одного пользователя не станут меньше приносимой прибыли на заданном промежутке времени, либо гипотеза не будет признана несостоявшейся.

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

7. Нет обратной связи с клиентами

И на этапе тестирования, и на этапе первых шагов развития, необходима качественная и удобная обратная связь с пользователями.

Любой человек, у которого возник вопрос, должен получить возможность в полклика его задать. Ответ должен быть быстрым и решающим проблему.

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

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

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

8. Нет поставленных целей

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

Цель – это конкретика. Что именно должно произойти через 3 месяца после запуска, чтобы вы посчитали мобильное приложение успешным?

Возможно, это десять тысяч пользователей, или месячный оборот в пятьсот тысяч рублей. Что бы это ни было – оно должно быть записано и разбито на промежуточные этапы.

Часто эта цель отсутствует, что не позволяет команде фокусироваться на результате.

9. Отсутствие гибкости

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

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

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

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

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

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

10. Агрессивная монетизация

Как мы часто пишем в своих статьях и новостных выпусках, основной актив современного IT рынка – это внимание.

Если у вас есть активная аудитория из ста тысяч человек, не приносящая сейчас ни копейки, она уже оценивается в значительную сумму – от $200 000 и больше в зависимости от демографии.

Не стоит монетизировать мобильное приложение в ущерб его росту
Монетизация не должна быть в ущерб росту. Иначе не будет вот так.

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

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

Мобильное приложение не должно быть предназначено “для всех”. Это должна быть конкретная группа людей, но как только вы установили с ней связь, вы должны как можно быстрее набирать массу именно этих пользователей.

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

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

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

Выводы

Сложностей в разработке мобильных приложений немало. Это комплексный, сложный, многогранный продукт. Вместе с тем по правилу Парето причиной 80% неудач является 20% наиболее частых ошибок.

Приведенный список – это как раз эти 20%.

Давайте делать классные продукты вместе.

Получите оценку вашей идеи

Если у вас уже есть идея, мы сразу сможем дать оценку по цене и срокам

Также ответим на любые вопросы о процессе раработки.

Тоже интересно