Навигация в мобильном приложении: таб-бар, бургер-меню или жесты

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

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

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

Зачем навигации отдельное решение

На десктопе навигация может позволить себе многое: горизонтальное меню, боковую колонку, футер со списком разделов. На телефоне у неё есть лишь полоска экрана, которую одновременно хочет занять контент. Поэтому мобильная навигация — всегда компромисс между видимостью разделов и местом для содержимого.

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

Навигацию трудно поменять после релиза. Пользователи привыкают к расположению разделов, а аналитика, маркетинговые глубокие ссылки и пуш-уведомления завязываются на конкретные экраны. Поэтому структура стоит того, чтобы проверить её отдельно от визуального дизайна.

Какие паттерны навигации бывают?

Большинство мобильных приложений собраны из нескольких базовых паттернов. Обычно их комбинируют: таб-бар для верхнего уровня, стек экранов внутри каждого раздела, модальные окна для коротких задач.

• Таб-бар (нижняя навигационная панель). Три–пять разделов верхнего уровня с иконками и подписями внизу экрана. Разделы всегда видны, переключение — одно касание, легко дотянуться большим пальцем.
• Бургер-меню (навигационный ящик). Список разделов скрыт за иконкой и выезжает сбоку. Экономит место и вмещает много пунктов, но разделы не видны, пока меню закрыто.
• Вкладки вверху. Переключатель между представлениями одного раздела: «Все», «Непрочитанные», «Архив». Подходит для параллельных списков одного типа, а не для верхнего уровня всего приложения.
• Стек и иерархия. Переход вглубь — от списка к карточке, от карточки к деталям — с кнопкой «Назад» в заголовке. Работает внутри любого раздела.
• Хаб (главный экран-плитка). Стартовый экран с крупными входами в разделы. Хорош для приложений, где задачи редко пересекаются: банк в киоске, корпоративный портал.
• Жесты. Свайп назад, смахивание карточки, долгое нажатие. Ускоряют опытных пользователей, но невидимы для новичков.

Скрытая навигация проигрывает видимой по обнаруживаемости: исследования Nielsen Norman Group показали, что пользователи заметно реже заходят в разделы, спрятанные за бургером, и дольше выполняют задачи. Это не запрет на бургер, а аргумент держать на виду самое важное.

Как выбрать паттерн под своё приложение?

Выбор начинается не с паттерна, а с инвентаризации: какие задачи человек решает в приложении, как часто и в каком порядке. Выпишите все разделы, отметьте частоту использования по аналитике или интервью и только потом раскладывайте их по уровням.

• 3–5 частых равноправных разделов → таб-бар. Типичный случай для магазина, соцсети, банка, сервиса доставки.
• Больше пяти разделов, из них 3–4 частых → таб-бар для частых + вкладка «Ещё» или профиль со списком остального.
• Много равноправных разделов, которыми пользуются редко → навигационный ящик, лучше в сочетании с поиском.
• Один главный сценарий (камера, плеер, карта) → без постоянной панели: контент на весь экран, второстепенное — в настройках.
• Линейный процесс (оформление заказа, онбординг, заявка) → пошаговый стек без глобальной навигации, чтобы человек не выпал из сценария.
• Планшет и складные экраны → боковая навигационная колонка (rail) или постоянная боковая панель вместо нижнего таб-бара.

Порядок вкладок тоже важен. Самый частый сценарий ставят первым, профиль и настройки — последними. Центральное место иногда занимают главным действием, например «Создать» в соцсети, но только если это действие действительно частое — иначе кнопка в центре становится декорацией.

Подписи у иконок обязательны. Иконки «дом», «поиск» и «профиль» узнают почти все, а всё остальное без текста превращается в загадку. Короткая подпись в одно слово почти не занимает места и снимает вопрос «что за этой иконкой».

Чем отличаются iOS и Android?

Структура разделов может быть общей для обеих платформ, а вот поведение навигации пользователи ожидают «родным». Сравним ключевые различия по гайдлайнам Apple Human Interface Guidelines и Material Design 3.

• Нижняя панель. iOS — таб-бар, обычно до пяти вкладок, при большем числе — вкладка «Ещё». Android — navigation bar на три–пять пунктов, для широких экранов — navigation rail и drawer.
• Возврат назад. iOS — кнопка в заголовке и свайп от левого края. Android — системный жест или кнопка «Назад», которые приложение обязано корректно обрабатывать, включая предиктивную анимацию возврата в новых версиях системы.
• Повторное нажатие на активную вкладку. На обеих платформах пользователи ожидают возврата к началу раздела или прокрутки вверх.
• Сохранение состояния. Переключение между вкладками не должно сбрасывать прокрутку и открытый экран внутри раздела.
• Главное действие. В Android принят плавающий кнопочный элемент (FAB) для основного действия экрана, в iOS чаще используют кнопку в заголовке или в самом таб-баре.

Кроссплатформенная разработка не отменяет этих различий: общий код навигации на Flutter или React Native нужно настроить так, чтобы системный «Назад» на Android и свайп на iOS вели себя предсказуемо для каждой платформы.

Зона большого пальца и размеры касаний

Большинство людей пользуются телефоном одной рукой хотя бы часть времени, и в этом режиме комфортно достижима нижняя и центральная часть экрана. Верхние углы на больших смартфонах приходится тянуть или перехватывать телефон. Это главный практический аргумент в пользу нижней навигации и против важных кнопок в верхнем левом углу.

Размеры целей касания задают платформы и стандарты доступности:

• Apple рекомендует цели касания не меньше 44×44 pt;
• Material Design — не меньше 48×48 dp с отступами между целями;
• WCAG 2.2, критерий 2.5.8, задаёт абсолютный минимум 24×24 CSS-пикселя для веба.

Иконка при этом может быть меньше: увеличивается не картинка, а кликабельная область вокруг неё. Активная вкладка должна отличаться не только цветом — добавьте заливку индикатора, начертание подписи или форму иконки. Контраст иконок и подписей с фоном панели проверяйте так же, как текст; подробно об этом — в разборе контраста и фокуса по WCAG 2.2.

Жесты и кнопка «Назад»

Жесты экономят место и ускоряют опытных пользователей, но у них нет видимого признака. Человек не узнает о свайпе, пока его не покажут или он не наткнётся на него случайно. Поэтому жест должен дублировать видимый элемент, а не заменять его.

• Не конфликтуйте с системой. Свайпы от краёв экрана заняты системными жестами iOS и Android; собственный жест у края приведёт к случайным срабатываниям.
• Оставляйте видимую альтернативу. Смахивание для удаления — плюс пункт в меню действий; свайп назад — плюс кнопка в заголовке.
• Подтверждайте разрушительные действия. Или дайте отменить их: «Письмо удалено. Отменить».
• Проверяйте с экранным диктором. VoiceOver и TalkBack не выполняют кастомные жесты — у каждого действия должен быть доступный аналог.

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

Как проверить навигацию до релиза?

Навигацию можно проверить задолго до готового интерфейса — и это дешевле всего.

• Шаг 1. Карточная сортировка. Участники группируют пункты так, как понимают их сами. Показывает, какие названия и группы разделов естественны для аудитории.
• Шаг 2. Дерево-тест. Текстовая структура без дизайна и задачи вида «где бы вы искали историю заказов». Отделяет проблемы структуры от проблем вёрстки.
• Шаг 3. Тест первого клика. На прототипе: куда человек нажимает первым, получив задачу. Если первый клик верный, задача обычно решается успешно.
• Шаг 4. Юзабилити-тест сценариев. Пять–восемь участников на кликабельном прототипе ловят большинство грубых проблем; как планировать такую сессию, разобрано в статье о тестировании на пяти пользователях.
• Шаг 5. Метрики после релиза. Доля успешно завершённых задач, число шагов до ключевых экранов, использование поиска как обходного пути, переходы в разделы из бургера. Как связать их с удовлетворённостью — в материале про SUS и HEART.

Чек-лист перед передачей в разработку

Перед тем как отдать макеты разработчикам, пройдитесь по списку. Он закрывает вопросы, которые иначе всплывут уже в коде.

• карта навигации: все экраны, уровни и переходы между ними;
• 3–5 пунктов верхнего уровня, порядок по частоте использования;
• иконки с текстовыми подписями, активное состояние не только цветом;
• цели касания не меньше 44×44 pt и 48×48 dp;
• поведение повторного нажатия на активную вкладку;
• сохранение состояния внутри каждой вкладки;
• обработка системного «Назад» на Android и свайпа на iOS;
• сценарии входа из пушей и глубоких ссылок, включая «Назад» после них;
• поведение при скрытой клавиатуре, в альбомной ориентации и на планшете;
• все состояния элементов навигации: бейджи, загрузка, офлайн — по чек-листу состояний компонента;
• доступные названия для VoiceOver и TalkBack у каждой вкладки и кнопки.

Редакция Флагштока

Пишем об UX/UI-дизайне: исследования, интерфейсы, дизайн-системы и доступность.