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

Что хотел заказчик

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

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

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

Что сделали мы

Провели технический аудит

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

Архитектура проекта. Изучая код, мы выяснили, что проект строится на архитектуре Model View Controller (MVC). Такая архитектура разделяет приложение на три основных компонента:

1. модель — отвечает за данные и логику;
2. визуальное представление — отображение данных пользователю;
3. контроллер — управляет взаимодействием между моделью и представлением.

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

Например, автодилеру нужно было реализовать функцию выкупа машины, программу лояльности и обеспечить электронный документооборот. Для этих целей мы предложили архитектуру Model View Presenter (MVP). Она представляет собой шаблон, который тоже разделяет приложение на три компонента:

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

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

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

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

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

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

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

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

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

RB.RU принимает заявки на RB Digital Awards 2024 — четвертую ежегодную независимую премию для компаний, которые повысили эффективность бизнеса с помощью новых технологий. Премия присуждается за кейсы в области цифровой трансформации. Успейте заявить о себе до 1 декабря.

Узнать подробности и подать заявку

Провели дизайн-аудит

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

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

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

Например, если пользователь хочет записаться на тест-драйв из раздела услуг. Наблюдение за пользователями показало, что 30% аудитории не переходят к выбору времени для записи, сталкиваясь с трудностями при выборе временного слота.

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

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

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

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

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

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

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

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

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

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

Сформировали гипотезы

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

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

Протестировали основные функции приложения

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

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

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

1. количество установок приложения выросло на 50%;
2. доля записей на сервис через приложение увеличилась на 11%;
3. количество лидов из приложения по направлению «Автомобили с пробегом» увеличилось на 26%;
4. средний чек в приложении вырос на 20%.

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

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

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

Чек-лист, чтобы оценить свое приложение самостоятельно

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

• Документация. Вы документируете все? Есть ли у вас описание функционала, который вы делали год назад? У вас должны храниться требования и другая документация проекта по всему, что вы делаете.
• Рефакторинг и технический долг. Как часто в приложении делают рефакторинг и закрывают технический долг? Нужно поддерживать код в актуальном состоянии, своевременно обновлять используемые библиотеки, поддерживать целостность и единообразие исходного кода независимо от текущей разработки новых функций.
• Полнота данных. Знаете ли вы свою аудиторию? Отслеживаете и анализируете ли воронки событий? Собираете ли вы и достаточно ли полно анализируете данные по тому, как работает приложение? Для эффективной поддержки старого и разработки нового функционала необходимо наблюдать за состоянием приложения и тому, как люди его используют. Здесь помогают мониторинг, крашлитика и другие инструменты.
• Анализ Usability. Проводите ли вы фокус-группы? Анализируете ли UX и UI? От того, удобно ли ваше приложение, зависит его привлекательность и успешность на рынке. Так что полезно тестировать Usability и непрерывно проводить улучшения на основе данных.
• Гипотезы, чтобы улучшить пользовательский опыт. Вы определяете проблемы пользователей и их потребности? Изучаете продукты конкурентов? Формулируете гипотезы и тестируете ли их? Вместе с улучшением пользовательского опыта растет количество пользователей, посещений приложения, доходы, а вместе с тем падают затраты на разработку.

Фото на обложке: Freepik / Freepik