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

Мы проверим все возможные варианты реализации Вашей идеи в приложение, сравним с существующими аналогами и определим сильные стороны проекта.

Командная работа по сбору данных и обсуждению проекта.

1 Анализ конкурентов:

  •      количество загрузок
  •      оценки и отзывы

2 Выбор варианта монетизации проекта:

  • покупки в приложении
  • оплата подписки или премиум-версии
  • размещение рекламы
  • продажа данных

3 Маркетинг

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

4 Дорожная карта продукта и MVP

5 UX-дизайн. Внутренняя архитектура приложения

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

6 Вайрфрейм

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

Инструменты: Balsamiq, Sketch, Axure, Figma, RealtimeBoard, Wireframe.cc и Whimsical

7 Пользовательские сценарии

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

Инструменты: маркеры, плюс Invision, Adobe XD и Figma.

8 Проверка на аудитории

Самый простой способ проверить, насколько хорош ваш UX-дизайн – протестировать его на будущих пользователях. Отправьте им ссылку, после перехода по которой они смогут «потыкать» по отрисованным вайрфреймам. О функциональности речь не идёт, только о проверке навигации. Прислушивайтесь к комментариям, возвращайтесь на один-два-три шага назад, исправляйте проблему и тестируйте. Снова и снова.

Инструменты те же, что и для пользовательских сценарий: Invision, Adobe XD и Figma.

9 UI-дизайн. Стайлгайды

Стайлгайды – это стройматериалы для отделки «интерьера» мобильного приложения и повышения его юзабилити. Без продуманного стайлгайда элементы дизайна будут менять цвета и плавать по экрану, сбивая пользователя с толку.

Руководство по стилю мобильного приложения должно быть максимально подробным и опираться на характеристики аудитории. Ей нужно работать в приложении по ночам? Делаем тёмную тему. Это внутреннее приложение для сотрудников крупной компании? Убираем всё лишнее. Как это сделать? Опытный UI-дизайнер предложит сотню вариантов цветовой палитры, шрифтов и виджетов (кнопок, форм, значков и т.д.).

10 Рендеринг

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

Инструменты: Sketch, Figma, Adobe XD и Principle.

11 Проверка дизайна

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

Инструмент: Invision, Figma и Sketch.

12 От дизайна к разработке

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

В некоторой степени успех совместной работы дизайнеров и разработчиков зависит от выбора инструментов. Например, приложение Zeplin показывает последним все свойства загруженного в него дизайна, хотя не обладает всеми возможностями Sketch или Photoshop. В любом случае, убедитесь в том, что команда пользуется точными значениями измерений и не ленится копировать HEX-коды цветов.

Инструмент: Zeplin

13 Архитектура системы

В мобильной разработке существует великое множество технологий. Одни почти не требуют затрат, но не отличаются высокой производительностью, другие потребуют больших вложений во имя блестящего результата. Худшее, что вы можете сделать на данном этапе – использовать устаревшие или ненадёжные инструменты, которые приведут к тому, что вам придётся переписывать код, доплачивая остальным членам команды за переработку. Чтобы избежать этого, рекомендуем принять ряд важных решений до начала работы над проектом. Каких именно, расскажем ниже.

Frontend-разработка

Существует три основных подхода к frontend-разработке:

  • Нативный – при таком подходе приложение пишется под конкретную мобильную платформу. То есть код приложения под Android нельзя будет использовать на iOS без адаптации. Интерфейс нативного приложения выглядит максимально органично, а само оно работает быстро и отлаженно. За такую надёжность приходится платить, поэтому нативная разработка стоит дороже остальных вариантов.
  • Кроссплатформенный – код такого приложения универсален, вследствие чего ОС запускает его как нативное. Многие считают этот способ оптимальным по соотношению «цена-качество», но он всё равно требует от разработчика временных затрат на оптимизацию. Если остановитесь на нём, среди фреймворков выбирайте между React Native, Xamarin и Native Script.
  • Гибридный – код пишется на HTML, CSS или Javascript в таких средах разработки, как Cordova, Phone Gap и Ionic. Получается дёшево, сердито и не без проблем.

Backend-разработка (программный интерфейс и сервер)

Сервер влияет на производительность мобильного приложения и масштабируемость продукта, то есть способность системы увеличивать ту же производительность за счёт увеличения доступных ресурсов. Технологии здесь те же, что и в разработке веб-приложений. Отправная точка – определиться с:

  • Языком программирования – написать мобильное приложение можно на Java, SWIFT, а сервер на Javascript, C#, Go-lang, PHP, Python и ещё десятке языков. И у каждого из них есть фреймворки на любой вкус.
  • Системой управления базой данных – они делятся на два типа: те, что работают на SQL, и все остальные. SQL-системы надёжны и подходят для решения практически любых задач. Самые популярные – MSSQL, MYSQL и PostgreSQL. Кроме того, придётся выбрать движок (подсистему хранения) и выстроить схему базы. Ваша цель на данном этапе – сделать систему надёжной и хорошо структурированной. Не поленитесь и тщательно продумайте каждый её элемент.
  • Хостингом для сервера и API – здесь вновь важно учесть производительность и масштабируемость приложения наряду с его надёжностью и ценой в магазинах. Такие провайдеры, как Amazon AWS и Rackspace, предлагают разработчикам облачные решения, причём размер облака можно будет увеличить, когда вырастет база пользователей. Они же помогут с резервным копированием данных и оперативными обновлениями.

Разработка и итерация

Как вы могли понять из начала нашего гайда, разработка мобильного приложения состоит из множества этапов. Разобраться в следующих будет в разы проще, если вы слышали про Scrum — метод управления проектами, который подразумевает разбивку рабочего процесса на небольшие отрезки – спринты. В каждом из них есть стадии планирования, разработки, тестирования и подведения итогов. Скрам – один из подходов методологии Agile, о которой написано множество книг, поэтому глубоко вдаваться в терминологию мы не будем. Тем более, что какими бы методами не пользовалась та или иная компания, этапы работы над мобильным приложением будут примерно одинаковыми.

Планирование

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

Разработка

На этапе разработки команда воплощает в жизнь идеи дизайнеров и свои собственные. Результат проверяет QA-команда (отдел контроля качества) или менеджер проекта. Последний также распределяет задачи между разработчиками, добиваясь равномерной загрузки команды на протяжении всего спринта.

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

Тестирование

Тестировать приложение не должны его же разработчики.

Тип тестирования выбирают исходя из проверяемой характеристики приложения:

  • Функционал – должен соответствовать заявленному. Хорошо, если у подрядчика есть QA-команда, а у неё – план тестирования со списком всех функций приложения и его желаемым поведением. Но если таковой нет – необходимо позаботиться об этом и нанять специально обученных специалистов. Юзабилити – интерфейс мобильного приложения должен быть интуитивно понятным и дружелюбным. О проблемах с этими качествами вам лучше всего расскажут те, кто видят продукт впервые.
  • Производительность – никто не будет пользоваться приложением, которое грузит рабочий экран больше 10 секунд. И хотя производительность обычно тестируют на более поздних стадиях разработки, следить за временем отклика надо уже сейчас.
  • Дизайн – тут дизайнерам придётся ещё раз включиться в работу и удостовериться в том, что каждая деталь визуального стиля была реализована разработчиками в соответствии со стайлгайдом. Кстати, это ещё одна веская причина работать с компаниями, которые занимаются и разработкой, и дизайном.

Но и это ещё не всё:

  • Регрессионное тестирование – используется для проверки уже протестированного кода на ошибки, исправленные ранее, или возникшие в результате этих исправлений. Здесь на помощь вновь приходит QA-команда с чек-листами изменений, внесённых в код на каждом из спринтов.
  • Тестирование под платформу – существует бесчисленное количество комбинаций мобильных устройств и установленных на них операционных систем. Посмотрите, как приложение работает на смартфонах с разными размерами и разрешениями экранов, и запустите его на всевозможных версиях ОС.
  • Приемочное пользовательское тестирование – проводится будущими пользователями приложения и показывает, готов ли продукт к выходу на рынок. Собирайте отзывы и готовьтесь к старту, только если только ваше приложение с блеском прошло все предыдущие проверки.

Анализ

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

Перед запуском

К этому моменту приложение (или хотя бы MVP) должно быть полностью готово к выходу на рынок. Но если вы хотите потратить маркетинговый бюджет с умом, то размещать приложение в публичный доступ Google Play и Apple App Store пока рано. Нужно ещё раз протестировать его — на этот раз на небольших группах целевой аудитории. Сделать это можно двумя способами.

Фокус — группы

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

Бета -тестирование

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

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

Внедрение на рынок

Перед тем, как представить своё мобильное приложение миру, позаботьтесь о двух вещах: надёжном API-сервере и соблюдении правил Google Play Store и Apple App Store.

API-сервер

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

Магазины приложений

Публикация приложения в Google Play Store и Apple App Store – трудоёмкий процесс. Вам придётся убедиться в том, что приложение отвечает требованиям магазина, заполнить несколько форм для каждого из них, подготовить скриншоты и маркетинговые материалы, составить текст описания… а Apple ещё и тщательно в течение нескольких дней будет проверять само приложение и даже может не только потребовать изменений, но и отказать в публикации из-за “бессмысленности” приложения. Нет, мы не исключаем вероятность того, что магазин примет ваше приложение без лишних вопросов, и через несколько дней оно будет доступно для скачивания. Просто предупреждаем о возможных трудностях, которые возникнут с вероятностью в 99%.

Мониторинг

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

Падения

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

Инструменты: Firebase и Bugsee

Аналитика

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

Инструменты: Firebase, Яндекс.Метрика, Facebook Analytics, Apptentive, Google Analytics и Appsee

Производительность

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

Инструмент: Prometheus

Поддержка репутации

Оценки и отзывы в магазинах крайне важны, особенно для новых приложений. Всегда отвечайте комментаторам: благодарите за хорошие слова и постарайтесь помочь тем, кто столкнулся с трудностями при использовании вашего приложения. Комментаторы обычно не ожидают, что им ответят реальные разработчики. Чуть больше клиентоориентированности – и две звезды превращаются в пять, а ваша репутация взлетает до небес.

Дальнейшие улучшения

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

Вывод

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