Пользовательские сценарии и потоки: от задачи к экранам

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

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

1. Сценарий, поток, задача: разные слова про разное

Три термина постоянно путают, а они отвечают на разные вопросы и живут на разных стадиях.

Сценарий отличается от потока тем, что в нём есть контекст и нет интерфейса. Пример сценария:

Марина, бухгалтер подрядчика, в 17:40 получает от заказчика письмо: «акты за март не приняты, там неверный НДС». До конца рабочего дня 20 минут, дома ребёнок. Ей нужно понять, какие именно акты сломаны, исправить их и отправить заново — так, чтобы завтра не пришлось объясняться. Она заходит в портал с рабочего ноутбука, где уже открыто восемь вкладок, и не помнит, куда в прошлый раз нажимала.

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

Наконец, есть родственные нотации из смежных дисциплин: сценарии использования (use cases) и BPMN. Use case описывает основной и альтернативные ходы текстом, BPMN — процесс с дорожками ответственности (подробно — в треке системного анализа: UML и BPMN). UX-поток отличается фокусом: он показывает не то, как процесс устроен внутри компании, а то, что видит и решает человек по ту сторону экрана. Иногда они совпадают, чаще — нет: у бизнеса «согласование в трёх отделах» — три задачи, для пользователя это один шаг «отправил и жду».

2. Четыре уровня зума

Самая частая причина бесполезной схемы — смешение масштабов: на одном листе «узнал о продукте из рекламы» и «нажал Enter в поле поиска». Разделите уровни, у каждого свой горизонт времени и свой вопрос.

Практическое следствие: если проблема не решается на своём уровне, поднимитесь выше. Люди не находят кнопку «Экспорт» — соблазн покрасить её ярче (уровень экрана). Но на уровне потока часто видно, что экспорт вообще не нужен: человек экспортировал в Excel, чтобы посчитать сумму по фильтру, — значит, чинить надо суммой в интерфейсе. Обратный случай тоже реален: путь безупречен, а конверсия падает, потому что на шаге оплаты нет состояния «платёж обрабатывается» и люди жмут кнопку по три раза. Уровень диагностики должен совпадать с уровнем причины.

3. Обратный ход: проектируем поток от завершения

Естественный порыв — рисовать слева направо от точки входа. Это ведёт к потоку, который отражает устройство системы, а не задачу. Надёжнее строить справа налево.

1. Сформулируйте завершение глазами человека. Не «создана запись в БД», а «Марина уверена, что исправленные акты ушли и заказчик их увидит». Это разные критерии: первый закрывается редиректом, второй требует подтверждения с номером и датой, а возможно, и письма.
2. Опишите точку входа честно. Их обычно несколько: из письма, из поиска, по прямой ссылке из чата, из истории браузера, с телефона в метро. Поток, у которого один вход «главная страница», — фантазия.
3. Выпишите решения, а не экраны. Шаг существует, только если человек что-то решает или сообщает. «Приветственный экран с кнопкой Начать» — не шаг, а налог.
4. Для каждого решения спросите: чем человек его обеспечивает. Чтобы выбрать доставку, нужно знать срок и цену; чтобы выбрать тариф — понять, что входит; чтобы подтвердить удаление — понять, что именно исчезнет и обратимо ли. Недостающая информация — либо новый элемент на экране, либо перестановка шагов.
5. Добавьте ветвления (следующий раздел) и петли восстановления: что делает человек, когда ветка пошла не туда.
6. Разметьте состояния каждого шага, который ходит в сеть или зависит от прав.
7. Проверьте обратимость: из каждого шага должен быть путь назад или явно записанная причина, почему его нет.

Вот тот же поток, что на схеме, в виде графа. Обратите внимание на подписи рёбер: это условия, а не «да/нет».

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

4. Пять источников ветвлений

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

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

5. Поток как данные: схему можно проверять автоматически

Схема в графическом редакторе устаревает через две недели и не проверяется ничем. Поэтому у зрелых команд поток живёт ещё и в текстовом виде — в репозитории, рядом с кодом. Формат вторичен (YAML, JSON, mermaid), важно, что его читает не только человек.

Модель данных, которой достаточно для описания потока:

Тот же поток в YAML — файл живёт в репозитории продукта рядом с кодом:

# flows/acts-fix.yaml
goal: "исправленные акты отправлены, у человека есть подтверждение с номером"
start: list
terminal: [done, waiting]
steps:
  list:
    decision: "какой акт чинить первым"
    needs: "причина отклонения видна прямо в списке"
    states: [empty, loading, error]
    transitions: {open: diff}
  diff:
    decision: "чиню сам или зову бухгалтера заказчика"
    needs: "какие строки не сошлись и на какую сумму"
    states: [loading, error, denied]
    transitions: {edit: edit, comment: waiting, back: list}
  edit:
    decision: "какие значения поставить"
    states: [error, partial]
    transitions: {submit: check, back: diff}
  check:
    decision: "—"                                            # системный шаг, решений нет
    states: [loading, error, partial]
    transitions: {ok: done, invalid: edit, timeout: edit}     # повтор идемпотентен
  done:
    no_back_reason: "акт отправлен; отзыв — отдельный поток"
  waiting:
    no_back_reason: "ждём ответа, состояние видно в списке"

Псевдокод проверки:

достижимые ← обход_в_ширину(от старта по переходам)
для каждого шага S:
    нет выходов и S не терминальный        → «тупик»
    S не в достижимых                      → «недостижим»
    нет пути назад и нет причины           → «невозвратный шаг»
    S внешний и нет ветки на невозврат     → «отдали наружу без страховки»
    цели перехода нет среди шагов          → «битая ссылка»

Реализация, которая гоняется в CI вместе с тестами:

"""Валидатор потоков: тупики, недостижимые шаги, невозвратные и внешние ветки."""
import sys
from collections import deque

import yaml


def reachable(steps: dict, start: str) -> set[str]:
    """Обход в ширину от стартового шага. Время O(V + E), память O(V)."""
    seen, queue = {start}, deque([start])
    while queue:
        for target in steps[queue.popleft()].get("transitions", {}).values():
            if target in steps and target not in seen:
                seen.add(target)
                queue.append(target)
    return seen


def check(flow: dict) -> list[str]:
    steps, terminal = flow["steps"], set(flow["terminal"])
    seen = reachable(steps, flow["start"])
    problems: list[str] = []
    for name, step in steps.items():
        moves = step.get("transitions", {})
        if not moves and name not in terminal:
            problems.append(f"тупик: из «{name}» нет ни одного выхода")
        if name not in seen:
            problems.append(f"недостижим: в «{name}» не ведёт ни один переход")
        if name not in terminal and "back" not in moves and not step.get("no_back_reason"):
            problems.append(f"невозвратный «{name}»: нет пути назад и не записано, почему")
        if step.get("external") and "timeout" not in moves:
            problems.append(f"внешний «{name}»: нет ветки «человек не вернулся»")
        problems += [f"битый переход «{name}» --{label}--> «{t}»"
                     for label, t in moves.items() if t not in steps]
    return problems


if __name__ == "__main__":                       # ненулевой код возврата ломает сборку
    found = check(yaml.safe_load(open(sys.argv[1], encoding="utf-8")))
    print(*(f"✗ {p}" for p in found), sep="\n")
    sys.exit(1 if found else 0)

Обе функции — O(V + E) по времени и O(V) по памяти (V — шаги, E — переходы); для потоков из десятков шагов это микросекунды, так что проверка спокойно живёт в pre-commit. Ценность не в алгоритме, а в дисциплине: пустое состояние невозможно «забыть», если файл без него не проходит проверку. Не увлекайтесь: такой файл оправдан для 3–7 ключевых сценариев продукта, а не для каждого экрана — иначе он превращается в мёртвую документацию.

6. Разбор: почему эта форма неудобна

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

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

Три системных вывода из разбора:

• Половина проблем формы — не про форму, а про поток. Развилка «физлицо или компания» до формы убирает три поля. Проверка ИНН по реестру убирает ещё два. Форму чинят выше по течению.
• Стоимость поля несимметрична. Необязательное поле стоит секунду внимания, обязательное — может стоить всей заявки, если человек не может его заполнить в принципе. Поэтому обязательность — самое дорогое решение в форме.
• Момент проверки важнее текста проверки. Сравнительные исследования Baymard Institute по чекауту показывают: проверка «на лету» с понятной формулировкой сокращает число брошенных форм заметно сильнее, чем украшение сообщений. Материалы — baymard.com/checkout-usability.

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

7. Разбор: почему пользователь не нашёл кнопку

Второй канонический дефект. «Кнопку не видно» — это симптом, а причин у него конечный список, и лечатся они по-разному.

Разберём главные причины подробно.

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

Нет информационного запаха. Теория информационного поиска (information foraging, Pirolli & Card, Psychological Review, 1999) описывает поведение человека в интерфейсе как поиск пищи по запаху: он идёт туда, где формулировка обещает приближение к цели. Если человек ищет «выгрузить для бухгалтерии», а кнопка называется «Экспорт данных» — запаха нет. Проверка дешёвая: возьмите слова из исследований и сравните с подписями. Материал NN/g: Information Scent.

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

Слепота к рекламным паттернам. Действие оформлено как баннер (яркий прямоугольник справа, с иконкой и восклицанием), и его пролистывают, не читая. Явление многократно воспроизведено, обзор — у NN/g: Banner Blindness.

Серый disabled без объяснения. Человек видит кнопку, но она неактивна и молчит о том, что надо сделать. Хуже всего вариант, когда причина известна системе («не заполнен ИНН»), но не показана. Правильнее: кнопка активна, при нажатии — фокус на незаполненном поле с объяснением; или кнопка неактивна, но рядом текст «заполните ИНН, чтобы продолжить». Подробнее про состояния — в взаимодействии и состояниях.

Нет иерархии. Шесть кнопок одного веса в шапке карточки равны отсутствию кнопок: человек не выбирает, а сканирует и уходит. Здесь работает не «закон Хика» в лоб (про его границы честно написано в основах визуального дизайна), а простое правило: у экрана должно быть одно главное действие, вытекающее из шага потока, остальные — визуально тише.

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

8. Арифметика воронки: почему длинный поток дырявый

Каждый шаг — это множитель. Если на шаге i доля дошедших c_i, то сквозная конверсия потока из n шагов:

$$C = \prod_{i=1}^{n} c_i$$

Отсюда неприятный, но полезный вывод. Даже если каждый шаг «почти идеален» — c_i = 0.97 — поток из двенадцати шагов даёт $0.97^{12} \approx 0.69$: треть людей теряется на ровном месте. Именно поэтому «добавим ещё один маленький экранчик» — не бесплатное решение, даже если экранчик хороший.

Второй вывод — про то, куда вкладываться. Частная производная сквозной конверсии по шагу равна

$$\frac{\partial C}{\partial c_i} = \frac{C}{c_i}$$

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

Важная оговорка: «меньше шагов» ≠ «лучше». Знаменитое «правило трёх кликов» проверялось эмпирически и не подтвердилось: Джошуа Портер в исследовании UIE (articles.uie.com/three_click_rule) показал, что вероятность бросить задачу почти не зависит от числа кликов — люди уходят тогда, когда перестают понимать, приближаются ли они к цели. Иначе говоря, уверенность важнее краткости. Пять понятных шагов с ясным прогрессом лучше, чем два экрана-простыни с тридцатью полями. Хороший разбор компромисса «мастер против одного экрана» — у NN/g: Wizards и Progressive Disclosure.

Как связать это с продуктовыми показателями и не обмануть себя выборкой — в метриках UX и в треке продакт-менеджмента (метрики).

9. Один шаг — это не один экран: состояния и внешние системы

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

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

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

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

Ещё три перехода, которые надо явно решить на этапе потока, потому что потом они всплывают как баги:

• Кнопка «Назад» браузера. Возврат на шаг оплаты после успеха — что показываем? Обычно правильный ответ: подтверждение, а не форму.
• Двойная вкладка. Человек открыл поток дважды (это норма для людей, которые «на всякий случай»). Второй экземпляр должен увидеть актуальное состояние, а не начать параллельный процесс.
• Восстановление сессии. Ноутбук закрыли на шаге 4, вернулись через день. Черновик жив? Ссылка из письма ведёт на шаг 4 или в начало? Ответ зависит от цены потери, но ответ должен быть.

10. Где здесь исследования, а где вкусовщина

Честность в этом вопросе отличает проектировщика от человека с насмотренностью. Разложим утверждения о потоках по трём корзинам.

Есть данные и воспроизводимые эффекты.

• Сокрытие информации, нужной для решения, повышает отказ. Скрытая до последнего шага стоимость доставки — устойчиво первая причина брошенных корзин по сводкам Baymard (baymard.com/lists/cart-abandonment-rate).
• Принудительная регистрация до покупки снижает конверсию. Многократно воспроизведено; гостевое оформление — стандартная рекомендация Baymard.
• Момент валидации влияет на успех заполнения формы (проверка на лету против проверки после отправки).
• Закон Фиттса — количественная модель, применимая к размеру и расстоянию целей, включая соседство «Отправить» и «Очистить».
• Число шагов само по себе слабо влияет на отказ — эффект даёт потеря уверенности, а не клики (UIE, 2003).

Зависит от контекста, проверяется на вашем продукте.

• Мастер (несколько шагов) против одного длинного экрана: для редкой сложной задачи с ветвлениями обычно лучше мастер, для частой рутинной — один экран. Оба варианта имеют примеры успеха, решает частота использования и уровень экспертизы аудитории.
• Автосохранение против явной кнопки «Сохранить»: в документах автосохранение выигрывает, в финансовых операциях явное подтверждение снижает тревогу.
• Показывать ли номер шага и прогресс: помогает при 3–5 шагах, вредит, когда шагов десять и человек видит, во что вписался.
• Подтверждение опасного действия: диалог против отменяемого действия с уведомлением «Удалено. Отменить?». Второе обычно лучше, но не там, где отмена технически невозможна.

Вкус и договорённость (спорить бессмысленно, надо решить один раз и записать в систему).

• Где стоит основная кнопка — справа или слева от вторичной. Есть платформенные конвенции (в вебе чаще справа), и единственное реальное требование — единообразие внутри продукта.
• Стиль анимации перехода между шагами, скругления, оттенок акцентного цвета.
• Формулировка «Далее» против «Продолжить». Важно, чтобы слово было одно и то же во всём потоке; какое именно — вопрос тона.

Практический приём для команды: перед спором задайте вопрос «какой факт заставит нас изменить мнение?». Если ответа нет ни у кого — это третья корзина, решайте голосом старшего дизайнера за минуту и идите дальше. Если ответ есть — это первая или вторая корзина, и спор решается тестом или данными.

11. Доступность на этапе потока

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

Показательный пример «барьера уровня потока»: код из SMS на отдельном экране с автопереходом через 30 секунд. Верстка идеальна, ARIA на месте — но человек, который переключается в SMS и возвращается, не успевает; человек с экранным диктором не слышит обратный отсчёт; человек с тремором не попадает по мелким полям для отдельных цифр. Чинится всё это перепроектированием шага, а не атрибутами.

12. Передача в разработку: поток как контракт

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

Что входит в пакет передачи одного потока.

1. Цель и критерий завершения — та самая формулировка глазами человека.
2. Схема потока с подписанными условиями на рёбрах, всеми ветками из раздела 4 и петлями восстановления.
3. Список состояний каждого шага с финальными текстами (не «Lorem», не «Ошибка»).
4. Точки входа — все, включая прямые ссылки и письма.
5. Что фиксировано жёстко и почему — например: «сумма и срок доставки видны до ввода карты; это причина −17 % в текущей воронке».
6. Что оставлено на усмотрение разработки — например: анимация перехода, порядок загрузки блоков, конкретный компонент выпадающего списка из дизайн-системы.
7. Открытые вопросы с именем ответственного, а не с пометкой «уточнить».

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

• Макет — это один кадр, а интерфейс — множество. Один экран существует в десятках вариантов: длинное имя, пустой список, ошибка, локаль с длинными словами, зум 200 %, шрифт, подставленный ОС. Совпасть «в пиксель» может ровно один кадр из этого множества, и обычно он не самый важный.
• Среда рендеринга не подчиняется макету. Разные движки округляют субпиксели, по-разному считают межстрочный интервал, подставляют системные шрифты; на мобильных ОС часть компонентов рисует платформа (клавиатура, пикер даты, меню выделения текста). Требовать здесь совпадения — требовать переписать чужой код.
• Пиксельная приёмка съедает бюджет ревью. Час, потраченный на «отступ 14 вместо 16», — час, не потраченный на «а что если сервер ответил 409».
• Она конфликтует с системой. Если компонент из дизайн-системы даёт отступ 16, а в макете случайно 14, то «пиксель в пиксель» означает форк компонента — то есть медленную смерть системы.

Что вместо. Приёмка по контракту, а не по картинке:

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

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

13. Гигиена схем: как рисовать, чтобы читали

Схема потока — тоже интерфейс, у него есть свои пользователи (разработчик, аналитик, тестировщик, новый человек в команде через полгода) и свои дефекты.

• Один вход, направление одно. Слева направо или сверху вниз, без встречных стрелок через весь холст.
• Подписи на рёбрах — условия, а не «да/нет». «3 строки не сошлись» читается без контекста, «нет» — нет.
• Один уровень зума на схеме. Не смешивайте «выбрал тариф» и «нажал Enter».
• Ошибки и пустые состояния — на схеме, а не в комментариях. Иначе их не реализуют.
• Легенда, если фигур больше трёх. Прямоугольник — экран, ромб — решение системы, скруглённый — конец потока.
• Версия и владелец. Схема без даты и имени через месяц становится источником спора «а это ещё актуально?».
• Схема генерируется из текста, если можно. mermaid в репозитории переживает смену инструмента и попадает в ревью кода вместе с изменением поведения.

Инструменты не принципиальны: FigJam, Miro, Whimsical, draw.io, mermaid, обычный текст. Принципиально, чтобы схема лежала там, где её увидят при изменении поведения. Схема в личном файле дизайнера — не документация.

14. Типичные ошибки

• Только счастливый путь. Пять экранов, все зелёные, ни одной ветки. Такой поток не даёт разработке ничего, кроме порядка экранов.
• Один вход «главная». Реальные люди приходят из письма, поиска и чата; поток, спроектированный от главной, ломается на прямой ссылке.
• Шаг ради шага. Приветственные экраны, промежуточные подтверждения без риска, «выберите тип», когда тип выводится из данных. Каждый шаг — множитель в формуле из раздела 8.
• Смешение уровней зума — схема, где рядом «привлечение из рекламы» и «выбор из выпадающего списка».
• Развилка без сходимости. Ветка нарисована, но не показано, куда она возвращается; в коде это станет тупиком.
• Игнор внешних систем. Оплата, госуслуги, вход через провайдера — «дальше не наша зона». Возврат в поток — всегда ваша зона.
• Состояние «неизвестно» как ошибка. Таймаут показан текстом «Ошибка», человек платит второй раз.
• Поток без прав. Роль «наблюдатель» видит кнопки, которые для неё не работают.
• Схема, не пережившая релиз. После запуска правда — в коде и аналитике; устаревшая схема хуже отсутствующей.
• Оптимизация числа кликов вместо уверенности. Сокращение шагов при потере понятности снижает конверсию.
• Спор о вкусовщине как о факте и пиксельная приёмка — два способа потратить бюджет внимания впустую.

Мини-итог и чеклист

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

Перед тем как отдавать поток дальше, проверьте:

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

Источники

• A. Cooper, R. Reimann, D. Cronin. About Face: The Essentials of Interaction Design — сценарии и целеориентированное проектирование; K. Goodwin. Designing for the Digital Age — от сценария к потоку и структуре экранов.
• A. Cockburn. Writing Effective Use Cases — основной ход и альтернативы: дисциплина, из которой UX-поток вырос.
• P. Pirolli, S. Card. Information Foraging // Psychological Review, 1999 — модель поиска по «запаху»; практическое изложение — NN/g, Information Scent.
• Nielsen Norman Group: Journey Mapping 101, UX Mapping Cheat Sheet, Task Analysis, Wizards, Progressive Disclosure, Error Message Guidelines, Banner Blindness.
• J. Porter. Testing the Three-Click Rule // UIE, 2003 — articles.uie.com/three_click_rule.
• Baymard Institute: Checkout usability, Cart abandonment rate — крупнейший открытый свод данных по оформлению заказа.
• L. Wroblewski. Web Form Design — rosenfeldmedia.com/books/web-form-design.
• W3C. Understanding WCAG 2.2: Timing Adjustable, On Input, Error Prevention (Legal, Financial, Data).
• Mermaid — mermaid.js.org: схемы потоков текстом, живущие в репозитории рядом с кодом.

Что дальше

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

Вайрфреймы и прототипы: быстрая проверка идей до кода