Карта экранов мобильного приложения: где расходится логика
Карта экранов мобильного приложения — это не перечень страниц, а контракт между продуктом, дизайном и разработкой: какие экраны есть, чем они открываются, какие состояния поддерживают и куда пользователь возвращается после каждого шага. Пока схема переходов живёт в макете и описывает только удачный путь, кажется, что структура навигации приложения согласована. Расхождение логики экранов проявляется позже и не там, где его ждут.
Первое типовое место — вложенные и модальные ветки: подтверждение оплаты, выбор адреса, ввод кода из письма. На макете это отдельные слои, а в карте экранов у них нет точки возврата, и после отмены пользователь попадает не туда, откуда начал. Второе — внешние входы: переход по ссылке из письма или уведомления, открытие приложения после разрыва соединения. Схема переходов, построенная от главного экрана, такие сценарии просто не описывает.
Третье — узкие места навигации внутри самих экранов. Экран-перекрёсток начинает знать про пять сценариев сразу и сам решает, куда идти дальше; после этого правка в одном потоке ломает соседний, а тестировщик описывает дефект как «навигация ведёт себя странно».
Цена расхождения считается не красотой схемы, а числом правок: один переход приходится чинить в трёх местах, а часть ошибок всплывает уже после выкладки. Разбираем, как это закрывается.
Что даёт описанная структура переходов до старта разработки
Согласованная структура переходов показывает до первой строки кода, сколько экранов реально нужно продукту. Лишние шаги — дублирующие формы, промежуточные подтверждения, экраны «на всякий случай» — отсекаются на схеме, где правка стоит минуты, а не переделки готового кода. По нашей практике список экранов после такой ревизии сокращается на 15–25%, и каждый убранный экран перестаёт тянуть за собой состояние, обработку ошибок и отдельный набор проверок.
Единая логика для платформ описывается один раз: каркас переходов задаётся как маршруты с точками входа и выхода, а отличия сводятся к навигационным паттернам из руководств платформ, например Material Design. Команды обеих платформ реализуют один сценарий, а не две постепенно расходящиеся версии продукта: изменение в структуре применяется сразу везде.
Когда маршрут и состояния экрана — пустой список, загрузка, ошибка сети, отсутствие прав — описаны заранее, оценка перестаёт зависеть от находок по ходу работы. Разработчик получает контракт экрана: что приходит на вход, что уходит дальше, какие ветки нужно покрыть. Скорость разработки растёт, а правки после первого выпуска сокращаются примерно на треть: несогласованные переходы выявляются до сборки.
Итог — предсказуемый график выпуска: число экранов и связей известно, оценка складывается из понятных единиц, а риск менять навигацию в середине работы почти исчезает. Структуру дешевле переписать на схеме, чем в собранном приложении.
Форматы описания структуры: таблица состояний, схема, прототип
Формат описания структуры определяет, что именно увидит команда: список экранов, связи между ними или сам сценарий в работе. Один продукт можно описать таблицей состояний экранов, схемой переходов или интерактивным прототипом — разница в том, какие ошибки каждый формат ловит, а какие пропускает.
Ограничения форматов связаны не с качеством, а с моментом применения. Таблица не показывает ритм интерфейса, схема не передаёт поведение при отказах, прототип не описывает редкие ветки и расходится с реализацией, если обновляют только его.
| Формат | Когда подходит | Ограничения |
|---|---|---|
| Таблица состояний экранов | Фиксация логики: роли, права, состояния загрузки и ошибок, условия переходов | Не читается целиком на согласовании; требует обновления после каждой правки |
| Схема переходов | Проверка целостности: нет тупиков, у каждого экрана есть выход и обратный путь | Не передаёт содержимое экранов и правила доступа |
| Интерактивный прототип | Проверка сценария с пользователями: понятность шагов, объём формы, порядок действий | Не покрывает аварийные ветки; быстро расходится с реализацией |
| Текстовое описание экранов | Передача задачи в разработку и поддержку: единый словарь названий и зон | Устаревает без привязки к таблице и схеме, допускает разные трактовки |
На практике форматы не заменяют друг друга: таблица состояний остаётся источником правды, схема переходов — для проверки целостности на согласовании, прототип — для проверки сценария. Расхождение между ними — первый признак, что структуру пора пересобирать.
Этапы проектирования структуры и переходов приложения
Работу начинаем с инвентаризации: собираем все экраны, модальные окна, состояния загрузки и ошибок, которые есть в приложении или заложены в макетах. Каждому узлу присваиваем идентификатор и тип — так схема остаётся читаемой, когда экранов становится больше сотни. Дальше описываем переходы и условия: что открывает экран, при каких событиях он закрывается, куда ведёт системная кнопка «назад» на каждой платформе.
- Аудит существующих экранов. Сверяем макеты, работающее приложение и аналитику: находим экраны-дубли, тупики без выхода, места, где пользователь теряет контекст. Фиксируем расхождения между платформами — часто один и тот же сценарий на разных системах устроен по-разному без причины.
- Сборка черновой структуры. Раскладываем экраны по веткам: вход и регистрация, основной сценарий, настройки, платежи, поддержка, служебные состояния. Проверяем, что у каждого действия есть предсказуемый путь возврата.
- Согласование схемы с продуктом. Проходим карту вместе с владельцем продукта и дизайном: где сократить шаги, какие ветки убрать в следующий релиз, что критично на старте. Спорные места решаем на схеме, а не в коде.
- Проверка переходов. Симулируем сценарии: прерывание оплаты, потеря связи, повторный вход, глубокие ссылки, возврат из фонового режима. Каждый такой путь должен приводить в понятное состояние, а не в пустой экран.
- Передача структуры в разработку. Отдаём карту с описанием экранов, параметрами навигации и приоритетами — по ней команда оценивает объём этапов и не трактует требования по-своему.
- Поддержание актуальности. Договориваемся, кто и когда обновляет схему, чтобы она не разошлась с продуктом после первых же правок.
Карта экранов живёт вместе с продуктом: при добавлении функции мы обновляем её до начала разработки. Опишите задачу — вернёмся с оценкой и планом работ.
Что передаём команде: артефакты, схемы и регламенты
Карта экранов — рабочий документ, а не иллюстрация для презентации. После завершения работ она остаётся у заказчика в виде набора артефактов, по которым новая команда продолжает разработку, не восстанавливая логику по коду. Ниже — то, что входит в передачу.
- Схема переходов: все экраны, ветки навигации, возвраты и тупиковые состояния, с пометкой, какие переходы блокируются до выполнения условия.
- Схемы состояний экранов: для каждого экрана — загрузка, пустой список, ошибка, частичные данные, отсутствие сети; что именно видит пользователь в каждом случае.
- Описание переходов и параметров: какие данные передаются между экранами, что обязательно, что происходит при их отсутствии или устаревании.
- Правила именования экранов: единый шаблон, по которому экран, событие и параметр называются одинаково в схеме, аналитике и коде — расхождений при сверке не возникает.
- Документация структуры приложения: иерархия разделов, общие блоки, повторно используемые состояния и их владельцы.
- Регламент обновления схемы: кто и на каком этапе правит карту, как изменение попадает в неё до начала разработки, а не после релиза.
- Матрица связей «экран — требование — проверка»: видно, какие пути покрыты автотестами, а какие остаются ручными.
Всё передаём в виде, который версионируется рядом с кодом: правки видны в истории, а не теряются в переписке.
Кейс: как структура переходов сократила переделки в приложении
До: навигация собиралась по ходу разработки
Приложение на 40 с лишним экранов проектировали от макетов: каждый экран рисовали отдельно, а переходы между ними додумывались уже в коде. К третьей итерации всплыли три разных варианта возврата из корзины, два дублирующих потока регистрации и модальное окно, из которого не было выхода на оформление заказа. К моменту первой сборки команда накопила больше 60 правок навигации — часть из них ломала уже протестированные сценарии.
Что изменили: карта экранов до первой строки кода
Собрали карту экранов: для каждого экрана — входы, выходы, состояния (пусто / загрузка / ошибка / нет прав), модальные ветки и правила возврата. Отдельно описали сквозные потоки — оформление заказа, восстановление доступа, оплата — с точками, где пользователь может уйти и вернуться. Прототип переходов собрали в Figma, чтобы состояние возврата проверялось кликом, а не чтением описания, и согласовали карту до старта разработки.
После: метрики
Правок навигации после старта разработки — 8 вместо 60. Переделали 3 экрана вместо 20: переходы были согласованы заранее, и разработчикам не пришлось пересобирать сценарии на ходу. Доля переходов с явно описанным состоянием возврата выросла с 45% до 100%, поэтому тестировщики проверяли сценарии по карте, а не догадывались о них.
Согласованность экранов держалась на одном документе: дизайнер, разработчик и тестировщик смотрели на один источник правды вместо трёх трактовок. Сроки выпуска приложения не сдвинулись — пятинедельный перенос, который прогнозировали после первой сборки, не потребовался.
Чем отличается структура переходов от интерактивного прототипа
Карта экранов — это схема из узлов и переходов: какой экран, откуда на него попадают, куда уходят и при каком условии. Она задаёт объём продукта: сколько экранов и состояний, что показываем при пустом списке или обрыве связи. Интерактивный прототип отвечает на другой вопрос — как сценарий ощущается в работе.
Разница в полноте. Прототип собирают по одному, «счастливому» пути: вход, главное действие, результат. Карта покрывает ветки — нет прав, офлайн, ошибка запроса, пустое состояние, подтверждение удаления. Поэтому прототип без карты теряет заметную долю состояний, и их находят уже на собранном приложении, где правка дороже.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Текстовая карта экранов | Фиксация объёма, оценка сроков, постановка задач разработке | Не передаёт визуальный ритм и иерархию |
| Интерактивный прототип | Проверка спорного сценария, показ заказчику | Покрывает один-два пути, остальное — белые пятна |
| Карта плюс прототип ключевых сценариев | Обычная разработка продукта | Нужны два прохода и синхронизация между ними |
Первична карта. Из неё выводят навигацию, сценарии проверок и оценку трудозатрат, а прототип — производная от согласованной структуры. Если начинать с картинок, структура вырастает из макетов и расползается: два похожих экрана живут по разным правилам.
Прототип идёт первым в одном случае: когда спор идёт о самой механике, а не о деталях, и гипотезу надо проверить на людях. Тогда собираем два-три сценария, а карту восстанавливаем после. В Figma карта и прототип живут в одном файле, но это разные артефакты с разной ценностью.
Сомнения по структуре: дубли экранов, состояния, переходы
Дубли экранов почти никогда не появляются из-за невнимательности — их порождают разные сценарии входа. Один и тот же список открывается из поиска, из избранного и из уведомления, и в карте это разные маршруты с разным состоянием фильтра. Решить заранее, что переиспользуется как компонент, а что живёт отдельным экраном со своим контекстом, дешевле, чем потом править расходящихся близнецов по отдельности.
Вторая точка напряжения — состояния экранов: пустой список, загрузка, ошибка сети, частично устаревшие данные. В схеме они описываются как ветки одного экрана, а обратные переходы ведут туда, откуда пользователь пришёл, — иначе на этапе выпуска навигацию приходится переделывать. Ниже — сомнения, которые чаще всего всплывают до старта работы над структурой.
У нас уже есть приложение. Карту придётся собирать с нуля?
Нет. Снимаем текущую структуру по факту: проходим экраны, фиксируем переходы и состояния, помечаем дубли. Дальше правим точечно — обычно это слияние повторяющихся экранов и единый контракт параметров навигации.
Кто отвечает за обратные переходы и системные жесты?
Навигация фиксируется в карте как правило, а не как пожелание: для каждого экрана указано, куда ведёт возврат и что происходит с сохранённым состоянием. Так же описываем поведение при прерывании сценария — звонок, сворачивание, разрыв соединения.
Что будет со структурой после релиза?
Карта остаётся рабочим документом: новый экран или ветка состояния сначала появляются в ней, потом в коде. Это удерживает навигацию от разрастания и позволяет увидеть дубль до того, как он попал в сборку.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы вернуться с оценкой и планом работ, нужны вводные: список экранов в любом виде — таблица, скриншоты, наброски, — описание ролей пользователей и доступ к текущему прототипу или репозиторию. Этого достаточно, чтобы разобрать текущее состояние и не переписывать заново то, что уже работает.
На выходе вы получаете:
- разбор текущего состояния: какие экраны дублируют друг друга и где переходы теряют контекст пользователя
- карту экранов с ролями и состояниями — пустой, загрузка, ошибка, отсутствие сети
- схему навигации с точками возврата и выходами из тупиковых веток
- перечень экранов под объединение и тех, которые действительно нужно добавить
- оценку и план работ по этапам: порядок, зависимости между экранами, точки проверки
- правила поддержки структуры приложения — как новый экран встраивается, не ломая навигацию
- состав команды и формат отчётности по ходу работ
Оценка строится на вашем объёме экранов и сценариев, а не на средних показателях: внешне похожие приложения расходятся по числу состояний в разы. Если часть вводных отсутствует, разберём продукт вместе с вашей командой и соберём карту экранов по вашим сценариям.
Опишите задачу — вернёмся с разбором, оценкой и планом работ.