Заказчик почти никогда не приходит с запросом «нарисуйте мне user flow». Он приходит с прототипом, в котором отдельные решения могут противоречить друг другу или с идеей без единого зафиксированного сценария. И в таких случаях я не двигаюсь дальше, пока не соберу из этих вводных понятную схему.

В этой статье

За десять лет работы с CRM, LMS и SaaS-продуктами я поняла, что user flow помогает увидеть то, что заказчик сам иногда не осознаёт про свой продукт. В этой статье я показываю, как определяю границы сценария, когда user flow действительно нужен, когда без него можно обойтись и какие ошибки превращают рабочую схему в громоздкую и нечитаемую.

Меня зовут Лена Плинер. Я занимаюсь UX/UI дизайном сложных интерфейсов: CRM, ERP, SaaS-платформ и сервисов, веб- и мобильных приложений. Сотрудничаю с заказчиками и командами как попроектный дизайнер. Занимаюсь дизайном 15+ лет и мне всегда есть что рассказать. Делаю это в своем телеграм-канале, где пишу о том как организована моя работа, как решаю бизнес и дизайн задачи клиентов и о том, что помогает мне это делать.

Что это за инструмент

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

Это не единственный инструмент декомпозиции продукта, с которым я работаю. До user flow иногда имеет смысл сделать карту экранов — поэкранную структуру, которая показывает иерархию окон в приложении: что на верхнем уровне, что глубже. А если на стороне бизнеса есть процессы, влияющие на интерфейс, но происходящие offline, например доставка, я сначала делаю карту бизнес-процессов. Когда такая общая структура уже понятна, с помощью user flow я разбираюсь, что происходит внутри неё, в каких случаях какой путь проходит пользователь и есть ли альтернативные варианты.

Как проектировать поток: точка старта и точка завершения

Точку завершения я определяю раньше, чем начинаю рисовать схему, и это обычно самая сложная часть работы, потому что финальная цель не всегда очевидна и далеко не всегда сводится к «деньги пришли». Практический способ, который я использую: до отрисовки user flow я собираю user stories. В их структуре («я как пользователь хочу сделать X, чтобы получить Y») результат Y уже зафиксирован, и он становится ориентиром для конечной точки пользовательского потока. Часть user stories описывает не конечный результат, а отдельные шаги к нему. Я рассматриваю их как части более длинного пользовательского пути.

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

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

Всё, что лежит между точкой старта и точкой завершения одного пользовательского потока — это шаги, из которых складывается конкретный сценарий. Я не считаю шагом обязательно отдельный экран: это может быть действие на странице или смена состояния экрана. В проекте X-Ray для бренда «Окраина» я работала над интерфейсом рентген-детектора пищевого производства. Последовательность «просветили продукт → программа анализирует → отбраковка или пропуск» здесь отображается сменой состояний одного и того же экрана на тач-панели.

Схема user flow из проекта XRay для Окраина

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

Как задача определяет вид user flow

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

В проекте Check Zimmer — веб-платформе поиска жилья для приезжающих на работу в Германию — я делала userflow именно на уровне средней подробности: две роли, арендатор и арендодатель, и цикл с возвратами (отклик → предложение → согласие, отклонение или торг). Мне было важно явно показать этот цикл на схеме, потому что без него терялась логика повторных попыток договориться. Основной путь я отрисовала по принципу «только необходимые для первого результата шаги», но торг и повторные предложения, хотя и не обязательны для каждого пользователя, важны для логики продукта, поэтому я включила их как значимую альтернативную ветку. В подробную версию для разработки я бы добавила технические детали вроде обработки статусов отклика и условий, при которых предложение считается устаревшим; здесь, на уровне MVP, схема служила и для того, чтобы разобраться самой, и для синхронизации с командой.

Схема user flow из проекта «Check Zimmer»

Зачем нужно делать user flow: четыре сценария применения

Я использую user flow в четырёх ситуациях. Первая — разобрать уже существующий сценарий. Схема помогает разобрать структуру уже существующего сценария: увидеть лишние или недостающие шаги, редкие и нестандартные ситуации, параллельные ветки. В проекте Promokodus я делала именно такой аудит. Я собирала существующие сценарии в схему, фиксировала проблемы и гипотезы их решения, а затем на той же схеме показывала, как должен измениться сценарий.

Схема аудита user flow из проекта Promokodus: разбор существующей воронки

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

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

Третий — работа в связке с метриками. Если сопоставить разложенную на схему воронку с метриками, видно, где пользователи отваливаются, где тормозят, а где, наоборот, проводят подозрительно мало времени для сложного действия.

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

Схема user flow из проекта CRM для детского сада: сценарий добавления пользователя

Где user flow не нужен

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

Частный случай, который у меня встречается регулярно: в остальном линейном продукте есть один сложный узел, например собственная SSO-авторизация, и тогда я рисую user flow только для этого узла. Так было в проекте LMS для МГУ (Teach-In): весь продукт был линейным, кроме авторизации через SSO — единственного места, где логика ветвилась и требовала явной схемы. Отдельный user flow позволил разобрать этот узел до отрисовки остальных экранов и зафиксировать для разработки последовательность и ветвления сценария авторизации.

Схема user flow из проекта Teach-In: ветвление сценария SSO-авторизации на фоне линейного продукта

Гибридный формат (wireflow): блок-схема + мокапы экранов

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

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

Wireflow из проекта Eat Me Alisa: мокапы экрана заказа в разных статусах — в обработке, готовится, готов, выдан, оплачен, отменён

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

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

Частые ошибки/грабли при проектировании user flow

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

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

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

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

Как объяснять заказчику/команде, зачем нужен user flow

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

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

Спасибо за внимание!

User flow. Как проектировать и зачем