Аудит UX/UI мобильного приложения: точки разрыва и рост конверсии

Где рвётся путь к заказу: аудит UX/UI мобильного приложения

Аудит UX/UI мобильного приложения мы начинаем не с перерисовки экранов, а с разбора воронки: восстанавливаем путь пользователя от первого запуска до подтверждённого заказа и смотрим, где доля дошедших падает заметнее всего. Основа — события в аналитике, записи сессий и разметка ключевых шагов: корзина, способ доставки, оплата, повторный вход.

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

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

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

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

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

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

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

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

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

Форматы работ: полный разбор, экспресс-проверка, точечная проверка

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

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

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

Как проходит разбор: от сбора данных до проверки правок

Разбор идёт не по вкусовым ощущениям, а по воспроизводимой последовательности: сначала данные, потом схема, только затем правки. Такой порядок снимает спор «нравится — не нравится»: у каждой рекомендации есть метрика, к которой она привязана, и способ проверить её до релиза.

1. Сбор данных продуктовой аналитики. Выгружаем события, воронки, глубину сессий и распределение экранов входа-выхода за сопоставимый период. Цель — увидеть, на каком шаге отвал максимален, а не где он заметнее всего выглядит.
2. Схема пользовательских сценариев. Собираем карту экранов и переходов, накладываем её на воронку и размечаем точки разрыва: где пользователь сворачивает приложение, возвращается назад или повторяет одно действие.
3. Интерфейсная проверка. Тепловые карты и записи сессий показывают, куда реально тянется палец и какие элементы остаются в слепой зоне больших экранов.
4. Проверка гипотез на прототипе. Спорные места собираем в кликабельный прототип и прогоняем на фокус-группе либо разделённым тестом на части трафика — до того, как правка попадёт в код.
5. Приоритизация. Оставляем только то, что влияет на конверсию шага; остальное уходит в отдельный список с обоснованием, почему не берём сейчас.
6. Передача правок команде. Каждая точка оформляется как задача: экран, сценарий, ожидаемая метрика, критерии приёмки. Дизайнер и разработчик не додумывают, что имелось в виду.
7. Контроль после релиза. Сравниваем метрику выбранного шага до и после выката, чтобы подтвердить эффект или откатить решение.

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

Карта экранов, прототипы и регламент правок

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

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

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

Кейс: путь до заказа сократился, отказ на оплате убран

Клиент — сервис доставки еды с приложением на двух платформах. Аудит показал, что воронка теряет заказ не на входе, а на выходе: до оформления человек проходил девять экранов, четыре из которых были служебными — подтверждение адреса, выбор интервала, повторный ввод телефона, «проверьте данные». На экране оплаты отваливались 38% корзин: платёжный шаг открывался как отдельный сценарий и терял корзину при сворачивании приложения.

Что было до

Девять экранов, 4 минуты 30 секунд от «добавить в корзину» до подтверждения, 38% отказов на оплате, доля повторных заказов — 21%. Больше половины обращений в поддержку — «оплата не прошла» и «слетела корзина».

Что изменили

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

Что стало

Оформление занимает 1 минуту 40 секунд, отказы на оплате — 11%, доля повторных заказов — 34%, обращения про оплату сократились почти вчетверо. Метрики снимали на равных отрезках до и после, без сезонных всплесков и праздничных пиков, — сдвиг держится на обеих платформах.

Чем отличается разбор по аналитике от интервью с пользователями

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

Сравнение методов исследования упирается в их ограничения: аналитика бессильна там, где сценарий формально проходит, но смысл шага не считывается, а интервью ошибаются в частоте — человек помнит яркое, а не типичное. Выбор метода исследования диктует вопрос, а не удобство: Nielsen Norman Group разводит качественные и количественные данные по типу задач, которые они способны закрыть.

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

Частые технические сомнения: доступы, данные, повторные проверки

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

Какой объём данных достаточен для разбора?

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

Что делать, если разработка параллельно правит приложение?

Фиксируем базовую версию сборки, на которой идёт разбор, и не смешиваем выводы с новыми изменениями. После релиза повторная проверка сценария на обновлённой сборке показывает, ушла ли точка разрыва, — сравниваем поведение до и после.

Где чаще находятся точки разрыва — в интерфейсе или сервисах?

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

Обсудим задачу: что прислать для стартовой оценки

Чтобы стартовая оценка была предметной, а не «посмотрим и скажем», нам достаточно минимального набора входных данных. Чем полнее картина по сценариям и метрикам, тем точнее мы называем объём работ, состав команды и порядок взаимодействия — и тем меньше уточняющих кругов до старта.

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

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

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