User flow: что это такое и как проектировать путь пользователя

По оценке Forrester Research, грамотно спроектированный интерфейс способен повышать конверсию сайта в разы, а каждый вложенный в UX доллар возвращает бизнесу заметно больше, чем был потрачен. При этом львиная доля потерь на цифровых продуктах происходит не из-за «некрасивого дизайна», а из-за запутанного пути: пользователь не понимает, что делать дальше, упирается в лишний шаг и уходит. Именно эту логику пути и описывает user flow — схема, которую проектируют до отрисовки экранов.

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

В этой статье разберём по-компанийному и на «вы»: что такое user flow простыми словами, зачем он бизнесу и команде, из каких элементов состоит, какие бывают виды, чем отличается от customer journey map и user story, как составить его пошагово, какими инструментами и на каких примерах. Опираемся на практику Nielsen Norman Group и Interaction Design Foundation и на собственный опыт проектирования продуктов.

Что такое user flow простыми словами

User flow — это схема (обычно блок-схема), которая показывает последовательность шагов и решений пользователя на пути к конкретной цели внутри продукта. Проще говоря, это ответ на вопрос «что человек нажимает и видит по очереди, чтобы дойти от старта до результата». Синонимы, которые вы встретите в статьях и ТЗ: путь пользователя, пользовательский сценарий, UX-сценарий, поток пользователя.

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

Чем user flow не является, важно проговорить сразу, чтобы не путать инструменты:

• Это не макет и не дизайн. Flow отвечает на вопрос «какая логика пути», а не «как это выглядит». Внешний вид экранов появляется позже — на этапе вайрфреймов и макетов.
• Это не карта всего пути клиента. User flow живёт внутри интерфейса; переживания клиента до и после контакта с продуктом описывает customer journey map (о разнице — ниже).
• Это не список требований. Требования формулируют текстом в user story; flow — это уже их визуальная реализация по шагам.

Технически user flow — это набор блоков (экраны и действия), соединённых стрелками, с точками ветвления, где путь расходится в зависимости от выбора пользователя или ответа системы. Такую схему легко читает и дизайнер, и разработчик, и владелец бизнеса — в этом её сила.

Зачем бизнесу и команде нужен user flow

User flow нужен, чтобы спроектировать логику продукта до того, как в него вложены деньги на дизайн и разработку. Исправить лишний шаг на схеме — это минуты; переделать уже отрисованные и свёрстанные экраны — дни работы команды. По классическому наблюдению из инженерии, дефект, найденный на этапе проектирования, обходится в разы дешевле, чем тот же дефект, обнаруженный уже в готовом продукте, — и исследования Nielsen Norman Group о ROI юзабилити подтверждают: ранняя проработка сценариев напрямую влияет на отдачу от продукта.

Конкретная польза user flow для бизнеса и команды:

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

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

Из чего состоит user flow: элементы схемы

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

• Точка входа (старт). Откуда пользователь попадает в сценарий: главная страница, рекламное объявление, письмо, пуш-уведомление, результат поиска. У одного flow может быть несколько точек входа.
• Экраны и состояния (прямоугольники). Страницы или экраны, которые видит пользователь: каталог, карточка товара, форма, экран подтверждения. Сюда же относятся служебные состояния — загрузка, пустой экран, экран успеха.
• Действия и переходы (стрелки). Что делает пользователь и куда это его ведёт: нажал кнопку, заполнил поле, свайпнул. Стрелка показывает направление движения по сценарию.
• Точки принятия решения (ромбы). Развилки, где путь расходится в зависимости от условия: авторизован пользователь или нет, есть товар в наличии или нет, прошла оплата или отклонена. От ромба всегда идут минимум две ветки — например «да» и «нет».
• Состояния ошибок и тупики. Что происходит, когда что-то пошло не так: неверный пароль, отклонённая карта, потеря связи. Хороший flow всегда предусматривает запасной путь, а не оставляет пользователя в тупике.
• Финал (цель). Точка, где пользователь достиг целевого действия: заказ оформлен, аккаунт создан, заявка отправлена. Ради неё и строится весь сценарий.

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

Виды user flow: Task Flow, Wireflow, UI/Screen Flow

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

Task Flow — линейная цепочка шагов

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

Wireflow — схема со скетчами экранов

Wireflow — это гибрид user flow и вайрфреймов: вместо абстрактных прямоугольников в узлах стоят упрощённые скетчи экранов. Такой вид показывает не только логику переходов, но и примерное содержание каждого экрана. Он особенно полезен для мобильных приложений, где важно видеть, как меняется экран после каждого действия. Подробнее о самих вайрфреймах — в нашей статье про вайрфреймы (wireframes).

UI/Screen Flow — детальная схема с реальными экранами

UI Flow (Screen Flow) — это самый детальный вид, где узлами выступают готовые макеты или реальные экраны интерфейса, соединённые стрелками переходов. Его собирают ближе к концу проектирования, когда дизайн уже отрисован, — чтобы показать полную навигацию по продукту. Такой flow часто делают прямо в Figma, связывая фреймы прототипа.

Вид flow	Детализация	Что в узлах	Когда применять
Task Flow	Низкая, линейно	Текстовые шаги	Старт проекта, быстрый скелет сценария
Wireflow	Средняя	Скетчи экранов	Проектирование логики + примерного содержания экранов
UI/Screen Flow	Высокая	Реальные макеты	Финальная навигация, передача в разработку

На практике эти виды не конкурируют, а сменяют друг друга по мере роста детализации проекта: начинают с Task Flow, добавляют ветвления в полноценный user flow, а к концу дизайна собирают UI Flow из готовых экранов.

User flow, CJM и User Story: в чём разница

User flow, customer journey map и user story — это три разных инструмента, которые часто путают, потому что все они «про пользователя». Разница в масштабе и назначении: user flow описывает шаги в интерфейсе, CJM — весь путь клиента по точкам контакта с брендом, user story — текстовое требование. Разведём их чётко.

• User flow отвечает на вопрос «как пользователь дойдёт до цели в интерфейсе». Это экранная схема одного сценария: шаги, действия, ветвления. Уровень — продуктовый, инструмент — дизайнерский.
• Customer Journey Map (CJM) отвечает на вопрос «что клиент переживает на всём пути к покупке и после». Она охватывает все точки контакта — рекламу, сайт, поддержку, доставку — и включает эмоции, барьеры и ожидания. Уровень — стратегический. Мы разбирали её отдельно в статье про customer journey map.
• User Story отвечает на вопрос «что нужно сделать» и формулируется текстом: «как <роль>, я хочу <действие>, чтобы <ценность>». Это единица требования в бэклоге, а не схема.

Проще всего запомнить связку так: user story описывает требование словами, user flow превращает это требование в визуальный маршрут по экранам, а CJM смотрит на всё это сверху — как один из этапов большого пути клиента. Они не заменяют друг друга, а работают на разных уровнях.

Критерий	User flow	CJM	User story
Что описывает	Шаги в интерфейсе к одной цели	Весь путь клиента по точкам контакта	Одно требование
Формат	Блок-схема	Карта этапов с эмоциями	Текст
Уровень	Продуктовый	Стратегический	Задачный
Охват	Внутри продукта	До, во время и после контакта	Одна функция
Кто использует	UX-дизайнер, разработчик	Продакт, маркетинг, UX-стратег	Продакт, аналитик, команда

Как составить user flow: пошаговая инструкция

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

1. Определите цель бизнеса и задачу пользователя. Сформулируйте целевое действие (оформить заказ, зарегистрироваться, оставить заявку) и то, что хочет получить пользователь на этом пути. Без ясной цели схема расплывётся.
2. Выберите персону или сегмент. Уточните, для кого строите сценарий: у нового и вернувшегося пользователя разные пути. Один flow — под один сегмент, иначе он станет нечитаемым.
3. Соберите точки входа. Перечислите, откуда человек попадает в сценарий: главная, реклама, поисковая выдача, письмо, пуш. Точки входа задают начало схемы и влияют на первые шаги.
4. Спроектируйте шаги и ветвления. Разложите путь на экраны и действия, добавьте точки принятия решения (ромбы) с ветками «да/нет»: авторизован или нет, есть товар или нет, прошла оплата или отклонена.
5. Учтите ошибки и тупики. Для каждого критичного шага продумайте, что произойдёт при сбое, и добавьте запасной путь. Именно на необработанных ошибках чаще всего теряется конверсия.
6. Визуализируйте схему. Перенесите сценарий в инструмент (Figma, FigJam, Miro, draw.io), используя единую нотацию и стрелки. Держите схему читаемой: слева направо или сверху вниз, без пересечений линий.
7. Протестируйте и итерируйте. Проверьте flow на реальных пользователях и данных аналитики, найдите лишние шаги и точки отвала, обновите схему. User flow — живой документ, а не разовый артефакт.

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

Инструменты для создания user flow

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

Инструмент	Тип	Цена	Кому подходит
Figma / FigJam	Дизайн + вайтборд	Бесплатный тариф есть	Тем, кто уже делает макеты в Figma — flow и дизайн в одном месте
Miro	Онлайн-доска	Бесплатный тариф есть	Командным воркшопам и совместной проработке сценариев
Whimsical	Диаграммы + флоучарты	Условно-бесплатный	Быстрым аккуратным flow без лишних настроек
Overflow	User flow из макетов	Платный	Презентации интерактивных flow из готовых экранов
draw.io (diagrams.net)	Редактор диаграмм	Бесплатный	Простым блок-схемам без регистрации и оплаты

Отдельно стоит сказать про AI-помощники: современные редакторы и плагины умеют собирать черновик flow по текстовому описанию сценария. Это ускоряет старт, но черновик всё равно нужно проверять руками — искусственный интеллект не знает специфики вашего продукта и легко пропускает состояния ошибок. Начинающим достаточно бесплатной связки FigJam или draw.io; продвинутым командам — Figma для единства flow и макетов. Больше вариантов мы собрали в обзоре инструментов для прототипирования интерфейсов.

Примеры user flow

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

Пример для мобильного приложения: заказ и оплата такси

Сценарий «вызвать такси» в мобильном приложении обычно выглядит так:

1. Пользователь открывает приложение (точка входа) → экран карты.
2. Ромб: авторизован? Если нет — экран входа/регистрации, затем возврат на карту.
3. Указывает точку назначения → приложение показывает цену и класс машины.
4. Ромб: устраивает цена? Если нет — меняет класс или маршрут (ветка назад).
5. Нажимает «Заказать» → ромб: привязана карта? Если нет — экран добавления карты.
6. Ромб: оплата прошла? Если отклонена — сообщение об ошибке и выбор другого способа (запасной путь, не тупик).
7. Машина найдена → экран статуса поездки (финал сценария заказа).

Обратите внимание, сколько здесь развилок: без них flow превратился бы в линейную «идеальную» цепочку, которая ломается на первом же пользователе без привязанной карты.

Пример для сайта: оформление заказа в интернет-магазине

Классический flow оформления заказа на сайте:

1. Пользователь заходит на карточку товара (точка входа — из каталога, поиска или рекламы).
2. Нажимает «В корзину» → ромб: продолжить покупки или оформить? Ветка «продолжить» ведёт назад в каталог.
3. Переходит в корзину → нажимает «Оформить».
4. Ромб: авторизован? Если нет — предлагаем вход, регистрацию или оформление как гость (важная развилка для конверсии).
5. Заполняет данные доставки → выбирает способ оплаты.
6. Ромб: оплата прошла? При отказе — понятное сообщение и повтор, а не пустой экран.
7. Экран «Заказ оформлен» с номером и деталями (финал — целевое действие достигнуто).

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

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

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

• Лишние шаги. Каждый дополнительный экран на пути к цели — это точка, где пользователь может уйти. Если шаг можно убрать или объединить с другим, уберите. Идеальный flow короткий, но не в ущерб понятности.
• Нет обработки ошибок. Схема рисует только «счастливый путь», а что происходит при отклонённой оплате или потере связи — не продумано. В проде это оборачивается тупиками и брошенными сценариями.
• Смешение с CJM. В user flow пытаются впихнуть эмоции клиента, рекламные каналы и офлайн-точки контакта. В итоге схема раздувается и перестаёт быть рабочим инструментом дизайна. Всё это — уровень customer journey map, а не flow.
• Один flow на все сегменты. Попытка описать одной схемой и новичка, и опытного пользователя, и админа делает её нечитаемой. Под каждый значимый сегмент — свой flow.
• «Дизайн до сценария». Команда начинает рисовать красивые макеты, не спроектировав логику пути. Потом выясняется, что половину экранов нужно переставить, — и работа переделывается заново, уже дорого.

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

Частые вопросы (FAQ)

Чем user flow отличается от customer journey map (CJM)?

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

Чем user flow отличается от user story?

User story — это короткая текстовая формулировка требования в формате «как <роль>, я хочу <действие>, чтобы <ценность>». User flow — визуальная схема того, как это требование реализуется по шагам в интерфейсе. Story описывает, что нужно сделать, flow — как именно пользователь это сделает экран за экраном.

Кто в команде рисует user flow?

Чаще всего user flow проектирует UX-дизайнер или продуктовый дизайнер, но в работе участвуют продакт-менеджер (цели и метрики), аналитик (данные о поведении) и разработчик (техническая реализуемость). На небольших проектах flow может собрать и продакт, а дизайнер потом доводит его до детальных экранов.

В какой программе лучше делать user flow новичку?

Новичку удобнее всего начать с бесплатных инструментов: FigJam или Figma, если уже используете их для макетов, либо draw.io для простых блок-схем. Они не требуют глубокого обучения, поддерживают базовую нотацию (прямоугольник, ромб, стрелка) и совместную работу онлайн.

Сколько user flow нужно для одного продукта?

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

Нужно ли прорабатывать все сценарии ошибок?

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

Обязательно ли делать user flow до дизайна макетов?

Да, это дешевле и быстрее. Спроектировать логику пути на схеме из прямоугольников и стрелок занимает часы, а переделать отрисованные и свёрстанные экраны — дни и деньги. User flow помогает найти лишние шаги и тупики ещё до того, как дизайнер начнёт рисовать интерфейс. Хороший порядок такой: user story → user flow → вайрфреймы → прототип → макеты.