.svg)
Пользователь открывает приложение и первые три секунды просто смотрит на экран. Он ещё не понял, куда нажать. Это не значит, что интерфейс некрасивый - это значит, что структура перемещения между разделами не считывается мгновенно. Именно здесь начинается или заканчивается доверие к продукту.
Выбор схемы перемещения между экранами - одно из первых архитектурных решений при проектировании мобильного приложения. Tab bar, drawer, bottom sheet, stack - каждый из этих подходов решает конкретную задачу и ломается при неправильном применении. Проблема в том, что их часто выбирают по инерции: «все делают снизу - сделаем снизу».
В этой статье разберём, чем отличаются основные паттерны навигации в мобильных приложениях, когда каждый из них работает, а когда создаёт трение, и как принять решение, которое не придётся переделывать через квартал.
Коротко:
- Tab bar подходит для 3-5 равнозначных разделов с частым переключением между ними.
- Drawer уместен, когда разделов много или они второстепенны относительно основного контента.
- Bottom sheet - не навигационный паттерн в классическом смысле: он показывает дополнительный контекст, не уводя пользователя с экрана.
- Stack-навигация (последовательные экраны) работает для линейных сценариев: оформление заказа, онбординг, настройка.
- Главная ошибка - смешивать паттерны без логики: tab bar плюс drawer плюс вложенные стеки без чёткой иерархии.
- Выбор схемы зависит от трёх факторов: количество разделов, частота переключения и тип контента.
Четыре базовых паттерна и что они делают
Прежде чем выбирать, нужно понять, что именно каждый паттерн решает. Они не взаимозаменяемы - у каждого своя роль в иерархии интерфейса.
Tab bar (нижняя панель вкладок) - постоянно видимая полоса внизу экрана с 3-5 иконками. Пользователь всегда знает, где находится, и может переключиться в один тап. Это самый «дорогой» элемент с точки зрения экранного пространства: он занимает место на каждом экране приложения.
Drawer (боковое меню) - панель, которая выезжает сбоку по свайпу или нажатию на «гамбургер». Скрыта по умолчанию, открывается поверх контента. Вмещает много пунктов, но требует явного действия для открытия - пользователь должен помнить, что она существует.
Bottom sheet - панель, которая поднимается снизу и частично или полностью перекрывает экран. Технически это не навигация между разделами, а способ показать дополнительный контент или действия без полного перехода. Используется для фильтров, деталей объекта, меню действий.
Stack-навигация - линейная цепочка экранов, где каждый следующий открывается поверх предыдущего. Пользователь идёт вперёд и возвращается назад. Это основа большинства сценариев внутри разделов, а не способ переключаться между ними.
Tab bar: когда нижняя панель работает
Tab bar - самый узнаваемый паттерн мобильного UX. Instagram, Telegram, Spotify, большинство банковских приложений используют именно его. Причина простая: большой палец легко дотягивается до нижней части экрана, а постоянная видимость вкладок снижает когнитивную нагрузку - пользователь не думает, как переключиться.
Паттерн хорошо работает при нескольких условиях одновременно:
- Разделов от 3 до 5. Меньше трёх - нет смысла в постоянной панели. Больше пяти - иконки становятся мелкими, подписи не читаются.
- Разделы равнозначны по важности. Если один раздел используется в 90% случаев, а остальные - редко, tab bar создаёт ложное ощущение равенства.
- Пользователь часто переключается между разделами в рамках одной сессии. Если типичный сценарий - зайти в один раздел и выйти, постоянная панель тратит место впустую.
Важный нюанс tab bar дизайна: каждая вкладка должна сохранять своё состояние при переключении. Если пользователь прокрутил ленту вниз, перешёл в профиль и вернулся - он должен оказаться там же, где был. Сброс состояния при переключении - одна из самых раздражающих ошибок реализации.
Пример: Приложение для трекинга привычек. Четыре раздела: сегодня, статистика, каталог привычек, профиль. Пользователь несколько раз за день заходит отметить выполнение - переключается между «сегодня» и «статистикой». Tab bar здесь логичен: разделы равнозначны, переключение частое, пальцу удобно.
Drawer: когда боковое меню оправдано
Drawer долгое время был стандартом Android-приложений, пока Google в своих гайдлайнах Material Design не начал отдавать предпочтение нижней навигации. Тем не менее паттерн живёт и остаётся уместным в конкретных сценариях.
Drawer navigation оправдан, когда разделов больше пяти или когда они не равнозначны по частоте использования. Представьте почтовый клиент: основная работа происходит во «Входящих», а «Черновики», «Отправленные», «Спам», «Архив», «Метки» нужны значительно реже. Держать всё это в нижней панели - значит перегрузить интерфейс. Drawer убирает второстепенное из поля зрения, не удаляя его.
Ещё один сценарий - приложения с выраженной «главной сценой». Карты, редакторы, медиаплееры: контент занимает весь экран, и постоянная панель снизу мешает. Drawer позволяет сохранить доступ к настройкам и дополнительным функциям, не жертвуя площадью экрана.
Слабое место паттерна - низкая обнаруживаемость. Исследования юзабилити показывают, что пользователи реже исследуют скрытые меню, чем видимые. Если важный раздел спрятан в drawer, часть аудитории просто не найдёт его. Это не повод отказываться от паттерна, но повод убедиться, что в меню нет ничего критически важного для основного сценария.
Частая ошибка: Использовать drawer как «мусорный ящик» - складывать туда всё, что не поместилось в основной интерфейс. Пользователь открывает меню и видит 15 пунктов без логичной группировки. Это не решает проблему архитектуры - это её маскирует.
Bottom sheet: не навигация, а контекст
Bottom sheet часто путают с навигационным паттерном, хотя по природе это инструмент для показа дополнительного контента без смены экрана. Он поднимается снизу, частично перекрывает текущий экран и позволяет взаимодействовать с дополнительными данными или действиями.
Типичные сценарии использования:
- Детали объекта на карте (нажал на метку - снизу появилась карточка кафе)
- Фильтры и сортировка в каталоге
- Меню действий с выбранным элементом (share, delete, edit)
- Подтверждение операции с деталями (сумма, получатель, комиссия перед отправкой)
Ключевое свойство bottom sheet в мобильном UX - пользователь не теряет контекст. Он видит, откуда пришёл, и может закрыть панель свайпом вниз или тапом по затемнённому фону. Это делает паттерн менее «тяжёлым», чем полный переход на новый экран.
Проблемы начинаются, когда в bottom sheet пытаются уместить слишком много. Если контент требует прокрутки внутри панели, а сама панель при этом тоже прокручивается - возникает конфликт жестов. Пользователь не понимает, куда ведёт свайп: закрывает панель или скроллит её содержимое. Решение - либо ограничивать контент, либо переводить его на отдельный экран.
Stack-навигация: линейные сценарии
Stack - это не отдельный паттерн выбора, а базовый механизм перемещения внутри разделов. Нажал на карточку товара - открылся экран товара. Нажал «Оформить» - открылся экран оформления. Нажал «Назад» - вернулся.
Stack хорошо работает для линейных задач с чётким началом и концом: онбординг, оформление заказа, настройка аккаунта, создание объекта. Пользователь движется по шагам и понимает прогресс.
Ошибка - строить на stack-навигации разделы, между которыми нужно часто переключаться. Если пользователь должен сравнивать два объекта, переходя туда-обратно, стек создаёт длинную цепочку «назад-назад-назад». Это сигнал, что нужен другой паттерн или другая архитектура экрана.
Как выбрать паттерн: три вопроса
Выбор схемы перемещения между разделами сводится к трём вопросам. Ответив на них честно, можно отсечь неподходящие варианты.
Сколько разделов верхнего уровня? До 5 - tab bar. От 5 и больше - drawer или комбинация. Если разделов 2-3, возможно, нижняя панель вообще не нужна: достаточно переключателя или сегментированного контрола.
Как часто пользователь переключается между разделами? Если несколько раз за сессию - нужна постоянно видимая навигация (tab bar). Если пользователь заходит в один раздел и работает там - drawer не создаст проблем, а сэкономит место.
Что важнее: контент или структура? Если приложение - это прежде всего контент (карты, медиа, редактор), постоянная нижняя панель мешает. Если приложение - это набор равнозначных инструментов, видимая структура помогает ориентироваться.
| Паттерн | Оптимальное число разделов | Частота переключения | Типичный тип приложения |
|---|---|---|---|
| Tab bar | 3-5 | Высокая | Соцсети, банки, трекеры |
| Drawer | 5+ | Низкая или средняя | Почта, мессенджеры с папками, CRM |
| Bottom sheet | Не применимо | Не применимо | Дополнительный контекст в любом типе |
| Stack | Не применимо | Линейный сценарий | Оформление, онбординг, создание |
Платформенные различия: iOS и Android
Вакансии для дизайнеров
Платформы имеют устоявшиеся конвенции, и нарушать их без причины - значит создавать трение для пользователей, привыкших к определённому поведению.
На iOS tab bar - исторически основной паттерн. Apple Human Interface Guidelines рекомендуют его для приложений с несколькими равнозначными разделами. Drawer на iOS встречается реже и часто воспринимается как «андроидный» паттерн.
На Android Material Design долго продвигал navigation drawer как стандарт, но начиная с Material Design 2 акцент сместился на bottom navigation bar - аналог tab bar. Сейчас оба паттерна считаются приемлемыми, но нижняя навигация предпочтительна для частого переключения.
Если приложение кроссплатформенное, выбор паттерна стоит делать исходя из задачи, а не платформы. Главное - не использовать разные схемы на iOS и Android без веской причины: это усложняет поддержку и создаёт несогласованный опыт.
Типичные ошибки реализации
Большинство проблем с навигацией в мобильных приложениях возникают не из-за неправильного выбора паттерна, а из-за ошибок в деталях реализации.
Смешение паттернов без иерархии. Tab bar плюс drawer плюс bottom sheet на одном экране - это не «богатый интерфейс», это хаос. Пользователь не понимает, что главное, а что второстепенное. Каждый паттерн должен занимать своё место в иерархии.
Активная вкладка не отражает текущий экран. Если пользователь перешёл на экран из push-уведомления или диплинка, активная иконка в tab bar должна соответствовать разделу, в котором он находится. Рассинхронизация ломает ориентацию.
Drawer открывается свайпом, который конфликтует с контентом. Если на экране есть горизонтальный скролл или карусель, свайп вправо для открытия drawer будет срабатывать случайно. Нужно либо отключить жест открытия, либо пересмотреть архитектуру экрана.
Bottom sheet без обработки конфликта жестов. Когда внутри панели есть скроллируемый список, система не понимает, что делать со свайпом вниз: закрывать панель или скроллить список. Решение - блокировать закрытие свайпом, пока список не прокручен до верха.
Слишком много уровней вложенности в stack. Если пользователю нужно нажать «Назад» пять раз, чтобы вернуться к началу, архитектура экранов требует пересмотра. Хорошее правило: больше трёх уровней вложенности - сигнал проблемы.
Иконки в tab bar без подписей. Иконки без текста работают только для очень узнаваемых символов (дом, поиск, профиль). Всё остальное требует подписи. Подробнее об этом - в статье про иконки в интерфейсе.
Комбинирование паттернов: когда это работает
Реальные приложения редко используют один паттерн в чистом виде. Вопрос не в том, можно ли комбинировать, а в том, есть ли у комбинации логика.
Рабочая комбинация: tab bar для основных разделов плюс stack-навигация внутри каждого раздела. Это стандарт большинства приложений. Пользователь переключается между разделами через нижнюю панель, а внутри раздела движется по экранам вперёд-назад.
Ещё одна рабочая комбинация: tab bar плюс bottom sheet для дополнительного контекста. Пользователь находится в разделе, нажимает на объект - снизу поднимается панель с деталями. Tab bar при этом остаётся видимым или скрывается - зависит от высоты панели.
Проблемная комбинация: drawer плюс tab bar одновременно. Два конкурирующих паттерна навигации верхнего уровня создают путаницу. Пользователь не понимает, чем они отличаются и что в каком месте искать. Если оба присутствуют, нужна чёткая логика: tab bar для основных разделов, drawer для настроек и второстепенных функций.
Пример рабочей архитектуры: Приложение для доставки еды. Tab bar с четырьмя разделами: главная, поиск, заказы, профиль. Внутри «главной» - stack-навигация: ресторан - меню - блюдо - корзина - оформление. При нажатии на фильтры в поиске поднимается bottom sheet с параметрами. Drawer отсутствует - не нужен, разделов мало и все равнозначны.
Чеклист перед финальным решением
- Посчитаны разделы верхнего уровня - не больше 5 для tab bar.
- Проверена частота переключения между разделами в типичном сценарии.
- Определено, что важнее на экране: контент или структура.
- Учтены платформенные конвенции iOS и Android.
- Проверено, нет ли конфликтов жестов между паттернами и контентом.
- Каждый паттерн занимает своё место в иерархии - нет двух конкурирующих навигаций верхнего уровня.
- Активное состояние tab bar синхронизировано с текущим экраном, включая диплинки.
- Состояние вкладок сохраняется при переключении.
- В drawer нет критически важных для основного сценария разделов.
- Bottom sheet не перегружен контентом, требующим прокрутки.
FAQ
Чем tab bar отличается от bottom navigation bar?
По сути это одно и то же - постоянно видимая панель с вкладками внизу экрана. «Tab bar» - термин из экосистемы Apple и iOS HIG, «bottom navigation bar» - из Material Design. Принцип работы идентичен.
Когда drawer лучше tab bar?
Когда разделов больше пяти, когда они неравнозначны по частоте использования, или когда контент должен занимать весь экран без постоянной панели снизу. Drawer также уместен в приложениях, где основной сценарий линейный, а дополнительные разделы нужны редко.
Можно ли использовать bottom sheet как основную навигацию?
Нет. Bottom sheet - это инструмент для дополнительного контента и действий в контексте текущего экрана. Использовать его для переключения между основными разделами значит нарушить ожидания пользователя и создать непредсказуемое поведение.
Сколько уровней вложенности допустимо в stack-навигации?
Три уровня - комфортный максимум для большинства сценариев. Четыре уровня допустимы, если каждый шаг логически необходим. Пять и больше - сигнал, что архитектуру нужно пересмотреть: возможно, часть экранов можно объединить или заменить bottom sheet.
Нужно ли делать разную навигацию для iOS и Android?
Не обязательно, но стоит учитывать конвенции. На iOS tab bar - привычный паттерн, drawer воспринимается непривычно. На Android оба варианта приемлемы. Если ресурсы позволяют, небольшие адаптации под платформу улучшают опыт. Если нет - выбирайте паттерн под задачу и придерживайтесь его на обеих платформах.
Как понять, что выбранная схема не работает?
Сигналы проблемы: пользователи часто используют кнопку «Назад» там, где должны переключаться между разделами; в аналитике видно, что часть разделов почти не посещается; на юзабилити-тестах люди не могут найти нужный раздел с первой попытки. Если два из трёх симптомов есть - архитектуру стоит пересмотреть.
Итог
Выбор схемы перемещения между экранами - это не эстетическое решение. Tab bar, drawer и bottom sheet решают разные задачи, и ни один из них не является универсально правильным. Tab bar работает там, где разделов мало и переключение частое. Drawer уместен, когда структура сложная или контент важнее навигации. Bottom sheet - это инструмент контекста, а не маршрутизации.
Большинство проблем возникают не из-за неправильного выбора паттерна, а из-за отсутствия логики в комбинировании. Если каждый элемент навигации занимает своё место в иерархии и отвечает на конкретный вопрос пользователя «где я и куда могу пойти», интерфейс работает. Если нет - никакая красота иконок не спасёт от путаницы.