Проектирование навигации мобильного приложения: где ломается структура
Навигация ломается не в момент проектирования, а когда в приложение добавляют пятый-шестой раздел. Новый блок удобнее прицепить к уже существующему экрану, и структура экранов приложения растёт вглубь: до нужного раздела пользователь идёт через профиль, вложенный список и ещё один уровень. Глубина переходов переходит порог в три шага — и часть людей до цели просто не доходит. На тестах по одному сценарию это не видно: каждый путь по отдельности выглядит логичным.
В аналитике поломка проявляется как рост доли брошенных сценариев на промежуточных экранах: возвраты назад, повторные открытия того же пункта, уход после второго перехода. Одновременно растёт поток однотипных обращений в поддержку — «где найти», «почему не открывается». Разбор каждого такого обращения забирает время команды, которое не идёт ни на новые функции, ни на ускорение текущих. Показатель, по которому это отслеживают, — доля доведённых до конца целевых сценариев от начатых, а не число установок.
Запутанная навигация почти всегда следствие отсутствия карты экранов: связи между уровнями держат в голове, а при добавлении раздела проверяют только сам раздел, не весь маршрут целиком. Разбираем, как это закрывается — от инвентаризации существующих путей до правил, по которым новый экран встаёт в структуру, не увеличивая глубину переходов.
Что даёт продуманная структура экранов и переходов
Перестройку навигации мы измеряем двумя величинами: сколько шагов экономит пользователь и сколько времени экономит команда на каждой следующей доработке. Перед правками фиксируем базовые значения — путь до частого действия, число повторов одного экрана в разных ветках, глубину вложенности, — и после сверяем с ними результат.
Сокращение пути пользователя здесь главный ориентир: повтор заказа, корзина, поиск и настройки профиля укладываются в два-три перехода вместо пяти-шести. Дубли путей убираются — вместо трёх копий одного экрана остаётся один маршрут с параметрами, и правка расходится по всем веткам. Понятность интерфейса держится на единой логике возврата и предсказуемом поведении кнопки «назад».
Скорость выпуска новых разделов
Когда маршруты описаны декларативно, а экраны собраны из переиспользуемых шаблонов, новый раздел перестаёт быть отдельным проектом: команда подключает готовые блоки и тратит время на бизнес-логику, а не на верстку. Это сокращает выпуск раздела с недель до дней, а изменение затрагивает один шаблон вместо пяти его копий.
Доля брошенных сценариев
Длинный путь и непонятный возврат — основная причина, по которой пользователь бросает сценарий на середине; сокращение шагов и явные точки выхода снимают часть обрывов без новых функций. После перестройки доля брошенных сценариев на ключевых действиях падает заметнее, чем от косметических правок: видно, на каком шаге люди останавливались раньше и куда вернулись после.
Сравнение моделей навигации: вкладки, стек и боковое меню
Навигация — это контракт переходов: что доступно с любого места, как сохраняется состояние при возврате и какова глубина пути к цели. Один шаблон редко закрывает и быстрые повторяющиеся действия, и длинные линейные процессы — отсюда перегруженные меню и потерянные шаги. Опираемся на опубликованные руководства по проектированию мобильных интерфейсов, в частности Human Interface Guidelines.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Нижние вкладки | 3–5 равнозначных разделов, доступных с любого экрана | Шестая позиция теряет читаемость, на планшетах — полоса пустоты |
| Линейный стек | Последовательные шаги: оформление, регистрация, анкета | Возврат в середину без сохранения состояния теряет введённое |
| Боковая панель | Редкие разделы: настройки, справка, архив | Скрытый вход плохо обнаруживается, не годится как основной |
| Смешанная модель | Ядро из вкладок и линейные сценарии внутри разделов | Нужны явные правила сброса стека, иначе состояния расходятся |
Вкладки для частых сценариев
Нижние вкладки держат 3–5 точек входа и сохраняют раздел при переключении: пользователь возвращается туда, где остановился, а каждая вкладка ведёт собственный стек. Ограничение шаблона — плоская структура: всё, что не влезает в пять позиций, уходит во вложенность и перестаёт находиться.
Стек для последовательных шагов
Линейный сценарий — это стек экранов с одним обратным путём и явной точкой выхода. Черновик и позицию в процессе сохраняем в состоянии, иначе возврат в середину теряет введённое, и пользователь бросает оформление. Глубину стека ограничиваем: длинный путь без промежуточных ориентиров сбивает и усложняет восстановление после сворачивания приложения.
Порядок работ: от разбора сценариев до передачи команде
Навигация — это не картинка со стрелками, а спецификация: какие экраны есть, чем они связаны, что делает системная кнопка «назад» и как восстанавливается состояние после сворачивания приложения. Без такого артефакта каждый разработчик трактует переходы по-своему, а правки на этапе сборки стоят дороже всего.
Разбор сценариев и метрик
Начинаем не с макетов, а с данных: воронка в аналитике, записи сессий, обращения в поддержку. Из них собираем частотные пути к цели и отдельно — места, где люди разворачиваются и уходят.
- Собираем карту сценариев — один путь на задачу пользователя, с точками входа из уведомлений и глубоких ссылок.
- Фиксируем метрики пути: сколько экранов до цели, доля возвратов назад, отказы на формах.
- Строим прототип переходов — граф экранов с состояниями: пустой список, загрузка, ошибка.
Согласование карты экранов
Прототип проверяем на людях, а структуру описываем только после того, как тупики убраны.
- Проверяем на пользователях: 5–7 человек решают типовые задачи, считаем время до цели и число ошибок.
- Описываем структуру: таблица экранов, вложенность, правила системной кнопки «назад», восстановление состояния.
- Согласуем карту экранов с командой и заказчиком — что входит в ближайший релиз, а что откладываем.
- Передаём в разработку: граф переходов как спецификация, тесты на ключевые сценарии, ревью навигации в каждом спринте.
Что передаём на руки: карты экранов, схемы и регламенты
Передача документации — не финальная презентация, а рабочий комплект, по которому ваша команда развивает навигацию без нас. Отдаём всё в редактируемом виде: макеты и схемы — в Figma, правила — текстом рядом с кодом, чтобы описание структуры и сами экраны менялись одним изменением.
- Карта экранов — перечень с идентификаторами, состояниями (основное, пустое, ошибка) и точками входа в приложение.
- Схема переходов — граф связей между экранами: куда ведёт системная кнопка «назад», какие переходы взаимозаменяемы.
- Правила именования разделов — словарь терминов и шаблон идентификаторов, чтобы экран находился по имени, а не по переписке.
- Регламент изменений — кто согласует правку структуры, в какой момент она попадает в сборку и как откатывается неудачное решение.
- Журнал решений — почему выбран именно этот переход и какие альтернативы отклонены.
- Чек-лист проверки навигации — сценарии входа и поведение структуры на разных размерах экрана.
Регламент развития структуры
Новый экран редко появляется в вакууме: он либо расширяет существующую ветку, либо ломает её. Правило простое — сначала фиксируем точку входа и глубину, потом рисуем экран; правка, затрагивающая больше двух переходов, обновляет схему отдельным изменением с коротким описанием.
Так структура остаётся читаемой после десятков итераций, и новый разработчик в команде заказчика понимает логику переходов без устных пояснений.
Кейс: перестроили структуру сервиса и убрали дубли путей
К нам пришёл сервис доставки продуктов FreshMarket с приложением, которое несколько лет обрастало разделами: каждый новый сценарий добавлял экран, а не переиспользовал существующий. Навигация перестала быть предсказуемой — пользователь попадал к одному результату разными путями, и команда не могла однозначно назвать основной.
Мы прошли по данным о переходах и собрали карту фактических маршрутов вместо задуманных. До оформления заказа пользователь делал семь шагов вместо четырёх возможных, а на ключевом экране сходились шесть разных точек входа.
| Показатель | До | После |
|---|---|---|
| Шаги до ключевого действия | 7 | 4 |
| Дублирующие разделы | 14 | 6 |
| Брошенные сценарии | 38% | 21% |
| Завершённые действия за сессию | 1,2 | 1,9 |
Какие риски сняли
Пути свели к одному входу на сценарий, поэтому логика перестала расходиться между дублями, а правка в одном месте больше не требует синхронной правки в трёх. Глубину вложенности ограничили тремя уровнями: новый раздел появляется только под уже существующий сценарий, а не рядом с ним.
Структуру описали декларативно, поэтому перестройка разделов проверяется на карте маршрутов до релиза, а не после жалоб. Ещё через два релиза доля завершённых действий не откатилась — удержалась, когда добавили второй способ оплаты.
Что делать, если структура уже сложилась и менять её дорого
Прежде чем что-то менять, стоит замерить, где именно рвётся путь до целевого действия. Провал в одной-двух ветках не требует полной переработки: смотрите долю возвратов со второго и третьего уровня, среднее число шагов до ключевого экрана и то, как часто пользователи открывают поиск вместо разделов.
Риски смены структуры лежат не в новой раскладке, а в маршрутах, которые уже разошлись по свету: сохранённые ссылки, уведомления со старыми адресами, внешние переходы из поиска. Каждый такой маршрут на переходный период остаётся рабочим как алиас на новый экран, иначе просадка по входам и сессиям перекроет весь выигрыш от перестройки.
Ведём переходный период группами: одна ветка, отдельный слой совместимости, свои метрики до и после, отключение без выпуска новой сборки. Продолжаем или откатываем по доле дошедших до цели, числу шагов, отказам и стабильности сессий — а не по ощущению «стало современнее».
Технические вопросы, которые задают перед стартом
Перед стартом сомнения обычно одни и те же: где кончается проблема конкретного экрана и начинается изъян структуры, нужно ли переписывать приложение целиком, как потом жить со старыми ссылками. Ниже — ответы на пять вопросов, которые чаще всего определяют объём работ.
Как понять, что дело в структуре, а не в отдельном экране?
Смотрим пути пользователей: доля возвратов на предыдущий шаг, глубина вложенности, точки выхода и повторные заходы в тот же раздел. Если сбои повторяются на разных экранах одного сценария — это диагностика навигации, а не вёрстки. Локальный дефект живёт на одном экране, структурный — на всём маршруте.
Можно ли обойтись без переписывания приложения?
В большинстве случаев да. Меняем граф переходов, а не содержимое экранов: добавляем промежуточные узлы, часть сценариев переводим на вкладки, логику и данные не трогаем. Переписывание оправдано, только когда структура срослась с логикой экранов.
Как проверяете навигацию до выпуска?
Собираем кликабельный прототип маршрутов и прогоняем сценарии целиком, с возвратами и прерываниями. Затем — проверки переходов и восстановления состояния экрана после сворачивания, дальше закрытая раздача. Проверка до выпуска ловит тупики и лишние шаги до релиза.
Что будет со старыми переходами и ссылками?
Не ломаем. Прямые ссылки из писем, уведомлений и QR ведём через слой совместимости на новые маршруты, неиспользуемые постепенно выводим из оборота. Пользователь по ссылке годовой давности попадает на нужный экран.
Как поддерживать структуру дальше и насколько это трудоёмко?
Ведём карту маршрутов и правила добавления экранов: куда крепится новый раздел, какие переходы он обязан поддержать, где дублировать существующие. Тогда объём доработок предсказуем, а поддержка структуры становится регламентом, а не разовой правкой.
Обсудим задачу и вернёмся с оценкой и планом работ
Чтобы вернуться с планом работ, а не с общими словами, нам достаточно стартового набора материалов. Чем конкретнее вход, тем точнее сроки этапов и тем меньше правок на этапе проектирования навигации мобильного приложения.
- Цель приложения и ключевое действие пользователя: оформить заказ, оставить заявку, повторить покупку.
- Роли и сценарии: как разные группы попадают в приложение, что делают первым делом, куда возвращаются.
- Что есть сейчас: макеты, прототип, дерево экранов в любой форме — подойдёт даже набросок от руки.
- Где теряются пользователи: отчёты аналитики, обращения в поддержку, записи тестов с реальными людьми.
- Ограничения: платформы, действующая дизайн-система, обязательные интеграции и внешние сервисы.
- Доступы: тестовый контур и учётные записи, если часть навигации уже реализована в коде.
- Внешние сроки: запуск, кампания продвижения, сезон — под них выстраиваем график этапов.
На разборе показываем схему переходов верхнего уровня и называем сроки каждого этапа — от инвентаризации экранов до проверки прототипа на пользователях. Состав команды озвучиваем сразу: кто отвечает за проектирование, кто за техническую реализуемость переходов, кто ведёт проверку. Опишите задачу в удобной форме — вернёмся с оценкой и планом работ.