Дизайн

Зачем проводить UX-аудит мобильного приложения

Команда «Иностудио»

Оглавление

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

 Кому полезен UX-аудит

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

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

 Какие задачи решает UX-аудит

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

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

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

 Как проводят UX-аудит

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

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

 Анализ метрик

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

Метрики производительности

load time — общее время загрузки приложения, при котором все элементы успевают полностью отобразиться на экране.

crashes — количество ошибок и сбоев в приложении.

latency — время, необходимое приложению для передачи информации и отображения ответа на запрос пользователя.

Метрики взаимодействия и вовлечённости

daily active users (dau) — показывает количество пользователей, которые взаимодействуют с приложением каждый день, считается метрикой успешности.

monthly active users (mau) — аналог предыдущего показателя, показывает количество активных уникальных пользователей, которые пользовались приложением хоть раз за последний месяц.

stickiness — показывает, как часто клиенты возвращаются к сервису.

average session length — средняя длительность одного сеанса, показывает количество времени, которое пользователь в среднем проводит в приложении.

churn rate — показывает количество юзеров, которые перестали пользоваться приложением за определённый период времени. Метрика не учитывает новых пользователей, поэтому даёт объективные данные во время бурного роста.

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

retention rate — показывает количество пользователей, которые вернулись в приложение за определённый период. Метрика определяет вовлечённость клиентов и даёт данные для прогноза.

Метрики конверсии

goal completion — процент пользователей, которые выполнили целевое действие приложения: сделали заказ, оформили подписку, оставили данные для связи.

time to goal completion — время, которое понадобилось клиенту для совершения целевого действия. Метрика объясняет, почему действие не выполнили, и показывает факторы, которые отвлекли или задержали пользователя.

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

После исследования метрик приложения идёт следующий этап UX-аудита — пользовательское тестирование.

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

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

С помощью такого вида тестирования можно формировать гипотезы UX-проблем в интерфейсе. Например, мы видим по метрикам, что большое количество пользователей не может пройти регистрацию, но мы не знаем, почему так происходит. Метрики (количественные данные) не дают ответ на вопрос «Почему?», поэтому необходимо добыть качественные данные. И как раз один из инструментов для получения качественных данных — это пользовательское тестирование.

    Для проведения пользовательского тестирования понадобятся:
  • респонденты (5–10) — пользователи мобильного приложения;
  • интерфейс — либо существующая рабочая версия мобильного приложения, либо прототип разного уровня детализации (детализация зависит от задачи исследования);
  • камера или диктофон для записи и прослушивания сессии юзер-тестирования;
  • фасилитатор сессии.

Как использовать пользовательское тестирование

Важный момент: результаты тестирования не являются конечным результатом UX-аудита. Всё потому, что количество респондентов (5–10) не несёт статистическую значимость. Даже десяти респондентов слишком мало, чтобы утверждать, что найденная проблема присутствует у большинства пользователей.

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

Вот как это выглядит на схеме:

HADI-цикл

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

Если же мы уверены, что проблема на основе гипотезы сформулирована верно, то нам нужно подтвердить эту проблему статистической значимостью. Для этого запускаем такой же HADI-цикл, только на этапе действия применяем методы количественного исследования, например используем A/B-тест, смотрим метрики или проводим опрос.

Бывают ещё количественные немодерируемые пользовательские тестирования. Они имеют статистическую значимость, потому что проверяется большая группа респондентов, например 500–1000. Цифра сильно зависит от размеров пользователей сервиса. Всех не опросить, но какую-то значимую часть можно. Поэтому команды сами решают, какое число респондентов будет статистической значимостью. Но такие исследования проводятся без фасилитатора/модератора, действия пользователя отслеживаются через специальные инструменты, получая ответ на вопрос «Что является причиной проблемы?».

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

 UX-аудит: что потом

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

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

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

Оцените эту статью

1 4
Спасибо за оценку!

Оставьте заявку

Расскажите о проекте — мы его реализуем

Мы свяжемся с вами в течение 4 рабочих часов: обсудим цели проекта, требования к нему и составим план сотрудничества

* – поля обязательные для заполнения