Мобильное приложение для бизнеса: что нужно знать заказчику

Что такое карта путешествий пользователя

Карта путешествия пользователя (Customer Journey Map) позволяет наглядно представить, как разные персонажи будут пользоваться приложением в каждой из пользовательских историй. На такой карте виден весь путь пользователя – перемещение между экранами и клики на кнопки.

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

Александр Хрущев, технический директор студии WINFOX:

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

Чек-лист: что должно быть в ТЗ

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

Общие сведения:

• цель создания сервиса;

• совместимость с платформами: это будет приложение для iOS, Android или других платформ;

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

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

Функциональные требования к приложению:

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

• форматы данных: как будет реализован обмен данными в приложении;

• интеграция: должно ли приложение поддерживать совместную работу с другими сервисами, например с платежными системами и почтовыми серверами;

• интерфейсы доступа: как приложение будет обмениваться данными с внешними сервисами;

• дополнительные функции: должно ли приложение уметь что-то еще, например работать с файлами или библиотеками шифрования;

• конфигурация и администрирование: с помощью каких элементов администратор будет управлять приложением;

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

Нефункциональные требования к приложению:

• безопасность: требования к безопасности приложения;

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

• производительность: требования к работе приложения, например к скорости работы базы данных;

• требования к аппаратному обеспечению сервера: перечень технических характеристик.

Реализация функциональности приложения:

• экран загрузки;

• регистрация и авторизация;

• основной экран;

• меню;

• поиск;

• …

• уведомления.

Этап 3. Проектирование и дизайн

Здесь наша работа делится на два направления: UX-дизайн, то есть проектирование, и UI-дизайн, то есть дизайн привычном понимании.

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

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

Что в результате:

• карта экранов;

• статичный или интерактивный прототип приложения;

• отрисованные экраны и элементы интерфейса.

Александр Хрущев, технический директор студии WINFOX:

«Иногда заказчик говорит: «А давайте не будем тратить время на проектирование и сразу займемся дизайном?». Не делайте так. Допустим, мы исключили проектирование и сделали дизайн. Посмотрели его, и у вас появилась куча идей, как все улучшить. Мы вносим правки и перерисовываем дизайн. Трудозатраты и стоимость проекта вырастают в два раза, а скорость работы вдвое снижается. Дизайнер выгорает, а вы как заказчик недовольны, что проект стал дороже. Все в минусе».

UX-дизайн

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

Проектирование особенно важно для проектов с большой долей неопределенности. Например, для стартапов.

Рустам Мухамедьянов, руководитель студии WINFOX:

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

Александр Хрущев, технический директор студии WINFOX:

«Лучше делать интерактивный прототип, например, в Figma. Перейдя по ссылке, можно пользоваться приложением так, будто оно уже готово и установлено на ваш смартфон. Вы можете перемещаться по разделам, нажимать на кнопки и выполнять различные действия».

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

UI-дизайн

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

Валерий Сорокин, менеджер проектов студии WINFOX:

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

В зависимости от масштаба проекта дизайн может занять одну неделю или несколько месяцев.

Этап 4. Разработка

Программирование – один из главных этапов. Написание кода любого приложения делится на фронтенд и бэкенд.

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

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

Что в результате:

• первый релиз приложения.

Фронтенд

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

Нативная разработка

Нативные приложения написаны для конкретной мобильной платформы: iOS, Android, Windows. Язык программирования, который используется для написания таких сервисов, поддерживается только одной платформой. Например, Swift и Objective-C понимает только iOS, а Java или Kotlin – только Android.

Делайте нативное приложение, если оно должно стать важной частью бизнеса и влиять на продажи.

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

Плюсы нативных приложений:

• наиболее производительны;

• получают полную поддержку от сторов;

• интуитивно понятны, работают более плавно, привычны для пользователя и дарят больше эмоций;

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

• позволяют разработчикам получить доступ к полному набору функций операционной системы.

Минусы нативных приложений:

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

• не лучший вариант для простых приложений.

Кроссплатформенная разработка

При создании таких приложений используются общие наборы средств разработки (SDK). Из-за этого кроссплатформенные сервисы не используют все нативные преимущества каждой платформы. Зато сделать такое приложение дешевле – это оптимальный вариант для проектов с ограниченным бюджетом.

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

Плюсы кроссплатформенных приложений:

• разработка и поддержка дешевле, чем у нативных приложений;

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

Минусы кроссплатформенных приложений:

• низкие производительность и отзывчивость;

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

• требуют у разработчиков больше сил и времени, чтобы адаптировать сервис под разные платформы и устройства;

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

Чек-лист: как выбрать тип приложения

Исходите из своих бизнес-целей и ответьте на следующие вопросы:

• Насколько быстрое и отзывчивое приложение вам нужно?

• Насколько важны бизнес-процессы, которые встроены в приложение?

• Насколько сложные функции будет выполнять ваше приложение?

Рустам Мухамедьянов, руководитель студии WINFOX:

«Главное отличие между нативным и кроссплатформенным приложением – в скорости и отзывчивости работы. Это как проехаться на Porsche Cayenne и Hyundai Solaris. Оба авто едут по дороге, разгоняются, маневрируют и входят в повороты. Но разница чувствуется сразу».

Бэкенд

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

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

Александр Хрущев, технический директор студии WINFOX:

«На этапе бэкенда участие заказчика минимальное. Вам не надо думать, где хранить данные и нужно ли использовать бессерверную архитектуру – это решают разработчики. Мы в WINFOX всегда выбираем оптимальные для клиента решения. Единственное исключение – это когда надо вписать приложение в уже существующую среду. Тогда вы можете сказать: “Делайте на PHP, а не на Java”».

Этап 5. Тестирование и стабилизация

Тестирование – это процесс поиска ошибок в работе приложения, а стабилизация – процесс их исправления.

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

Некоторые заказчики пренебрегают тестированием: «Давайте скорее запускаться! Если будут баги, поправим по ходу». Но чем дальше вы идете в цикл разработки без тестирования, тем дороже будет исправление ошибок.

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

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

Рустам Мухамедьянов, руководитель студии WINFOX:

«Тестирование – это недешево и трудоемко. Но мы никому не рекомендуем от него отказываться, стремясь сэкономить».

Что в результате:

• перечень исправлений и доработок;

• исправление багов, повторное тестирование и стабилизация приложения (баг-фикс, регрессионное тестирование).

Чек-лист: что нужно протестировать

• Функциональность. Такое тестирование гарантирует, что приложение работает нормально. На этом этапе проверяют основные функции: регистрацию, авторизацию, процесс покупки и оплаты.

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

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

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

• Стабилизацию. На этом этапе проводится окончательная проверка работоспособности приложения перед выпуском релиза. Мы не добавляем в приложение новые фичи, а только исправляем существующие ошибки.

Этап 6. Публикация в сторах

Когда приложение готово, его нужно выложить в App Store и Google Play. Для этого оно должно пройти модерацию: сотрудники сторов проверяют, что приложение соответствует всем требованиям, и только потом разрешают его загрузить.

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

Что в результате:

• приложение загружено в Google Play и App Store, где пользователи могут его найти и скачать.

Оптимизация для сторов

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

Чек-лист: как оптимизировать приложение для сторов

• Составьте название и описание приложения. Название приложения – первое, что видят пользователи. Оно должно быть броским, уникальным, соответствующим приложению и его основным функциям. А еще должно содержать ключевые слова. Максимальное количество символов в названии – 50, поэтому лучше выбрать одно-два главных ключевых слова.

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

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

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

• Сделайте красивую иконку. Иконка – главная точка контакта с пользователями. Икона должна быть привлекательной и отличаться от конкурентов. Если они используют объемный дизайн и красный цвет, выбирайте плоский дизайн и зеленый цвет. И помните: иконка должна графически передавать основную функцию вашего приложения.

ASO-оптимизация в сторах – это сегодня как SEO в начале 2000-х годов: запросы залетают в топ со скоростью пули.

Процесс загрузки приложения в разные сторы немного отличается.

Публикация в App Store

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

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

3. Подготовьте сертификат цифровой подписи – его можно сделать на developer.apple.com.

4. Выберите способ монетизации – платный контент в приложении или плата за установку.

5. Загрузите все в App Store.

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

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

Публикация в Google Play

1. Создайте аккаунт в Google Play Developer Console или попросите менеджера проекта выложить приложение от имени разработчика.

2. Оформите пользовательское соглашение от Google (Privacy Policy). Если не знаете, как это сделать, мы поможем.

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

4. Подготовьте сертификат цифровой подписи.

5. Выберите способ монетизации – платный контент в приложении или плата за установку.

6. Загрузите все в Google Play.

Обычно модерация в Google Play проходит быстрее, чем в Apple Store.

Этап 7. Поддержка и развитие

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

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

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

Что в результате:

• техническая поддержка готового приложения: доработки приложения на основе отзывов, администрирование, наполнение контентом;

• развитие приложения, то есть выпуск обновлений.

Поддержка

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

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

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

Развитие

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

План развития приложения называется дорожной картой (Road Map). Такой план обычно составляется на год. Идеально, если у заказчика уже есть понимание, как будет развиваться приложение. Если такого понимания нет – ничего страшного, мы поможем разобраться.

Как составить дорожную карту

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

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

Валерий Сорокин, менеджер проектов студии WINFOX:

«Иногда (очень часто!) лучше проигнорировать просьбы пользователей ради того, чтобы сохранить простоту интерфейса и не зарыть главную функцию в тоннах сомнительных опций. Чтобы понять, как именно поступить, задайте себе всего один вопрос: “Для какого процента аудитории действительно нужна новая фича?”».

Данные аналитики. Для начала можно использовать бесплатные системы аналитики в приложениях, например AppMetrica от Яндекса или Firebase Analytics от Google. Выдвините гипотезы, как можно улучшить те или иные важные для бизнеса показатели: вовлеченность, количество активных пользователей в день и в месяц, стоимость установки приложения. Внедрите изменения для части аудитории, измерьте результат, а после масштабируйте его или откатитесь назад. Затем повторите все еще раз, то есть работайте в рамках HADI-цикла постоянного улучшения.

Рустам Мухамедьянов, руководитель студии WINFOX:

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

Коротко

Сделав приложение, не бросайте его. Занимайтесь поддержкой и развитием.

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

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

Глава 5. Что такое MVP и зачем он нужен

Любой бизнес начинается с идеи, однако не каждая из них выстреливает. Иногда предприниматель узнает, что клиентам не нужно приложение, уже после того, как оно готово. MVP, или Minimum Viable Product – это минимально жизнеспособный продукт, который помогает проверить гипотезу.

Как выглядит MVP

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

Зачем нужен MVP

Сделать MVP – оптимальный способ быстро проверить, что на самом деле нужно рынку (или не нужно).

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

Как мы делаем MVP

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

Чтобы сделать MVP с нуля, нам в WINFOX обычно надо два-три месяца.

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

Коротко

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