4.4. Сценарии мобильного взаимодействия и ключевой путь

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

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

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

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

Вспомните формулу:

Job Story задаёт «зачем» и «откуда». Сценарий задаёт «как»: через какие шаги, экраны, решения и отклики проходит человек от ситуации к результату. Каждая хорошая Job Story порождает минимум один сценарий. Некоторые — два или три, если ситуация допускает разные траектории.

Среди всех сценариев есть один, который важнее остальных. Это ключевой путь — critical path, happy path, основной маршрут, ради которого приложение вообще существует.

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

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

Самый простой способ — пронумерованная цепочка шагов:1. Человек достаёт телефон (контекст из Job Story).
2. Открывает приложение / получает пуш / видит виджет.
3. Видит [что именно] на первом экране.
4. Делает [действие 1].
5. Приложение отвечает [отклик 1].
6. Делает [действие 2].
7. …
8. Достигает [результат].
9. Закрывает приложение / уходит / остаётся.Каждый шаг — пара: действие пользователя + ответ интерфейса. Если вы написали шаг, в котором пользователь что-то делает, а приложение молчит — это дыра. Если приложение что-то показывает, а пользователь не знает, зачем — тоже дыра.

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

Формат: FigJam, индивидуально → обсуждение. 16 минут.

Нулевой старт — только для режима B (4 минуты):Возьмите любую задачу, которую вы сами решаете телефоном. Напишите одну Job Story прямо сейчас:

Одно предложение. Не думайте — пишите. Этого достаточно, чтобы перейти к заданию.Задание (7 минут):Возьмите свою главную Job Story — из домашнего задания (режим A) или только что написанную (режим B). Разверните её в сценарий: пронумерованная цепочка шагов от ситуации до результата. Минимум 5 шагов, максимум 10.Для каждого шага запишите:

Под таблицей — одна строка: «Главное действие всего сценария — это шаг №__». Назовите тот шаг, ради которого существует всё остальное.Обсуждение (5 минут):Разбираю 2–3 сценария:● где главное действие названо точно,● где шагов слишком много (и как сократить),● где между шагами есть разрыв (пользователь не понимает, куда идти).Что это проверяет:Можете ли вы выстроить последовательность, а не просто перечислить экраны?

Среди всех моментов взаимодействия с приложением есть один, который определяет всё остальное. Это первый вход — момент, когда человек впервые открывает ваше приложение.

Первый вход — ситуация, в которой оказывается человек; онбординг, который вы придумаете потом, к ней не имеет отношения. И эта ситуация неприятна.Вот что он знает: почти ничего. Он скачал приложение (или ему прислали ссылку). Он нажал «открыть». Он видит экран. И прямо сейчас в его голове — одновременно три вопроса:● Что это? (понимание)● Что мне здесь делать? (действие)● Зачем я здесь? (мотивация)Если хотя бы на один из этих вопросов нет ответа в первые 5–8 секунд — человек закрывает приложение. Не потому что оно плохое. А потому что у него есть ещё 80 приложений и никаких обязательств перед вашим.

Ошибка 1. Стена регистрации. Человек ещё ничего не увидел — а от него уже требуют email, пароль, подтверждение, номер телефона. Он не знает, стоит ли ваше приложение его данных. Разрешите ему сначала посмотреть.Ошибка 2. Экскурсия из семи слайдов. «Добро пожаловать! Наше приложение делает то, это и вот это. Свайпните, чтобы узнать больше. Ещё свайпните. И ещё. А теперь — начнём!» Этот онбординг никто не читает. Пользователь свайпает до конца и забывает всё, что видел.Ошибка 3. Пустота без объяснения. Человек открыл приложение — а там ничего. Пустой список. Пустая карта. Пустая лента. Без единого намёка на то, что делать. Об этом мы поговорим подробнее через минуту.

● Одно действие. Не «вот всё, что мы умеем», а «сделай вот это одно — и ты поймёшь, зачем ты здесь». Duolingo не объясняет методику — он сразу предлагает перевести первое слово. Вы ещё ничего не знаете о приложении, но вы уже внутри опыта.● Ценность до регистрации. Покажите результат прежде, чем просить данные. Человек должен увидеть, что приложение ему полезно, до того как оно попросит создать аккаунт.● Прогрессивное раскрытие. Не всё сразу. Первый экран — одно действие. Второй — чуть больше. Третий — контекст расширяется. Как расширяющиеся круги на воде.

Пустое состояние (empty state) — экран, на котором ещё нет данных. Список контактов пуст. Корзина пуста. Лента событий пуста. История поездок пуста.

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

1. Начальное пустое состояние. Пользователь только что установил приложение. Данных нет, потому что он ещё ничего не сделал. Это момент максимальной уязвимости: человек не понимает, как будет выглядеть приложение «в рабочем состоянии», потому что ещё не видел его таким.Что делать: покажите, что здесь будет. Заполните пустоту приглашением к первому действию. Не абстрактным «Добавьте контент», а конкретным: «Сфотографируйте первое растение» или «Добавьте адрес дома, чтобы мы знали, откуда строить маршрут».2. Пустое состояние после очистки. Пользователь удалил все элементы, завершил все задачи, очистил корзину. Список стал пустым — но по его воле.Что делать: отметьте достижение. «Все задачи выполнены» — это не пустота, это результат. Дайте почувствовать завершённость, а не потерю.3. Пустое состояние из-за ошибки. Поиск не нашёл результатов. Фильтр слишком узкий. Сервер не ответил. Данные есть — но приложение не может их показать.Что делать: объясните, почему пусто, и предложите выход. «Ничего не найдено. Попробуйте другие фильтры» — минимум. «Ничего не найдено по запросу „кафе веган“. Вот что есть поблизости» — лучше.

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

Пользователь не идёт по вашему сценарию. Точнее — он идёт по нему ровно до тех пор, пока что-нибудь не пойдёт не так. А это происходит всегда.

● Нет интернета. Пользователь в метро, в подвале, в самолёте. Что показывает ваше приложение? Белый экран? Бесконечный спиннер? Или сообщение: «Вы офлайн. Вот что доступно без сети»?● Сервер не отвечает. Задержка, таймаут, ошибка 500. Пользователь не знает, что такое «500». Он знает, что «сломалось». Что вы ему скажете? «Ошибка сервера» — бесполезно. «Что-то пошло не так. Попробуйте через минуту» — уже лучше. «Мы сохранили ваш черновик. Попробуем отправить, когда появится связь» — уважение.● Пользователь ввёл что-то неправильно. Неверный формат, пустое поле, некорректный адрес. Когда вы сообщаете об ошибке — до того как он нажал «отправить», или после? Инлайн-валидация (подсветка поля в момент ввода) спасает десятки нервных клеток.

Отдельный и критически важный сценарий — возврат. Пользователь ушёл с экрана. Закрыл приложение. Свернул его. Отвлёкся. Прошло два часа — и вот он вернулся.Что он видит?● То, на чём остановился? (сохранение состояния)● Начало, как будто ничего не было? (потеря контекста)● Что-то изменившееся, потому что мир за это время двигался? (обновление)Это проектное решение, которое вы должны принять осознанно, а не оставить на милость технической реализации.

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

Формат: FigJam, работа в парах. 12 минут.Задание:Возьмите сценарий, который вы нарисовали в интерактиве 1. Передайте его партнёру. Партнёр пытается сломать ваш сценарий, вписывая сбои в каждый шаг:Для каждого шага вашего сценария партнёр записывает одну вещь, которая может пойти не так:

Обязательно включите хотя бы:🔴 одну потерю связи,🟡 одну ошибку пользователя,🟠 один незапланированный уход (человек закрыл приложение на полпути).Разбор (4 минуты):Смотрю на 2–3 самых интересных «поломки»: где сценарий рухнул полностью, а где устоял.Что это проверяет:Готов ли ваш сценарий к реальной жизни — или он работает только в идеальных условиях?

Крайний случай (edge case) — это ситуация, которая не должна произойти, но происходит. Пользователь с именем из одной буквы. Список из 10 000 элементов. Фотография размером 50 мегабайт. Человек, который открыл приложение в 3 часа ночи. Человек, который пользуется приложением каждый день уже полгода — и видел всё, что можно видеть.

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

● Минимум данных. Один контакт. Одна запись. Одно фото. Как выглядит экран, когда данных почти нет, но они уже есть?● Максимум данных. Тысяча записей. Годовой архив. Бесконечный скролл. Как приложение справляется с перегрузкой?● Длинный текст. Имя из 40 символов. Описание на три абзаца. Адрес с корпусом, строением и квартирой. Ваши карточки это выдержат?● Вернувшийся пользователь. Человек, который всё видел, всё знает, всё настроил. Что ему остаётся? Не заскучает ли он?● Нетипичный контекст. Приложение открыто в тёмной комнате (тёмный режим?). На ярком солнце (контрастность?). В движущемся транспорте (стабильность нажатий?). Одной рукой, потому что вторая занята.● Пользователь передумал. Начал заполнять форму — и решил не заполнять. Добавил товар в корзину — и хочет убрать. Подтвердил действие — и хочет отменить. Есть ли обратный путь?

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

Откройте любое руководство по user flow. Там всегда два участника: пользователь и интерфейс. Пользователь нажимает — интерфейс отвечает. Пользователь скроллит — интерфейс показывает. Диалог двух.Но это радикальное упрощение — полезная ложь, без которой трудно думать.Акторно-сетевая теория складывалась в работах Бруно Латура, Мишеля Каллона, Джона Ло и других исследователей науки и техники. Её провокация состоит в методической симметрии: объясняя действие, нельзя заранее оставить людям всю активность, а вещам — роль декораций. Дверной доводчик, бактерия, стандарт связи и юридический протокол меняют ход событий, поэтому сеть следует прослеживать по тому, как участники заставляют друг друга действовать. Термин актант, заимствованный из семиотики, помогает временно отложить вопрос о человеческом намерении и посмотреть на производимый эффект.Перенесите это на мобильный сценарий.Когда человек заказывает такси через приложение в 11 вечера на тёмной улице, в этом сценарии действуют не двое (пользователь и интерфейс), а целая сеть:● Сотовая сеть — актант: она может пропасть, и тогда сценарий рухнет. Она не «фон», она действует, потому что её исчезновение меняет всё.● Батарея — актант: 8% заряда превращают неспешный выбор в экстренный. Батарея диктует темп взаимодействия.● Освещение — актант: на тёмной улице экран слепит, контрастность критична, человек не видит мелкий текст. Темнота проектирует за вас.● Push-уведомление от другого приложения — актант: оно прерывает сценарий, уводит внимание, заставляет вернуться и вспоминать, на чём остановился.● Палец — актант: мокрый от дождя палец не попадает в кнопку. Холодный палец не регистрируется тачскрином. Палец — не нейтральный инструмент, он действует и отказывается действовать.● Тревога — актант: страх заставляет нажимать быстрее, ошибаться чаще, не дочитывать текст. Аффект — такой же участник сценария, как кнопка.Все эти сущности действуют. Они не декорации вокруг «главных героев». Они — полноправные актанты сценария, и если вы их не учитываете, ваш user flow описывает фантазию, а не реальность.

Здесь начинается авторская мутация ANT — анарх-акторная композиция. Классическая акторно-сетевая теория вовсе не требует центрального хаба; она как раз показывает, как центры собираются и удерживаются сетью переводов. Приставка «анарх-» добавляет другой акцент: ни один центр не получает остаточного права объявить себя окончательным источником порядка. Пользователь, интерфейс и платформа могут временно координировать сценарий, но не владеют им полностью. Сценарий происходит как пересборка полномочий, а не как безупречное исполнение линии из Figma.Что это значит для проектирования?Когда вы рисуете user flow как линию — вы полезно лжёте. Эта ложь необходима: без упрощения нельзя проектировать. Но помните, что за линией стоит сеть. И каждый ваш «сбой» (потеря связи, ошибка ввода, уход пользователя) — это не поломка линейного сценария. Это проявление актанта, которого вы не нарисовали на схеме, но который всегда был рядом.Сбои — не исключения. Они — нормальная работа сети. Проектировать error states и edge cases — значит уважать тех участников сценария, которых вы не видите на wireflow, но которые видят вас.Вывод для вашего сценария: нарисуйте flow как линию — рабочий инструмент. Но мысленно видьте за ней сеть. Спросите себя: какие актанты я не учёл? Что ещё действует в этом сценарии помимо пальца и экрана?Вопрос к проекту: какой не показанный на схеме актант способен изменить ключевой путь?Вмешательство: добавьте к wireflow одну внешнюю дорожку — сеть, батарею, геолокацию, тревогу, чужое уведомление — и событие, которым она вмешивается в сценарий.

Понятие цимцум (צמצום) связано с каббалой Ицхака Лурии XVI века и дошло до нас прежде всего в изложении его ученика Хаима Виталя. Бесконечность Эйн Соф как бы сокращает или скрывает свет, образуя пространство для конечного творения. Внутри еврейской мысли спорили, следует ли понимать это отступление буквально: многие позднейшие интерпретации говорят о сокрытии божественного присутствия с точки зрения творения, поскольку буквальное отсутствие Бога породило бы новые противоречия. Уже в самом понятии поэтому живёт напряжение — мир получает место благодаря жесту, который одновременно является присутствием и сокрытием.Экстраполируйте эту концепцию на первый вход в мобильное приложение.Ваше приложение знает всё, что оно умеет. У него есть каталог, фильтры, настройки, профиль, история, аналитика, уведомления, интеграции, тёмный режим, подписка. Оно наполнено функциями, как Эйн Соф наполнен светом. И вот приходит новый пользователь. Он ничего не знает. Он — пустое пространство.Если приложение не сжимается — оно заливает пользователя всем сразу: регистрация, туториал, запрос разрешений, главный экран со всеми фичами. Бесконечный свет, в котором нет места для человека. Пользователь слепнет и уходит.Хороший первый вход — цимцум интерфейса. Приложение сознательно отступает. Оно скрывает свою полноту. Оно показывает одно действие, одно обещание, одну возможность. Не потому что больше нечего показать — а потому что без этого отступления пользователю негде быть.Это отличается от минимализма. Минимализм — эстетическое решение: «мы любим чистоту». Цимцум — этическое решение: «мы отступаем, чтобы дать место другому». В терминах нашего курса это ближе всего к слабому дизайну — проектированию, которое не навязывает, а создаёт условия. Слабый дизайн знает свои границы. Цимцум — это слабый дизайн как космогонический принцип.Обратите внимание: цимцум — не отречение. Бог не уходит навсегда. Он отступает, чтобы потом свет мог вернуться, уже преобразованный, уже совместимый с конечным сосудом. Точно так же ваше приложение — после первого входа, после первого действия — начинает возвращать сложность, но постепенно, в том темпе, который может выдержать пользователь. Прогрессивное раскрытие — это возвращение света после цимцума.

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

Китаро Нисида, основатель Киотской школы, приходит в поздних работах к басё абсолютного ничто — «месту», которое не является ещё одной сущностью рядом с находящимися в нём вещами. Кэйдзи Ниситани продолжает эту линию в разговоре о поле пустоты, где преодолевается противопоставление бытия и нигилистического ничто. Формула дзеттай му (絶対無), «абсолютное ничто», не означает пустой контейнер или источник, который можно представить чёрным веществом. Она пытается мыслить такое основание явления, которое само не превращается в очередной предмет.Ничто — это не провал в бытии. Ничто — это поляна, на которой бытие разбивает лагерь.Перенос на empty states — рискованная проектная аналогия. Нисида не писал о пустых экранах, а цифровой контейнер с будущими данными едва ли равен басё абсолютного ничто. Линза нужна, чтобы вывести пустоту из статуса недоделанного интерфейса и спросить, какую возможность она организует.Стандартный UX-подход к пустому экрану: «тут пока ничего нет — покажем заглушку или приглашение». Это правильно на операциональном уровне. Но онтологически это мелко. Потому что пустой экран — это не временное неудобство перед наполнением. Это басё — место, которое конституирует возможность наполнения.Поясню. Полный экран (список из 50 записей, заполненная лента, карта с метками) существует не вопреки пустому экрану, а благодаря ему. Пустой экран — это не «минус», который станет «плюсом», когда появятся данные. Пустой экран — это условие, при котором данные вообще могут появиться. Без пустой страницы нет рукописи. Без тишины нет звука. Без дзеттай му нет сущего.Что это меняет в проектировании?Если вы думаете о пустом экране как о «заглушке до настоящего контента» — вы проектируете извинение: «простите, тут пока пусто, но скоро всё будет». Пользователь чувствует дефицит.Если вы думаете о пустом экране как о басё — вы проектируете место возникновения. Не «тут пока ничего нет», а «это место, в котором появится именно ваш контент — и без этого места он не мог бы существовать». Пустота экрана — не ожидание данных, а условие их рождения.

Практически это может выглядеть по-разному. Пустая карта дрейфа с одной точкой «Вы здесь» — и ощущение, что вся карта ждёт ваших маршрутов. Пустой журнал наблюдений с единственной строкой: «Первая запись — самая трудная» — и ощущение, что журнал уже существует, просто ещё не заполнен. Пустой плейлист с подписью: «Тишина. Пока» — и ощущение, что тишина тоже часть коллекции.Для исследовательских проектов это особенно остро. Если ваш интерфейс работает с вниманием, памятью, городским пространством — пустой экран может быть самой точной метафорой того, что вы исследуете. Пустота как предмет, а не как баг.Вывод для ваших empty states: проектируйте пустой экран как место, которое делает возможным всё, что на нём появится. Если ваша пустота ощущается как поляна — вы на правильном пути. Если она ощущается как ошибка 404 — копайте глубже.Вопрос к проекту: что впервые становится возможным именно потому, что экран пуст?Вмешательство: превратите один empty state в место первого действия: покажите будущую структуру, дайте осмысленный начальный жест и объясните, что возникнет после него.

Формат: FigJam, индивидуально → обсуждение. 15 минут.Задание (10 минут):Нарисуйте (схематично, не нужна красота) два экрана вашего приложения:Экран 1. Первый вход. Что видит человек, когда впервые открывает ваше приложение? Помните:● Никакой регистрации на этом экране.● Одно действие или одно обещание.● Человек должен понять за 5 секунд: что это, что делать, зачем.Экран 2. Пустое состояние. Выберите один экран вашего приложения, который может быть пустым (список, лента, карта, история). Нарисуйте его пустую версию. Помните:● Не «Нет данных», а приглашение.● Покажите, что здесь будет.● Предложите конкретное первое действие.Обсуждение (5 минут):Разбираю 2–3 работы:● где первый вход ясный и не перегруженный,● где пустое состояние работает как приглашение, а не как тупик,● где связь между первым входом и пустым экраном выстроена (первый вход ведёт к этому пустому экрану, и пользователь знает, что делать).Что это проверяет:Умеете ли вы проектировать не только «рабочий» экран, но и момент до него?

Сценарий существует как текст; но в какой-то момент текст должен стать визуальной схемой — wireflow.

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

Flowchart (блок-схема) отлично показывает логику: «если → то → иначе». Но он не показывает опыт. Пользователь не мыслит в терминах ромбов и стрелок. Он мыслит экранами, кнопками, текстом, откликом.Wireflow соединяет два мира: логику потока и визуальность экрана. Это позволяет увидеть:● Сколько экранов между входом и результатом (если больше 5–6 — вероятно, слишком много).● Где экран перегружен (слишком много стрелок «выходят» из него).● Где тупик (экран, из которого нет выхода кроме кнопки «назад»).● Где петля (пользователь ходит по кругу и не может выйти).

Для домашнего задания вам нужен минимальный wireflow:● 5–8 экранов.● Каждый экран — прямоугольник с грубой разметкой: заголовок, основной контент, главное действие (кнопка, свайп, ввод).● Стрелки между экранами — с подписью: что пользователь делает, чтобы перейти.● Хотя бы одна развилка (два возможных пути).● Хотя бы один тупик или ошибка (с пометкой: что здесь происходит).Это не финальный прототип. Это карта прохождения, которая покажет, есть ли у вашего приложения связная траектория или оно разваливается на отдельные экраны.

Формат: FigJam, индивидуально. 12 минут.Задание (10 минут):Нарисуйте ключевой путь вашего приложения как wireflow. Минимум 5 экранов, максимум 8.Для каждого экрана:● Прямоугольник с грубой разметкой (заголовок, контент, кнопка/действие).● Стрелка к следующему экрану с подписью действия.Обязательно включите:🟢 Первый экран (первый вход — что видит новый пользователь).🔵 Экран ключевого действия (перипетия — момент, ради которого приложение существует).🟡 Экран результата (узнавание — пользователь видит, что всё сработало).🔴 Одну сбойную ветку (стрелка в сторону: «что если здесь сломалось?»).Под wireflow — одна строка: «Весь путь от входа до результата — __ шагов».Разбор (2 минуты):Быстро смотрю на 2–3 доски: есть ли связность, видна ли перипетия, есть ли сбойная ветка.Что это проверяет:Можете ли вы нарисовать свой сценарий, а не только описать его словами?

Передайте модели текст ключевого пути и словарь состояний экранов. Попросите породить пятнадцать нарушений: потерю сети, двойное нажатие, свёрнутое приложение, отозванное разрешение, пустой ответ, очень длинные данные, возвращение через сутки. Каждый сбой должен быть описан как переход между состояниями, с ответом на вопросы: что сохранилось, что потеряно, откуда человек продолжит путь?Потом отберите пять мутаций по последствиям. «Что-то пошло не так» — слишком дешёвая ветка; полезный сбой меняет данные, темп, доверие или возможность завершить действие. Если модель предлагает техническое решение вроде очереди офлайн или идемпотентной отправки, проверьте его вместе с тем, кто отвечает за код: правдоподобие ещё не архитектура.Артефакт занятия: wireflow до и после машинной атаки; пять принятых мутаций; состояние данных для каждой; одна отвергнутая «универсальная ошибка» с объяснением. При отсутствии модели группа может провести тот же краш-тест вручную.

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

● Понимание разницы между коллекцией экранов и связным сценарием.● Умение выделить ключевой путь и назвать его перипетию.● Проработанный первый вход — без стены регистрации и без пустоты-тупика.● Хотя бы одну сбойную ветку: что делает приложение, когда что-то идёт не так.● Черновой wireflow на 5–8 экранов.

Сценарная схема + low-fi wireflow.Часть 1. Сценарная схема (текст)Опишите ключевой путь вашего приложения как пронумерованную последовательность шагов (формат из интерактива 1). Минимум 6 шагов.Для каждого шага укажите:

Обязательно включите:● Первый вход (как человек попадает в приложение).● Ключевое действие (перипетия).● Результат.● Минимум 2 сбойных ветки (ошибка, офлайн, возврат, пустое состояние — что угодно).Часть 2. Low-fi wireflow (визуальная схема)Нарисуйте ключевой путь как wireflow: 5–8 экранов, соединённых стрелками. Для каждого экрана — грубая разметка (заголовок, контент, действие). Хотя бы одна развилка. Хотя бы один тупик или ошибка.Добавьте к wireflow:🟢 Пометку «первый вход» на первом экране.🔵 Пометку «ключевое действие» на главном экране.🔴 Пометку «сбой» на ветке ошибки.⚪️ Пометку «empty state» на экране, который может быть пустым (с вашим вариантом дизайна пустого состояния).Часть 3. Мутация wireflowПриложите пять сбойных мутаций, возникших после машинного или ручного краш-теста. Для каждой укажите, что происходит с данными, куда попадает человек и может ли он безопасно продолжить путь.Формат сдачи: FigJam или Figma.

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