«Кладбище экранов» — набор красивых макетов без логической ткани между ними. Сценарий превращает ситуацию из Job Story в конкретный путь — шаг, отклик, переход. Эта лекция объясняет, как строить ключевой путь и вспомогательные сценарии, почему пустота и отказ важны не меньше успешного исхода, и как проектировать движение, а не экраны.
На прошлом занятии вы собрали Job Stories и карту контекста. У вас есть ситуации, в которых человек встречается с вашим будущим приложением. Сегодня мы превращаем эти ситуации в сценарии: в последовательности действий, которые можно нарисовать, проверить и сломать. Потому что сценарий — это первая настоящая проверка того, существует ли ваш проект как опыт, а не как набор экранов.
Кладбище экранов
Вот что часто происходит в студенческих проектах. Человек придумал приложение, сел в Figma и начал рисовать экраны. Главный экран — красивый. Профиль — есть. Настройки — на всякий случай. Экран каталога, экран деталей, экран корзины. Потом экран онбординга — задним числом. Потом экран пуш-уведомления — потому что кто-то спросил. Потом ещё один экран, потому что вчера придумалась фича.
Результат — набор картинок, между которыми нет логической ткани. Каждый экран сам по себе может выглядеть хорошо. Но если спросить: «Что человек делает после этого экрана?» — пауза. «А как он сюда попал?» — ещё одна пауза. «А если у него нет интернета?» — тишина.
Это и есть кладбище экранов: собрание надгробий красивых интерфейсов, под которыми похоронен пользовательский опыт.
Сценарий заставляет вас думать не экранами, а переходами: что было до, что происходит сейчас, что будет после. Не «какой экран нарисовать», а «что делает человек, когда он здесь оказался, и куда он идёт дальше».
Что такое сценарий мобильного взаимодействия
Сценарий — это последовательность действий пользователя внутри вашего приложения, привязанная к конкретной ситуации из вашего исследования. Он отвечает на цепочку вопросов:
● Откуда человек пришёл? (контекст входа)
● Что он видит первым? (точка входа)
● Что он делает? (действия)
● Что приложение отвечает? (отклик)
● Куда он уходит? (точка выхода или продолжение)
Сценарий — это не карта всех возможностей приложения, а один конкретный путь одного конкретного человека в одной конкретной ситуации. У вашего приложения будет много сценариев. Но у каждого сценария — одна ситуация, одно намерение, одна траектория.
Связь с Job Stories
Вспомните формулу:
Когда [ситуация], я хочу [мотивация], чтобы [результат].
Job Story задаёт «зачем» и «откуда». Сценарий задаёт «как»: через какие шаги, экраны, решения и отклики проходит человек от ситуации к результату. Каждая хорошая Job Story порождает минимум один сценарий. Некоторые — два или три, если ситуация допускает разные траектории.
Ключевой путь
Среди всех сценариев есть один, который важнее остальных. Это ключевой путь — critical path, happy path, основной маршрут, ради которого приложение вообще существует.
Ключевой путь — это минимальная последовательность шагов, которая ведёт пользователя от входа к главному результату.
Если ваше приложение помогает заказать еду — ключевой путь ведёт от открытия до подтверждённого заказа. Если ваше приложение исследует городской дрейф — ключевой путь ведёт от запуска до момента, когда человек сделал первое отклонение от маршрута и зафиксировал наблюдение.
Зачем выделять ключевой путь
● Он доказывает гипотезу. Если ключевой путь работает — значит, приложение делает то, что обещает. Если не работает — не спасут ни красивые экраны, ни анимации, ни брендинг.
● Он задаёт приоритет. Всё, что на ключевом пути, — первый приоритет. Всё, что рядом, — второй. Всё, что далеко, — может подождать или вовсе не нужно.
● Он становится историей. На финальной презентации вы будете показывать не россыпь экранов, а прохождение сценария. Ключевой путь — это сюжет вашего проекта.
Как описать ключевой путь
Самый простой способ — пронумерованная цепочка шагов:
- Человек достаёт телефон (контекст из Job Story).
- Открывает приложение / получает пуш / видит виджет.
- Видит [что именно] на первом экране.
- Делает [действие 1].
- Приложение отвечает [отклик 1].
- Делает [действие 2].
- …
- Достигает [результат].
- Закрывает приложение / уходит / остаётся.
Каждый шаг — это пара: действие пользователя + ответ интерфейса. Если вы написали шаг, в котором пользователь что-то делает, а приложение молчит — это дыра. Если приложение что-то показывает, а пользователь не знает, зачем — тоже дыра.
Перипетия: поворотный момент сценария
В любом хорошем ключевом пути есть один шаг, который важнее остальных. Назовём его перипетией — термин из аристотелевской «Поэтики», означающий поворот событий, после которого всё меняется.
Начало пути — вход: пользователь присматривается, ещё не вовлечён. Перипетия — момент ключевого действия: отправил заказ, зафиксировал наблюдение, сделал выбор, от которого зависит результат. До перипетии можно было уйти. После — вы уже внутри. Конец — узнавание результата: заказ подтверждён, маршрут построен, запись сохранена.
Сценарий без перипетии — это инструкция: нажал, нажал, нажал, готово. Скука. Пользователь не чувствует, что прошёл через что-то. Даже в утилитарном приложении ищите поворот: решение, подтверждение, момент, после которого опыт меняется. Для исследовательских проектов перипетия может быть буквальной: момент, когда человек замечает нечто неожиданное, — и этот момент тоже нужно спроектировать, хотя предрешить его нельзя.
Когда будете описывать свой ключевой путь — отметьте перипетию. Если её нет — у вас пока не сценарий, а список действий.
Интерактив 1. Сценарий за 7 минут
Формат: FigJam, индивидуально → обсуждение. 12 минут.
Задание (7 минут):
Возьмите свою главную Job Story (из домашнего задания). Разверните её в сценарий: пронумерованная цепочка шагов от ситуации до результата. Минимум 5 шагов, максимум 10.
Для каждого шага запишите:
Под таблицей — одна строка: «Главное действие всего сценария — это шаг №__». Назовите тот шаг, ради которого существует всё остальное.
Обсуждение (5 минут):
Разбираю 2–3 сценария:
● где главное действие названо точно,
● где шагов слишком много (и как сократить),
● где между шагами есть разрыв (пользователь не понимает, куда идти).
Что это проверяет:
Можете ли вы выстроить последовательность, а не просто перечислить экраны?
Первый вход: порог
Среди всех моментов взаимодействия с приложением есть один, который определяет всё остальное. Это первый вход — момент, когда человек впервые открывает ваше приложение.
Первый вход — ситуация, в которой оказывается человек; онбординг, который вы придумаете потом, к ней не имеет отношения. И эта ситуация неприятна.
Вот что он знает: почти ничего. Он скачал приложение (или ему прислали ссылку). Он нажал «открыть». Он видит экран. И прямо сейчас в его голове — одновременно три вопроса:
● Что это? (понимание)
● Что мне здесь делать? (действие)
● Зачем я здесь? (мотивация)
Если хотя бы на один из этих вопросов нет ответа в первые 5–8 секунд — человек закрывает приложение. Не потому что оно плохое. А потому что у него есть ещё 80 приложений и никаких обязательств перед вашим.
Типичные ошибки первого входа
Ошибка 1. Стена регистрации. Человек ещё ничего не увидел — а от него уже требуют email, пароль, подтверждение, номер телефона. Он не знает, стоит ли ваше приложение его данных. Разрешите ему сначала посмотреть.
Ошибка 2. Экскурсия из семи слайдов. «Добро пожаловать! Наше приложение делает то, это и вот это. Свайпните, чтобы узнать больше. Ещё свайпните. И ещё. А теперь — начнём!» Этот онбординг никто не читает. Пользователь свайпает до конца и забывает всё, что видел.
Ошибка 3. Пустота без объяснения. Человек открыл приложение — а там ничего. Пустой список. Пустая карта. Пустая лента. Без единого намёка на то, что делать. Об этом мы поговорим подробнее через минуту.
Что работает на первом входе
● Одно действие. Не «вот всё, что мы умеем», а «сделай вот это одно — и ты поймёшь, зачем ты здесь». Duolingo не объясняет методику — он сразу предлагает перевести первое слово. Вы ещё ничего не знаете о приложении, но вы уже внутри опыта.
● Ценность до регистрации. Покажите результат прежде, чем просить данные. Человек должен увидеть, что приложение ему полезно, до того как оно попросит создать аккаунт.
● Прогрессивное раскрытие. Не всё сразу. Первый экран — одно действие. Второй — чуть больше. Третий — контекст расширяется. Как расширяющиеся круги на воде.
Пустые состояния: дизайн Ничто
Пустое состояние (empty state) — это экран, на котором ещё нет данных. Список контактов пуст. Корзина пуста. Лента событий пуста. История поездок пуста.
Это один из самых недооценённых моментов в проектировании мобильных приложений. Большинство дизайнеров проектируют «идеальный» экран — заполненный, живой, со всеми данными. А пустой экран оставляют «на потом». Или вовсе не проектируют.
Между тем пустой экран — это первое, что видит новый пользователь. У него ещё нет данных. У него нет истории. У него нет контента. Он смотрит в пустоту.
Три типа пустых состояний
1. Начальное пустое состояние. Пользователь только что установил приложение. Данных нет, потому что он ещё ничего не сделал. Это момент максимальной уязвимости: человек не понимает, как будет выглядеть приложение «в рабочем состоянии», потому что ещё не видел его таким.
Что делать: покажите, что здесь будет. Заполните пустоту приглашением к первому действию. Не абстрактным «Добавьте контент», а конкретным: «Сфотографируйте первое растение» или «Добавьте адрес дома, чтобы мы знали, откуда строить маршрут».
2. Пустое состояние после очистки. Пользователь удалил все элементы, завершил все задачи, очистил корзину. Список стал пустым — но по его воле.
Что делать: отметьте достижение. «Все задачи выполнены» — это не пустота, это результат. Дайте почувствовать завершённость, а не потерю.
3. Пустое состояние из-за ошибки. Поиск не нашёл результатов. Фильтр слишком узкий. Сервер не ответил. Данные есть — но приложение не может их показать.
Что делать: объясните, почему пусто, и предложите выход. «Ничего не найдено. Попробуйте другие фильтры» — минимум. «Ничего не найдено по запросу „кафе веган“. Вот что есть поблизости» — лучше.
Правило пустого экрана
Каждый пустой экран — это дизайнерская задача, а не техническая заглушка. Если в вашем прототипе есть хотя бы один экран, который может оказаться пустым, — вы обязаны спроектировать его пустое состояние. Иначе это не дизайн, а надежда на то, что у пользователя всегда будут данные.
Ошибки, сбои, возвраты
Пользователь не идёт по вашему сценарию. Точнее — он идёт по нему ровно до тех пор, пока что-нибудь не пойдёт не так. А это происходит всегда.
Error states: когда приложение не может
● Нет интернета. Пользователь в метро, в подвале, в самолёте. Что показывает ваше приложение? Белый экран? Бесконечный спиннер? Или сообщение: «Вы офлайн. Вот что доступно без сети»?
● Сервер не отвечает. Задержка, таймаут, ошибка 500. Пользователь не знает, что такое «500». Он знает, что «сломалось». Что вы ему скажете? «Ошибка сервера» — бесполезно и пугает. «Что-то пошло не так. Попробуйте через минуту» — уже лучше. «Мы сохранили ваш черновик. Попробуем отправить, когда появится связь» — уважение.
● Пользователь ввёл что-то неправильно. Неверный формат, пустое поле, некорректный адрес. Когда вы сообщаете об ошибке — до того как он нажал «отправить», или после? Инлайн-валидация (подсветка поля в момент ввода) спасает десятки нервных клеток.
Сценарий возврата
Отдельный и критически важный сценарий — возврат. Пользователь ушёл с экрана. Закрыл приложение. Свернул его. Отвлёкся. Прошло два часа — и вот он вернулся.
Что он видит?
● То, на чём остановился? (сохранение состояния)
● Начало, как будто ничего не было? (потеря контекста)
● Что-то изменившееся, потому что мир за это время двигался? (обновление)
Это проектное решение, которое вы должны принять осознанно, а не оставить на милость технической реализации.
Офлайн-сценарий
Мобильное приложение существует в мире, где связь нестабильна по определению. Тоннель метро, подвальный этаж, загородная дорога, перегруженная сеть на концерте. Вопрос не «что если нет интернета», а «что приложение делает, когда интернет пропадает на 40 секунд» — потому что это происходит десятки раз в день.
Минимальный набор решений:
● Кэширование — последние загруженные данные доступны офлайн.
● Очередь действий — если пользователь нажал «отправить», а связи нет, действие ставится в очередь и выполняется, когда связь вернётся.
● Индикация состояния — пользователь должен понимать, что он офлайн. Не красный баннер с восклицательным знаком, а спокойное: «Работаете без сети. Изменения синхронизируются позже».
Интерактив 2. Сломайте свой сценарий
Формат: FigJam, работа в парах. 12 минут.
Задание:
Возьмите сценарий, который вы нарисовали в интерактиве 1. Передайте его партнёру. Партнёр пытается сломать ваш сценарий, вписывая сбои в каждый шаг:
Для каждого шага вашего сценария партнёр записывает одну вещь, которая может пойти не так:
Обязательно включите хотя бы:
🔴 одну потерю связи,
🟡 одну ошибку пользователя,
🟠 один незапланированный уход (человек закрыл приложение на полпути).
Разбор (4 минуты):
Смотрю на 2–3 самых интересных «поломки»: где сценарий рухнул полностью, а где устоял.
Что это проверяет:
Готов ли ваш сценарий к реальной жизни — или он работает только в идеальных условиях?
Крайние случаи: дизайн на грани
Крайний случай (edge case) — это ситуация, которая не должна произойти, но происходит. Пользователь с именем из одной буквы. Список из 10 000 элементов. Фотография размером 50 мегабайт. Человек, который открыл приложение в 3 часа ночи. Человек, который пользуется приложением каждый день уже полгода — и видел всё, что можно видеть.
Крайние случаи — это не экзотика, а гигиена. Вы проектируете ключевой путь для типичной ситуации. Но мобильное приложение попадёт в руки людей, которые типичными не являются. И именно крайние случаи чаще всего обнажают слабости проекта.
Типичные крайние случаи для мобильного сервиса
● Минимум данных. Один контакт. Одна запись. Одно фото. Как выглядит экран, когда данных почти нет, но они уже есть?
● Максимум данных. Тысяча записей. Годовой архив. Бесконечный скролл. Как приложение справляется с перегрузкой?
● Длинный текст. Имя из 40 символов. Описание на три абзаца. Адрес с корпусом, строением и квартирой. Ваши карточки это выдержат?
● Вернувшийся пользователь. Человек, который всё видел, всё знает, всё настроил. Что ему остаётся? Не заскучает ли он?
● Нетипичный контекст. Приложение открыто в тёмной комнате (тёмный режим?). На ярком солнце (контрастность?). В движущемся транспорте (стабильность нажатий?). Одной рукой, потому что вторая занята.
● Пользователь передумал. Начал заполнять форму — и решил не заполнять. Добавил товар в корзину — и хочет убрать. Подтвердил действие — и хочет отменить. Есть ли обратный путь?
Протрём наши линзы
Теперь — отступление, которое, возможно, развернёт привычное понимание user flow. Три способа думать о сценарии из территорий, куда стандартные UX-руководства не заглядывают. Для проекта они не обязательны — но полезны тем, кому важно понимать почему, а не только как.
Линза 1. Сценарий как анарх-акторная сборка: не диалог, а сеть
Откройте любое руководство по user flow. Там всегда два участника: пользователь и интерфейс. Пользователь нажимает — интерфейс отвечает. Пользователь скроллит — интерфейс показывает. Диалог двух.
Но это ложь. Ну, точнее — радикальное упрощение.
Бруно Латур, социолог и философ, предложил акторно-сетевую теорию (ANT): любое действие — не результат единственного субъекта, а эффект сети, в которой участвуют люди, вещи, институты, технологии, условия среды. Латур называет каждого участника актантом — будь то человек, дверная ручка, бактерия или программный протокол. Актант — это всё, что действует или заставляет действовать других.
Перенесите это на мобильный сценарий.
Когда человек заказывает такси через приложение в 11 вечера на тёмной улице, в этом сценарии действуют не двое (пользователь и интерфейс), а целая сеть:
● Сотовая сеть — актант: она может пропасть, и тогда сценарий рухнет. Она не «фон», она действует, потому что её исчезновение меняет всё.
● Батарея — актант: 8% заряда превращают неспешный выбор в экстренный. Батарея диктует темп взаимодействия.
● Освещение — актант: на тёмной улице экран слепит, контрастность критична, человек не видит мелкий текст. Темнота проектирует за вас.
● Push-уведомление от другого приложения — актант: оно прерывает сценарий, уводит внимание, заставляет вернуться и вспоминать, на чём остановился.
● Палец — актант: мокрый от дождя палец не попадает в кнопку. Холодный палец не регистрируется тачскрином. Палец — не нейтральный инструмент, он действует и отказывается действовать.
● Тревога — актант: страх заставляет нажимать быстрее, ошибаться чаще, не дочитывать текст. Аффект — такой же участник сценария, как кнопка.
Все эти сущности действуют. Они не декорации вокруг «главных героев». Они — полноправные актанты сценария, и если вы их не учитываете, ваш user flow описывает фантазию, а не реальность.
Здесь важно ещё одно. В классической сетевой теории есть центральный узел — координатор, организатор, хаб. Но в модели анарх-акторной композиции — ацентричной системы, где структура возникает из постоянно меняющихся отношений равноправных агентов, — центра нет. Ни пользователь, ни интерфейс не контролируют сценарий полностью. Сценарий происходит — как событие, а не как исполнение плана.
Что это значит для проектирования?
Когда вы рисуете user flow как линию — вы лжёте. Однако эта ложь необходима: без упрощения нельзя проектировать. Но помните, что за линией стоит сеть. И каждый ваш «сбой» (потеря связи, ошибка ввода, уход пользователя) — это не поломка линейного сценария. Это проявление актанта, которого вы не нарисовали на схеме, но который всегда был рядом.
Сбои — не исключения. Они — нормальная работа сети. Проектировать error states и edge cases — значит уважать тех участников сценария, которых вы не видите на wireflow, но которые видят вас.
Вывод для вашего сценария: нарисуйте flow как линию — это рабочий инструмент. Но мысленно видьте за ней сеть. Спросите себя: какие актанты я не учёл? Что ещё действует в этом сценарии помимо пальца и экрана?
Линза 2. Цимцум: первый вход как божественное самосжатие
В лурианской каббале есть одно из самых странных и красивых космогонических понятий: цимцум (צמצום). Бог — бесконечный, вездесущий, заполняющий собою всё — сжимается. Он отступает внутрь себя, создавая пустое пространство, в котором станет возможным конечный мир. Без цимцума нет места для творения: бесконечный свет не оставляет зазора для чего-либо другого. Бог должен уменьшить себя, чтобы дать место не-Богу.
Экстраполируйте эту концепцию на первый вход в мобильное приложение.
Ваше приложение знает всё, что оно умеет. У него есть каталог, фильтры, настройки, профиль, история, аналитика, уведомления, интеграции, тёмный режим, подписка. Оно наполнено функциями, как Эйн Соф наполнен светом. И вот приходит новый пользователь. Он ничего не знает. Он — пустое пространство.
Если приложение не сжимается — оно заливает пользователя всем сразу: регистрация, туториал, запрос разрешений, главный экран со всеми фичами. Бесконечный свет, в котором нет места для человека. Пользователь слепнет и уходит.
Хороший первый вход — это цимцум интерфейса. Приложение сознательно отступает. Оно скрывает свою полноту. Оно показывает одно действие, одно обещание, одну возможность. Не потому что больше нечего показать — а потому что без этого отступления пользователю негде быть.
Это отличается от минимализма. Минимализм — эстетическое решение: «мы любим чистоту». Цимцум — этическое решение: «мы отступаем, чтобы дать место другому». В терминах нашего курса это ближе всего к слабому дизайну — проектированию, которое не навязывает, а создаёт условия. Слабый дизайн знает свои границы. Цимцум — это слабый дизайн как космогонический принцип.
Обратите внимание: цимцум — не отречение. Бог не уходит навсегда. Он отступает, чтобы потом свет мог вернуться, уже преобразованный, уже совместимый с конечным сосудом. Точно так же ваше приложение — после первого входа, после первого действия — начинает возвращать сложность, но постепенно, в том темпе, который может выдержать пользователь. Прогрессивное раскрытие — это возвращение света после цимцума.
Вывод для вашего первого входа: перестаньте думать о первом экране как о витрине («смотрите, что мы умеем!»). Думайте о нём как о жесте отступления. Что ваше приложение прячет — чтобы дать пространство человеку? Что оно не показывает — и в этом его сила?
Линза 3. Дзеттай му: пустой экран как абсолютное место
Философы Киотской школы — Нисида Китаро, Ниситани Кэйдзи — разработали понятие дзеттай му (絶対無): абсолютное Ничто. Это не nihil negativum, не «тут отсутствует какое-бы то ни было нечто». Это продуктивное Ничто — источник бытия, которое само не является ничем конкретным. У Ниситани дзеттай му — «абсолютное основание всего сущего, не сводимое к простой отрицательности или отсутствию». У Нисиды с этим связано понятие басё (場所) — «место»: абсолютное Ничто как место, в котором всё сущее может появиться.
Ничто — это не провал в бытии. Ничто — это поляна, на которой бытие разбивает лагерь.
Перенесите это на empty states.
Стандартный UX-подход к пустому экрану: «тут пока ничего нет — покажем заглушку или приглашение». Это правильно на операциональном уровне. Но онтологически это мелко. Потому что пустой экран — это не временное неудобство перед наполнением. Это басё — место, которое конституирует возможность наполнения.
Поясню. Полный экран (список из 50 записей, заполненная лента, карта с метками) существует не вопреки пустому экрану, а благодаря ему. Пустой экран — это не «минус», который станет «плюсом», когда появятся данные. Пустой экран — это условие, при котором данные вообще могут появиться. Без пустой страницы нет рукописи. Без тишины нет звука. Без дзеттай му нет сущего.
Что это меняет в проектировании?
Если вы думаете о пустом экране как о «заглушке до настоящего контента» — вы проектируете извинение: «простите, тут пока пусто, но скоро всё будет». Пользователь чувствует дефицит.
Если вы думаете о пустом экране как о басё — вы проектируете место возникновения. Не «тут пока ничего нет», а «это место, в котором появится именно ваш контент — и без этого места он не мог бы существовать». Пустота экрана — не ожидание данных, а условие их рождения.
Практически это может выглядеть по-разному. Пустая карта дрейфа с одной точкой «Вы здесь» — и ощущение, что вся карта ждёт ваших маршрутов. Пустой журнал наблюдений с единственной строкой: «Первая запись — самая трудная» — и ощущение, что журнал уже существует, просто ещё не заполнен. Пустой плейлист с подписью: «Тишина. Пока» — и ощущение, что тишина тоже часть коллекции.
Для исследовательских проектов это особенно остро. Если ваш интерфейс работает с вниманием, памятью, городским пространством — пустой экран может быть самой точной метафорой того, что вы исследуете. Пустота как предмет, а не как баг.
Вывод для ваших empty states: проектируйте пустой экран не как временное отсутствие, а как место. Место, которое делает возможным всё, что на нём появится. Если ваша пустота ощущается как поляна — вы на правильном пути. Если как ошибка 404 — копайте глубже.
Интерактив 3. Первый вход и пустой экран
Формат: FigJam, индивидуально → обсуждение. 15 минут.
Задание (10 минут):
Нарисуйте (схематично, не нужна красота) два экрана вашего приложения:
Экран 1. Первый вход. Что видит человек, когда впервые открывает ваше приложение? Помните:
● Никакой регистрации на этом экране.
● Одно действие или одно обещание.
● Человек должен понять за 5 секунд: что это, что делать, зачем.
Экран 2. Пустое состояние. Выберите один экран вашего приложения, который может быть пустым (список, лента, карта, история). Нарисуйте его пустую версию. Помните:
● Не «Нет данных», а приглашение.
● Покажите, что здесь будет.
● Предложите конкретное первое действие.
Обсуждение (5 минут):
Разбираю 2–3 работы:
● где первый вход ясный и не перегруженный,
● где пустое состояние работает как приглашение, а не как тупик,
● где связь между первым входом и пустым экраном выстроена (первый вход ведёт к этому пустому экрану, и пользователь знает, что делать).
Что это проверяет:
Умеете ли вы проектировать не только «рабочий» экран, но и момент до него?
От сценария к wireflow
Сценарий — это текст. Но в какой-то момент текст должен стать визуальной схемой: wireflow.
Wireflow — это user flow, в котором каждый узел — не абстрактный прямоугольник с надписью, а схематичный экран. Не hi-fi, не красивый — но достаточно конкретный, чтобы было видно: что на экране, куда нажимать, что происходит дальше.
Почему не просто flowchart
Flowchart (блок-схема) отлично показывает логику: «если → то → иначе». Но он не показывает опыт. Пользователь не мыслит в терминах ромбов и стрелок. Он мыслит экранами, кнопками, текстом, откликом.
Wireflow соединяет два мира: логику потока и визуальность экрана. Это позволяет увидеть:
● Сколько экранов между входом и результатом (если больше 5–6 — вероятно, слишком много).
● Где экран перегружен (слишком много стрелок «выходят» из него).
● Где тупик (экран, из которого нет выхода кроме кнопки «назад»).
● Где петля (пользователь ходит по кругу и не может выйти).
Минимальный wireflow
Для домашнего задания вам нужен минимальный wireflow:
● 5–8 экранов.
● Каждый экран — прямоугольник с грубой разметкой: заголовок, основной контент, главное действие (кнопка, свайп, ввод).
● Стрелки между экранами — с подписью: что пользователь делает, чтобы перейти.
● Хотя бы одна развилка (два возможных пути).
● Хотя бы один тупик или ошибка (с пометкой: что здесь происходит).
Это не финальный прототип. Это карта прохождения, которая покажет, есть ли у вашего приложения связная траектория или оно разваливается на отдельные экраны.
Интерактив 4. Ключевой путь на доске
Формат: FigJam, индивидуально. 12 минут.
Задание (10 минут):
Нарисуйте ключевой путь вашего приложения как wireflow. Минимум 5 экранов, максимум 8.
Для каждого экрана:
● Прямоугольник с грубой разметкой (заголовок, контент, кнопка/действие).
● Стрелка к следующему экрану с подписью действия.
Обязательно включите:
🟢 Первый экран (первый вход — что видит новый пользователь).
🔵 Экран ключевого действия (перипетия — момент, ради которого приложение существует).
🟡 Экран результата (узнавание — пользователь видит, что всё сработало).
🔴 Одну сбойную ветку (стрелка в сторону: «что если здесь сломалось?»).
Под wireflow — одна строка: «Весь путь от входа до результата — __ шагов».
Разбор (2 минуты):
Быстро смотрю на 2–3 доски: есть ли связность, видна ли перипетия, есть ли сбойная ветка.
Что это проверяет:
Можете ли вы нарисовать свой сценарий, а не только описать его словами?
Как сценарий доказывает необходимость приложения
На первом занятии вы отвечали на вопрос, почему это должно быть приложением. На втором — формулировали гипотезу. На третьем — собирали ситуации. Сегодня сценарий замыкает круг.
Хороший сценарий — это доказательство того, что ваше приложение нужно. Если вы можете провести человека от ситуации к результату через связную цепочку шагов — значит, ваш проект существует как опыт, а не как декларация. Если не можете — значит, проект ещё не собран.
И вот ещё одна вещь, которую стоит запомнить: ваш сценарий — это будущая презентация.
На финальном показе проекта вы не будете листать экраны один за другим, как слайды в PowerPoint. Вы будете рассказывать историю прохождения: вот человек, вот ситуация, вот он открывает приложение, вот что он видит, вот что делает, вот что получает. Сценарий, который вы рисуете сегодня, — это каркас этой истории.
Что вы должны вынести из этой лекции
● Понимание разницы между коллекцией экранов и связным сценарием.
● Умение выделить ключевой путь и назвать его перипетию.
● Проработанный первый вход — без стены регистрации и без пустоты-тупика.
● Хотя бы одну сбойную ветку: что делает приложение, когда что-то идёт не так.
● Черновой wireflow на 5–8 экранов.
Домашнее задание
Сценарная схема + low-fi wireflow
Часть 1. Сценарная схема (текст)
Опишите ключевой путь вашего приложения как пронумерованную последовательность шагов (формат из интерактива 1). Минимум 6 шагов.
Для каждого шага укажите:
Обязательно включите:
● Первый вход (как человек попадает в приложение).
● Ключевое действие (перипетия).
● Результат.
● Минимум 2 сбойных ветки (ошибка, офлайн, возврат, пустое состояние — что угодно).
Часть 2. Low-fi wireflow (визуальная схема)
Нарисуйте ключевой путь как wireflow: 5–8 экранов, соединённых стрелками. Для каждого экрана — грубая разметка (заголовок, контент, действие). Хотя бы одна развилка. Хотя бы один тупик или ошибка.
Добавьте к wireflow:
🟢 Пометку «первый вход» на первом экране.
🔵 Пометку «ключевое действие» на главном экране.
🔴 Пометку «сбой» на ветке ошибки.
⚪️ Пометку «empty state» на экране, который может быть пустым (с вашим вариантом дизайна пустого состояния).
Формат сдачи: FigJam или Figma.
Итоговая формула
Сценарий доказывает, что ваш интерфейс живёт в чьей-то повседневности.
Если вы не можете провести одного человека через один путь от ситуации к результату — у вас пока нет проекта. Есть экраны, есть гипотеза, есть Job Stories. Но между ними — пустота. Сценарий заполняет эту пустоту связной тканью: шагами, откликами, поворотами, ошибками, возвратами. Он делает ваше приложение проходимым — как делает проходимым город не карта, а маршрут по нему.
На следующем занятии мы возьмём ваши руки и поговорим о мобильных аффордансах: палец, жест, досягаемость, тактильный отклик — всё то, что делает сценарий телесным.