Разработка User Flow диаграмм мобильного приложения

User flow diagram: где ломается путь пользователя

User flow diagram нужен не для того, чтобы показать счастливый путь от входа до оплаты, а чтобы зафиксировать точки отвала: места, где пользователь закрывает приложение и не возвращается. На схеме они видны только тогда, когда нарисованы не одни успешные переходы, но и все альтернативные ветки — обычно не хватает именно их.

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

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

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

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

Что даёт проработанная схема экранов и переходов

Единая схема экранов и переходов — это не картинка для отчёта, а рабочий контракт между продуктом, дизайном и разработкой. Пока сценарии использования живут в переписке и головах, каждый участник держит свою версию, а расхождения всплывают на сборке, когда правка стоит дороже всего. Схема (user flow diagram) фиксирует точки входа, развилки и тупики до того, как написан код, и лежит в одном файле в Figma — правки видит вся команда сразу. Что это даёт в измеримых величинах:

• Число шагов до цели сокращается на 1–3: лишние экраны подтверждения, дублирующие входы и промежуточные состояния убираются ещё на схеме.
• Доля завершённых действий растёт: брошенные сессии на развилках видны до релиза, а не после отчётов об установках.
• Время на согласование правок падает в разы: обсуждается одна версия сценария, а не три противоречащих макета.
• Сценарии использования покрыты целиком: у каждого состояния экрана — загрузка, пустой список, ошибка — описан переход.
• Приёмка идёт по готовым маршрутам: проверяющий проходит сценарий по схеме и сразу называет расхождение с реализацией.
• Новый инженер входит в проект быстрее: схема отвечает на вопросы, которые иначе задают в чате по одному.

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

Сравнение подходов: диаграмма, прототип, карта экранов

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

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

На практике это не выбор одного варианта, а связка: диаграмма остаётся источником правды по логике и переживает десятки правок, карта экранов служит реестром для дизайна и приёмки, прототип закрывает два-три критичных пути. Гайдлайны платформ — Material Design и Human Interface Guidelines — держим как рамку, но решения принимаем по вашим сценариям.

Как мы проектируем путь пользователя: этапы работ

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

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

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

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

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

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

Кейс: сократили отвал на регистрации почти вдвое

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

Где теряли пользователей

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

Что изменили в пути

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

Итог первого цикла: отвал на регистрации сократился почти вдвое, доля доходящих до первого заказа выросла с 22 до 41%, выросла и доля возвращающихся пользователей. Такую же карту пути и набор метрик мы фиксируем до старта работ — чтобы результат замерялся, а не обсуждался.

Чем карта экранов отличается от прототипа и макета

Карта экранов (user flow diagram) фиксирует только логику перемещения: какие экраны есть, что пользователь на каждом делает и где маршрут ветвится — авторизован он или нет, есть ли товар в корзине. Внешний вид, цвета, отступы в неё не входят, и это осознанно: карту можно переписать целиком, не трогая остальную документацию.

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

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

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

Частые технические сомнения перед началом работ

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

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

Сколько времени потребуется от нашей команды?

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

Хватит ли проработки, чтобы разработка шла без догадок?

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

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

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

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

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

Что стоит прислать вместе с описанием задачи:

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

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