Исходный размер 1140x1600

3.5. Сценарий как машина состояний — спецификация, приоритет, крайние случаи

PROTECT STATUS: not protected

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

Рабочий вопрос

Что должно измениться в мире после каждого действия — и кто заметит, если изменение не состоялось?

big
Исходный размер 2304x1296

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

Персона, работа, ситуация

big
Исходный размер 2304x1296

Архивная лекция предлагала заменить декоративные персоны подходом Jobs to Be Done. Совет остаётся полезным: возраст, любимый бренд и фотография из фотостока редко объясняют, почему человек доверит магазину память или войдёт в коллективную сделку. Но формула работы тоже бывает слишком гладкой. Институциональный проект нуждается в ситуации — сцеплении мотива, ограничения, риска, других акторов и уже произошедшей истории.Записывайте её так:> Когда [контекст и нарушение равновесия], участник стремится [изменить состояние], однако [ограничение или конфликт], поэтому обращается к институту и ожидает [проверяемое последствие].«Купить редкий объект» почти ничего не задаёт. «После смерти соавтора хранитель хочет передать право на незавершённый объект музею, но контракт требует согласия отсутствующего владельца» — уже машина, способная произвести интерфейс.

Исходный размер 2304x1296

Функциональный паук

Исходный размер 2304x1296

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

Story map: позвоночник и глубина

Исходный размер 2304x1296

User Story Mapping раскладывает путь по горизонтали и варианты каждого шага по вертикали. Для нашего модуля верхняя линия — институциональный позвоночник: войти → обнаружить → понять право → выбрать → согласовать → обменять → получить → распорядиться. Под каждым шагом лежат основной ход, альтернативы, ошибки и восстановление.Карта одновременно показывает объём и позволяет провести линию первой версии. Прототип обязан доказать системный закон целиком; ему не требуется изображать весь возможный продукт. Если команда подробно рисует регистрацию и оставляет возврат фразой «потом», значит, удобный кусок производства победил смысл проекта.

Исходный размер 1152x778
Исходный размер 2304x1296

Четыре жанра описания

Не смешивайте уровни:1. Концептуальный сценарий объясняет, зачем институт существует и какой конфликт перерабатывает.
2. Сценарий состояний перечисляет участников, события, условия и переходы.
3. Экранный контракт говорит, что интерфейс показывает, принимает, запрещает и подтверждает в каждом состоянии.
4. Критерий приёмки позволяет проверить, произошло ли обещанное и видит ли участник результат.«Пользователь нажимает кнопку» — фрагмент хореографии. Спецификация появляется, когда известно: кнопка доступна хранителю после подтверждения двух совладельцев; нажатие создаёт резерв на 20 минут; отказ банка снимает резерв; повторный запрос не создаёт второй заказ; все участники получают понятный статус.

Исходный размер 2304x1296
Исходный размер 1152x778

Крайний случай — рентген закона

Исходный размер 2304x1296

Happy path показывает, как институт хотел бы выглядеть. Сбой показывает, чем он является. Проверьте:⚫️ товар изменился между просмотром и оплатой;
⚫️ цена зависит от группы, а один участник вышел;
⚫️ два покупателя претендуют на единственный экземпляр;
⚫️ агент собрал корзину по устаревшим данным;
⚫️ платёж подтверждён, доставка невозможна;
⚫️ право передано, затем отменена транзакция;
⚫️ пользователь не может выполнить условие возврата;
⚫️ сеть исчезла после необратимого действия.У каждого случая должны быть обнаружение, объяснение, ответственность, следующий шаг и след в истории. Ошибка без владельца превращается в Пустоту; исключение, рассмотренное заранее, становится частью институциональной этики.

Исходный размер 2304x1296

Приоритет: что должно существовать

RICE, ICE, Kano, Impact/Effort и метод Вигерса помогают сравнивать функции, когда команда согласовала критерий ценности. Для учебного прототипа коммерческий reach почти всегда вымышлен, поэтому подставлять цифры ради научного выражения лица бессмысленно. Используйте фильтр из четырёх вопросов:1. Без функции системный закон остаётся видимым?
2. Функция создаёт проверяемый переход состояния?
3. Она раскрывает конфликт или лишь заполняет привычный экран?
4. Её можно убедительно прототипировать и испытать за срок модуля?

Исходный размер 2304x1296

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

Исходный размер 2304x1296
3.5. Сценарий как машина состояний — спецификация, приоритет, крайние случаи
Проект создан 02.08.2026
Глава:
20
21
22
23
24