Заглянуть под капот: как проводить аудит мобильного приложения и какие бизнес-задачи он решает

Что можно узнать, проанализировав разные стороны сервиса, и как это помогает улучшить продукт. На примере аудита приложения для автомобилистов «Мой РОЛЬФ».

Привет! На связи Napoleon IT. Мы занимаемся аутсорс-разработкой IT-решений, управленческим консалтингом и оптимизацией бизнес-процессов для компаний и сегодня решили поделиться историей, как проводили аудит мобильного приложения на iOS и Android для компании «РОЛЬФ».

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

В 2022 году в «Рольф» задумались о том, чтобы превратить свое мобильное приложение на iOS и Android в универсального помощника для автомобилистов. Автодилер хотел, чтобы в обновленном сервисе пользователь мог:

• Записаться на тест-драйв в автосалон.

• Выбрать и приобрести не только новый, но и подержанный автомобиль.

• Узнать условия кредита на покупку машины.

• Получить напоминание, когда пора менять машинное масло.

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

В то время у «Рольф» уже было свое мобильное приложение с аудиторией в 200 тысяч пользователей. Компания развивала его около 5 лет.

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

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

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

Архитектура проекта. Изучая код, мы выяснили, что проект строится на архитектуре Model View Controller (MVC). Такая архитектура не очень подходила «Рольф»: она не позволяет быстро масштабировать приложение, а это был один из приоритетов компании. Поэтому мы предложили использовать архитектуру Model-View-Presenter (MVP), которая обеспечивает более простое тестирование и улучшенную расширяемость приложения, предоставляя более явное разделение между визуализацией и моделью.

Кодовая база. Если архитектура — общий подход к проекту, то кодовая база — детали. Поэтому мы провели рефакторинг кода.

Вместе с тем мы проверяли утечки памяти в приложении.

Если приложение разработано некорректно, оно перегружает оперативную память любого телефона и в итоге виснет, выдает ошибку или «вылетает». Одна из задач разработчиков — сделать так, чтобы приложение не перегружало память и вовремя убирало из нее «мусор», то есть неиспользуемые объекты.

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

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

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

• Провести рефакторинг отдельных модулей под архитектуру MVP на iOS.
• Выяснить причины утечек памяти и избавиться от них на iOS.
• Исключить legacy-код на Android.
  

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

Для этого мы привлекли наших партнеров из дизайн-студии 11:11 и вновь разделили работу на несколько блоков.

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

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

Анализ Usability. Оценка usability помогает понять, комфортно ли пользоваться сервисом.

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

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

Вот несколько моментов в приложении, которые мы обнаружили:

1. Некоторые пользовательские сценарии оказались непродуманными. Например, когда неавторизованный пользователь пытался записаться в сервисный центр, приложение выдавало ошибку. Ему приходилось переходить на экран логина, проходить процедуру авторизации и только потом возвращаться на экран с записью. Хорошее решение в этом случае — добавить сервис, который сам направит неавторизованного пользователя на экран логина, а после успешной авторизации автоматически перенаправит на нужный экран.
2. Были трудности с валидацией. Например, во время авторизации сервис выдавал ошибку, пока пользователь вводил номер телефона. Это отвлекало и нервировало. Уместно показывать ошибку, когда номер введен целиком и неверен, а не в процессе его ввода.
3. Не было обратной связи через мессенджеры. Большая часть пользователей предпочитает не звонить в техподдержку, а писать через мессенджеры.

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

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

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

У «Рольф» не был проработан регламент этих процессов, поэтому мы пошагово расписали, как отделу дизайна строить работу над задачами и взаимодействовать с другими отделами разработки. Таким образом команда будет работать в одном направлении и этапы дизайна будут понятны всем участникам проекта.

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

• Рекомендации, как структурировать UI Kit: проработать единообразие иконок и элементов, убрать дублирующие друг друга и неактуальные, ввести единство названий в разработке и дизайне на английском языке и прочее.

• Приоритизация гипотез: первым делом раздел авторизации и регистрации, затем приветственный экран и прочее.

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

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

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

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

По итогам аудита и последующей модернизации мобильного приложения автодилеру «Рольф» удалось улучшить важные для себя бизнес-метрики:

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

• количество лидов из приложения по направлению «Автомобили с пробегом» увеличилось на 26%;

• доля записей на сервис через приложение увеличилась на 11%;

• средний чек в приложении вырос на 20%.

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

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

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

В завершение мы собрали несколько пунктов, которые помогут провести мини-аудит своего мобильного приложения:

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

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

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

• Анализ Usability. Проводите ли вы фокус-группы? Анализируете ли UX и UI? От того, удобно ли ваше приложение, зависит его привлекательность и успешность на рынке. Так что полезно тестировать Usability и непрерывно проводить улучшения на основе данных.

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

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