60 дней кино и сериалов за 0 ₽
Условия подписки: clck.ru/dnhea. 18+
VC60
Забрать
60 дней подписки Яндекс Плюс бесплатно для новых пользователей, ранее не оформлявших подписку Яндекс Плюс либо подписки, её включающие, при условии привязки банковской карты. Далее — автопродление: 199 ₽/месяц. Действует на территории РФ. Активировать до 01.09.22 г. включительно на сайте https://hd.kinopoisk.ru/gift. Условия: clck.ru/FMQND.
Личный опыт
SimbirSoft

Как сделать MVP приложения и угодить всем

Можно ли при создании MVP мобильного приложения одновременно обеспечить и удобство для пользователей, и простоту разработки для команды? С 2008 года разработчики SimbirSoft создали около 300 мобильных приложений и могут точно сказать, что это реально.

Как обеспечить качественный пользовательский опыт, с каких шагов начинается разработка MVP и что учесть при реализации различных функций? Об этом расскажет руководитель направления мобильной разработки SimbirSoft Ринат Шамшутдинов. А также читайте про самые популярные ошибки в MVP.

MVP – это минимально жизнеспособная версия продукта, с которым вы можете выйти на рынок. Важно отметить: это не черновой вариант. На рынке у вашего продукта, скорее всего, уже будет много конкурентов. Поэтому нужно сделать так, чтобы пользователь был готов заплатить за него свои деньги и/или потратить личное время.

MVP-подход можно использовать и в уже действующих продуктах. Такой пример был в нашей практике: нужно было за 3 месяца улучшить приложение одного из региональных банков.

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

Ринат Шамшутдинов
руководитель направления мобильной разработки SimbirSoft

Чтобы MVP версия продукта была успешной, она должна соответствовать нескольким критериям:

  • Deadline. Приложение должно быть разработано в срок с учетом тестирования, правок и публикации.
  • User experience. Пользователь должен иметь возможность быстро разобраться в приложении и захотеть оставаться в нем дальше, применять его для решения своих потребностей.
  • Quality of code. Код должен быть поддерживаем для расширения функционала и дальнейшего развития приложения.

Остановимся на User experience. Своих пользователей бизнес знает, как никто другой, а значит готов проконтролировать этот момент при проработке концепции и разработке MVP. К слову, владелец продукта может это отследить по дизайн-макетам, которые предоставляет подрядчик. Также напомним, что для сложных проектов вроде дистанционного банковского обслуживания должно быть техническое задание с описанием основных экранов, сценариев использования и прочего. А для простых приложений может быть достаточно дизайн-макетов и описания backend API.

Внимание пользователю

Для качественного user experience необходимо:

  • Обеспечить удобный вход пользователей в приложение и простоту в освоении.
  • Уделить внимание альтернативным сценариям.

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

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

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

  • Используйте наиболее простые способы авторизации.

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

  • Сделайте понятной маску ввода.

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

  • Планируйте перенос данных заранее. Пользователи старого приложения должны безболезненно войти в новое.

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

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

Для этого:

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

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

Кроме того:

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

Как подготовиться к старту разработки MVP

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

1. Готовим документацию на основе актуальной информации о продукте:

  • по технической части:
  • Product Vision, техническое задание, дизайн-макеты, описание API backend-части приложения, roadmap;
  • с точки зрения бизнеса:
  • цели, основные сценарии, отличительные особенности, портрет пользователя.

2. Выделяем ограничения и риски.

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

3. Определяем ключевые фичи. Для каждой из них планируем Definition of Done.

Ключевые функциональности проекта определяют команда и владелец продукта. Для каждой фичи планируется результат, которого нужно достичь, чтобы считать функционал готовым. Затем каждая функциональность декомпозируется на более мелкие задачи, которые пойдут на оценку разработчикам. При распределении задач также необходимо учесть, когда и в какой версии – для тестирования, в т.ч. конечными клиентами, или в релизной – приложение должно быть загружено в маркетплейсы. Важно уточнить наличие аккаунтов и схему публикации, поскольку заведение аккаунта для юридического лица может занять несколько недель. Соответственно, владелец продукта (клиент) должен понимать, какие данные потребуются.

4. Делаем оценку проекта, формируем команду с учетом сроков.

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

5. Настраиваем инфраструктуру и закладываем архитектуру.

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

6. Подключаем команду разработчиков.

Как в будущем масштабировать MVP мобильного приложения

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

  • Поддержка телефона / планшета

При разработке MVP можно сосредоточиться на одном виде устройств. При этом важно ориентироваться на актуальные версии операционных систем. При поддержке старых версий срок разработки будет больше, а верстка будет выглядеть не всегда как на макетах. На июнь 2022 мы разрабатываем MVP для версий: Android 8+, iOS 13+.

  • Ориентация экрана и multi window

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

  • Ночной режим

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

  • Поддержка офлайн-режима

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

Варианты реализации:

  • Данные кешируются в оперативной памяти. После выгрузки приложения из памяти, данные повторно загружаются с сервера.
  • Read only. Пользователь может только просматривать контент в офлайн-режиме.
  • Read & Write. Если пользователь сможет редактировать контент в офлайне, важно согласовать с backend-разработчиками, как будет осуществляться мерж конфликтов при изменении данных на нескольких устройствах. Другими словами, как будут определяться, какие изменения самые актуальные. Поясним на примере ToDo-приложения. Предположим, что оно работает на двух устройствах. В офлайн-режиме на обоих гаджетах изменили статус конкретной задачи. В данном случае потребуется решить, какой из статусов будет самым актуальным при включении интернета.
  • Локализация

Важно предусмотреть, будет ли учитываться язык системы, нужно ли делать отдельную смену языка внутри приложения. Тексты ошибок backend-часть приложения должна возвращать в приложение с учетом локализации.

  • Push-уведомления

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

  • Интеграция с устройствами

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

  • Интеграция с социальными сетями

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

Вместо вывода

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

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

О кейсах из практики также рассказываем в нашем телеграм-канале – будем рады, если наш опыт окажется вам полезен!

0
Комментарии
Читать все 0 комментариев
null