Битва за внимание пользователя с каждым годом становится все более ожесточенной — команды программистов соревнуются в том, чтобы сделать свой продукт качественным, вкладывают значительные средства в UI/UX дизайн и разработку мобильных приложений.
Социальные сети, мессенджеры, образовательные платформы и многое другое — для каждого приложения есть четкий алгоритм создания, который немного меняется у разных компаний-разработчиков ПО. Это «жизненный цикл мобильной разработки», сценарий действий, выполняемых «мобильной командой» для создания нового приложения. Жизненный цикл помогает понять:
- Что нужно, чтобы начать процесс разработки
- Как это запустить
- Как должен выглядеть конечный результат
Рынок мобильных приложений быстро растет: в прошлом году пользователи скачали приложения 218 миллиардов раз. Это очень прибыльный бизнес: топ-200 приложений в App Store зарабатывают в среднем по $83 тысячи в день. Глобально рынок уже достиг $700 млрд, и продолжает расти безумными темпами — по 20-30% каждый год.
Создание любого успешного мобильного приложения состоит из 6 этапов. Но на каждом шаге встречаются свои скрытые проблемы. В этой статье мы поделимся своими способами их решения.
Шаг 1 — Исследование
Проблема: клиент на самом деле не знает, нужно ему приложение или нет.
Решение: Опросить, выяснить их ценности, задать вопросы, перечисленные ниже.
Все начинается с идеи. Но ужасные решения, бывает, тоже начинаются с идеи. Иногда клиент просто убежден, что у него должно быть приложение. Но прежде чем тратить время и деньги на разработку проекта, клиенту нужно ответить на следующие вопросы:
- Посещают ли пользователи ваш сайт со своих мобильных устройств?
- Хотите внедрить новые функции для мобильных приложений, которых нет на сайте?
- Используют ли ваши конкуренты мобильные приложения?
- Повторные продажи — это ваше дело?
- Есть ли у вас система лояльности?
Даже если клиент ответил «да» на большинство вопросов, только профессиональное исследование, проведенное агентством по разработке, может определить, полезно ли приложение для бизнеса.
Мобильное приложение не становится автоматически новым каналом продаж. Специалисты рекомендуют начать с анализа: как клиент общается с покупателями (через офлайн-магазин, колл-центр, общение через сайт). Полезно изучить, с какими внутренними процессами сталкиваются клиенты каждый день, и как мобильный опыт может улучшить эти взаимодействия.
Проблема: Клиенту нужно слишком много функций одновременно.
Решение: Критерии выбора признаков очень просты. «Может ли пользователь решить фундаментальную проблему без этой функции?». Если ответ «да», то функцию можно удалить.
Мы зависимы от чрезмерного мышления. При создании приложения первоначальный функционал через некоторое время уже не кажется достаточным. Клиенты часто предлагают добавить что-то еще, регулярно появляются новые мысли. Но чем больше фич, тем сложнее разработать продукт.
Команда для разработки мобильного приложения должна дать клиенту понять, что продукту нужно появиться на телефонах пользователей как можно скорее. Чем раньше появятся отзывы, тем выше шансы на успех. Как только цель будет достигнута, в будущем в приложении можно будет что-то изменить или добавить новые функции.
Проблема: аутсорсинговая компания, которую нанял клиент, считает, что «анализ конкурентов» буквально сравнивает их характеристики.
Решение: убедиться, что агентство по развитию использует модель пяти сил Портера для проведения анализа конкурентов.
В Кремниевой долине любят использовать схему «пяти сил Портера». Это модель анализа, которая определяет пять конкурентных сил, формирующих каждую отрасль. Это помогает указать на слабые и сильные стороны потенциального приложения.
Пять сил таковы:
- Власть поставщиков: насколько легко поставщикам завышать цены.
- Покупательная способность: насколько легко покупателям снижать цены.
- Конкурентное соперничество: количество и возможности конкурентов на рынке.
- Угроза замены: сколько приложений могут легко заменить ваше.
- Угроза нового входа: как ваш выход на рынок снизит прибыльность.
Шаг 2 — UX и UI дизайн
Проблема: дизайнеры игнорируют различия интерфейсов iOS и Android в концепции.
Решение: убедиться, что дизайнеры разрабатывают несколько концепций/выбирают одну платформу с самого начала.
Жизненный цикл разработки программного обеспечения для платформ iOS и Android требует различных подходов к дизайну, навигации, разработке программного обеспечения для мобильных приложений и другим аспектам взаимодействия с пользователем. Если вы думаете о создании мобильного приложения, нужно выбрать, какую платформу использовать.
Например, подбирая цвета для концепта, имейте в виду, что цветовая палитра iPhone обычно лучше передается на экране (без обид, поклонники Android!), поэтому нужно отказаться от концептов со смежными цветами. На Android они могут выглядеть «грязнее».
Также есть еще несколько нюансов UI/UX:
- Размер экрана: 320 x 568 пикселей для iPhone и 360 x 640 пикселей для Android.
- Системный шрифт: San Francisco iOS против Roboto Android.
- У iOS совершенно другие принципы UI/UX, чем у Android. Последний использует принципы Material Design.
- У устройств Android есть физические кнопки навигации. У iOS-устройства нет.
Чтобы не тратить средства впустую, лучше обратиться к дизайнеру, знакомому с требованиями операционных систем и логикой построения экранов для Android и iOS.
Проблема: команда разработчиков приложений игнорирует цель, создавая дизайн, который нравится ей лично.
Решение: приложение должно соответствовать предпочтениям основной целевой аудитории. Это можно указать в документе требований.
Например, вы разрабатываете страницу-вход приложения для занятий спортом. Используйте динамичные шрифты и яркие цвета (подходящие палитры можно найти в интернете):
Для всего приложения лучше использовать только до 4 видов одного шрифта (разных размеров, цветов и толщины) и 4-5 цветов. Этого достаточно для выделения и создания аккуратного интерфейса.
Шаг 3 — Разработка
Проблема: Команда разработчиков получает невозможную концепцию от команды дизайнеров. Теперь они должны его изменить.
Решение: Пришло время переоценить время в 3 этапа разработки мобильного приложения!
I. Команда разработчиков анализирует концепцию.
Разработчики изучают требования проектной группы/клиента. Проводят беглый анализ задачи, функций приложения, выявляют пробелы и задают вопросы, чтобы их заполнить.
II. Команда разработчиков выявляет проблемы концепции.
Разработчики указывают потенциально проблемные особенности из концепции дизайна в 5 стадий:
- Новые задачи и технологии для прототипа приложения.
- Сложные задачи, требующие исследований и времени.
- Полностью настраиваемые элементы пользовательского интерфейса невозможно реализовать.
- Они определяют функции, для которых возможно использование сторонних библиотек/сервисов (интеграция таких библиотек/сервисов также требует времени).
- Разработчики пересматривают все сроки проекта.
III. Команда разработчиков торгуется с продакт-менеджером, и рождается новый прототип приложения.
Разработчикам мобильных приложений:
- Определите компоненты приложения, которые можно использовать повторно.
- Определите компоненты/задачи, которые ранее были реализованы в каркасе других проектов.
- Определите задачи, для решения которых необходимо провести исследование, и согласуйте это время с руководителем.
- Определите компоненты (как пользовательский интерфейс, так и бизнес-логику), которые можно оптимизировать без потери качества и функциональности. Затем они согласовывают предложения по оптимизации с менеджером проекта.
Разработчики согласовывают изменения функционала каждого приложения с менеджером проекта, записывают их. Если им не хватает навыка ораторского искусства, и они не могут убедить PM, они делают письменное предупреждение о рисках, связанных с отказом от изменения дизайна.
Шаг 4 — Тестирование
Проблема: тестировщикам не хватает необходимых знаний о конкретном приложении.
Решение: убедиться, что тестировщики читают историю пользователя/карту пути клиента или видят, как работают похожие приложения.
Это одна из самых частых ошибок тестировщиков. Они «прощупывают» приложение, о котором никогда не слышали, а потому обращают внимание только на основные нюансы. Но тестировщик должен хорошо знать приложение — его функциональные требования, функции и логику.
Проблема: Клиент настаивает на том, чтобы пробовать и исследовать абсолютно все.
Решение: Дать понять клиенту, что это невозможно.
Невозможно протестировать мобильное приложение на всех устройствах и операционных системах. Google Analytics позволяет сделать определенные выводы о поведении пользователей. Допустим, вы хотите протестировать 50 случаев на 10 разных устройствах в 5 разных сетевых средах. Чтобы справиться с этой задачей и создать приложение, тестировщикам потребуется проработать бесконечное количество вариантов.
Шаг 5 — Развертывание ПО
Проблема: производительность приложения падает по мере роста пользовательской базы.
Решение: Повысить производительность.
- Разработчики могут кэшировать некоторые данные, а не динамически выдавать их каждый раз для каждого пользователя (например, количество комментариев).
- Хранение изображений и других тяжелых объектов в базе данных снижает производительность приложения. Избегайте хранения массивных наборов тяжелых изображений, подобных этому. Плюс подумайте об удалении данных, которые долго никто не спросит.
Проблема: Пользователи замечают ошибки в приложении.
Решение: Продумать заранее.
Это хорошая проблема. Если приложение уже получило большую базу пользователей, может случиться так, что они столкнутся с различными проблемами и программными ошибками. Например, это может быть тайм-аут сервера, сброс соединения или сброс обновления. Большинство этих проблем следует продумывать на этапе проектирования вашего приложения. Добавить возможность авторизации пользователей через сторонние сервисы.
Шаг 6 — Поддержка
Проблема: через некоторое время после запуска клиент пытается «починить» приложение, а не обновить его.
Решение: Каждый год выходит новая версия iOS. Клиенту потребуется немедленное исправление для новой версии, чтобы пользователи могли продолжить загрузку приложения. В то же время нужно думать о развитии.
По мере загрузки и использования нового сервиса пользователями вы будете получать отзывы и на их основе дорабатывать приложение. И через некоторое время вы наверняка захотите добавить новые функции.
Стоит ли сейчас разрабатывать мобильные приложения?
Ожидается, что к 2023 году глобальный доход от мобильных приложений достигнет 935 миллиардов долларов за счет платных загрузок и рекламы в приложениях. Доходы увеличиваются на 20-30% каждый год. Это делает разработку ПО для смартфонов одним из самых прибыльных и быстрорастущих сегментов ИТ-рынка. Особенно если ориентироваться не на Россию, а на Европу/США/Китай. Разработка новых приложений, особенно опирающихся на реальную базу, однозначно того стоит.
Только нужно обращать внимание на такие факторы, как:
- Анализ рынка и болей потенциальных пользователей
- Создание UX/UI дизайна, который будет отвечать потребностям пользователей
- Анализ функций приложения
- Повышение производительности
- Поддержку приложения по мере выхода новых версий Android или iOS.
Если хотите заказать разработку мобильного приложения на заказ, обращайтесь к Rubrain.com! У нас больше 10 000 опытных специалистов, мы реализуем проекты под ключ, можем предоставить вам команду под ключ. Делаем проекты для Vodafone, Яндекса, X5 Group, Evernote, The Washington Post и многих других. Присоединяйтесь!