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.Для каждого шага запишите: