Tabs, drawers, breadcrumbs: какой паттерн навигации роняет конверсию

Навигация — это последнее, о чём думают, когда продукт растёт. Сначала добавляют фичу, потом ещё одну, потом раздел, потом «давайте сюда тоже впихнём». В какой-то момент менеджер открывает аналитику и видит: люди не доходят до оплаты, не находят настройки, не возвращаются во вчерашний чат. И начинается охота на ведьм — переписывают кнопки, меняют цвета CTA, нанимают копирайтера. А проблема была в том, что три месяца назад tabs заменили на burger drawer, и половина аудитории просто перестала видеть половину продукта.

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

## Почему именно навигация роняет конверсию тише всего

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

Три причины, по которым навигационные ошибки редко ловят:

• Они равномерные. Падает не один шаг, а весь верх воронки. В графиках это выглядит как «у нас всегда так».
• Их прячут привычки команды. Дизайнер и PM знают где что лежит. Они физически не могут пройти флоу как новичок.
• Их легко списать на «не та аудитория». Удобный способ не чинить интерфейс.

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

## Сначала разберитесь, какой тип навигации вам вообще нужен

Перед выбором паттерна — короткая инвентаризация. Без неё спор «tabs или drawer» бессмысленный, потому что это спор о форме без понимания задачи.

### Четыре типа навигации, которые часто путают

• Глобальная — переход между крупными разделами продукта (главная, проекты, инбокс, настройки). Меняется редко, должна быть видна всегда.
• Локальная — переход внутри одного раздела (вкладки внутри проекта, подразделы профиля). Контекстная, меняется при смене раздела.
• Утилитарная — поиск, нотификации, аккаунт, помощь. Не часть основного флоу, но должна быть под рукой.
• Контекстная — хлебные крошки, «назад», «к списку». Помогает понять где ты и как вернуться.

Главная ошибка — смешать их в одном элементе. Burger, в который сваливают и разделы, и настройки, и логаут, и поддержку — классика. Пользователь открывает его, чтобы найти «Проекты», и теряется среди двенадцати пунктов разной природы.

### Чеклист инвентаризации перед редизайном навигации

• Выписали все возможные пункты навигации в один список
• Разметили каждый по типу: глобальный / локальный / утилитарный / контекстный
• Посмотрели в аналитике частоту использования каждого
• Отметили те, что нужны новичку в первые 5 минут
• Отметили те, что нужны платящему пользователю каждый день
• Проверили: нет ли пунктов, которыми не пользуется никто (часто это легаси из старых релизов)

После такой инвентаризации обычно выясняется, что половина «обязательных» пунктов меню вообще не нужна на видном месте, а пара критичных — наоборот, закопана.

## Tabs: когда они спасают, а когда душат

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

### Где tabs действительно работают

• Карточка объекта, у которого 2–5 равноправных аспектов (Обзор, Активность, Файлы, Доступы).
• Переключение между видами одного и того же содержимого (Список / Канбан / Календарь).
• Фильтр по статусу, где список не очень длинный (Все / Активные / Архив).

Во всех этих случаях пользователь понимает: я остаюсь на том же объекте, просто смотрю на него под другим углом.

### Анти-паттерны вкладок

• Семь и больше вкладок в ряд. На мобильном превращаются в горизонтальный скролл, и крайние вкладки становятся невидимыми.
• Вкладки как глобальная навигация. Если внутри каждой вкладки своя жизнь со своими разделами — это уже не вкладки, это разделы продукта, и их место в глобальном меню.
• Вкладки с разной природой контента. «Описание / Отзывы / Купить» — последняя должна быть кнопкой, а не вкладкой. Пользователь не «переключается» на покупку.
• Скрытый активный таб. На мобильном легко получить состояние, где не видно какая вкладка выбрана. Тест простой: сделайте скриншот — поймёте ли вы где находитесь, если откроете его через неделю.

### Вопросы для ревью вкладочного интерфейса

• Все ли вкладки помещаются без скролла на самом маленьком поддерживаемом экране?
• Понятно ли с первого взгляда, какая вкладка активна?
• Сохраняется ли состояние вкладки при возврате (или сбрасывается на первую)?
• Если бы вкладок было в два раза больше — выдержал бы паттерн? Если нет, не выбрали ли вы его на вырост?

Короткий итог по первому подходу к теме: навигация ломает конверсию не громко, а методично, и почти всегда из-за того, что элементы разной природы свалили в один контейнер. Дальше разберём drawers, burger-меню и breadcrumbs — и где каждый из них честно работает, а где маскирует структурную проблему продукта.

## Drawers: компромисс, который часто маскирует структурную проблему

Drawer — это панель, выезжающая сбоку или снизу. На бумаге звучит идеально: основной экран не загромождён, всё нужное под рукой. На практике drawer слишком часто становится свалкой для того, что команда не смогла честно структурировать.

### Где drawer действительно уместен

• Фильтры и сортировка в списках и каталогах. Пользователь настраивает один раз, потом возвращается к контенту.
• Детали объекта без перехода на отдельный экран. Кликнул по строке в таблице — выехала панель с подробностями, закрыл — остался в списке. Это сохраняет контекст.
• Утилитарные действия в редакторе. Слои, свойства, история — всё, что нужно рядом, но не должно отъедать экран постоянно.
• Мобильный аналог сайдбара в админках и дашбордах, где иначе не хватает места.

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

### Когда drawer ломает конверсию

• Главная навигация спрятана в drawer на десктопе. Пользователь не видит структуру продукта, пока не догадается ткнуть в иконку. На ревью часто выясняется, что половина разделов открывается реже именно после такого редизайна.
• Drawer внутри drawer. Открыли панель деталей, в ней кнопка «настройки», которая открывает ещё одну панель. Возврат назад превращается в квест, особенно на мобильном.
• Критичный CTA внутри drawer. «Купить», «Отправить», «Подтвердить» не должны жить за дополнительным кликом. Любая прослойка между намерением и действием — это потерянные пользователи.
• Drawer без чёткого способа закрыть. Нет крестика, не работает клик по затемнению, свайп не очевиден. На мобильном это особенно больно.

### Диагностический вопрос про drawer

Спросите себя честно: drawer здесь потому, что это лучший паттерн для задачи, или потому, что не хватило смелости решить, что из контента важнее? Если второе — drawer не решит проблему, а отложит её. Пользователь всё равно столкнётся со всем содержимым, только теперь ещё и через лишний клик.

## Burger и breadcrumbs: два паттерна с противоположными болезнями

### Burger: честный инструмент с нечестной репутацией

Burger-меню стало мемом «куда сваливают всё лишнее». Но сам по себе паттерн нормальный — проблема в том, как его используют.

Burger работает, когда:

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

Burger ломается, когда становится универсальной свалкой. Признаки беды: больше десяти пунктов, разделители между блоками разной природы, вложенные аккордеоны на два уровня вниз, дублирование пунктов из других мест интерфейса «на всякий случай».

### Breadcrumbs: работают только в глубоких иерархиях

Хлебные крошки оправданы там, где у контента есть настоящая древовидная структура: каталоги с категориями и подкатегориями, документация, файловые системы, админки с вложенными сущностями. В плоских продуктах с 4–5 разделами breadcrumbs не дают ничего, кроме визуального шума.

Типичные ошибки:

• Крошки, дублирующие заголовок страницы. «Проекты / Маркетинг / Лендинг Q3» и сразу под ним H1 «Лендинг Q3». Один из элементов лишний.
• Последний пункт — ссылка. Активная страница не должна быть кликабельной, иначе пользователь жмёт и попадает туда же, теряя доверие к навигации.
• Крошки, не отражающие реальный путь. Пришёл из поиска, а в крошках искусственное «Главная / Каталог / Категория», по которой ты никогда не шёл. Это не помощь, это фантазия дизайнера о том, как должен был прийти пользователь.

## Сценарий ревью навигации за один проход

Берёте макет или живой продукт и идёте по шагам, не отвлекаясь на эстетику.

• Назовите тип каждого навигационного элемента вслух: глобальный, локальный, утилитарный, контекстный.
• Найдите элементы, где смешаны типы. Это первые кандидаты на разделение.
• Для каждого drawer и burger задайте вопрос: что будет, если развернуть содержимое прямо на экране? Если становится только лучше — паттерн выбран не под задачу.
• Проверьте мобильную версию отдельно, а не как «уменьшенный десктоп». Часто именно там навигация разваливается.
• Пройдите ключевой флоу новичка: попадает ли он в цель за разумное число кликов, или путается между вкладками, drawer и burger.
• Посмотрите на состояние «вернулся через неделю». Понятно ли где ты находишься без подсказок?

### Типичные ошибки, которые видно в макете до релиза

• Активное состояние оформлено слабее, чем hover. На статичном скриншоте не отличить, где пользователь.
• Иконка без подписи в глобальной навигации. На ревью все угадывают значения по-разному — это сигнал, что и пользователь не угадает.
• Drawer и модалка используются вперемешку для похожих задач. Команда сама не помнит, где какой паттерн и почему.
• Breadcrumbs на странице, у которой нет родителя. Цепочка из одного звена выглядит как баг.

Короткий итог: выбор между tabs, drawer, burger и breadcrumbs — это не вопрос вкуса, а проверка того, насколько честно вы разложили содержимое продукта по типам. Когда инвентаризация сделана, паттерн выбирается почти автоматически. Когда нет — любой выбранный элемент будет тихо терять конверсию, и переделка цвета или иконки этого не починит.

## Навигация в продуктах с AI-функциями: новый слой, старые правила

AI-фичи редко живут в отдельном разделе. Они подмешиваются в существующий интерфейс: «сгенерировать черновик» внутри редактора, «спросить у ассистента» поверх таблицы, «суммаризировать» в карточке документа. И именно здесь навигация ломается чаще всего, потому что команда добавляет AI-точку входа поверх старой структуры, не пересматривая её.

### Где обычно прячут AI и почему это плохо

• В floating-кнопке в углу. Звучит безобидно, но это четвёртый плавающий элемент после чата поддержки, виджета фидбэка и онбординг-подсказки. Пользователь учится игнорировать весь угол целиком.
• В новом пункте burger-меню. AI становится «ещё одним разделом», хотя по смыслу это инструмент внутри текущего контекста, а не отдельное место.
• В drawer справа, который перекрывает контент. Ассистент по таблице не видит таблицу — и пользователь тоже, пока с ним общается.
• В отдельной вкладке tabs рядом с «Обзор» и «Настройки». Вкладки про навигацию между состояниями одного объекта, а AI — это действие над объектом, не состояние.

Хорошая проверка: спросите, AI у вас — это место, режим или действие. Место требует пункта в глобальной навигации, режим — переключателя в локальной, действие — кнопки в контексте. Большинство ассистентов — это действие или режим, и почти никогда не место.

### Командный паттерн: палитра вместо ещё одной кнопки

Если AI-функций становится больше трёх, разумнее ввести command palette (Cmd+K) и убрать половину точек входа из интерфейса. Это снимает давление с глобальной навигации и работает как единый «вход в действия» — поиск, переходы, AI-команды, шорткаты. Главное — не превращать палитру в свалку, как это часто случается с burger. Те же правила: группировка по типам, понятные категории, активное состояние.

## Как объяснить выбор паттерна команде

На ревью часто не хватает не аргументов, а языка. Дизайнер говорит «здесь лучше drawer», продакт слышит «мне так нравится». Чтобы разговор стал предметным, удобно фиксировать решение по короткой схеме.

### Шаблон решения по навигационному элементу

• Тип содержимого: глобальный / локальный / утилитарный / контекстный.
• Частота использования: ежедневно / в сессии / редко / разово.
• Связь с основным контентом: заменяет, дополняет, требует одновременного просмотра.
• Выбранный паттерн и одно предложение почему именно он.
• Что мы отвергли и почему — хотя бы один альтернативный вариант.

Последний пункт самый важный. Решение, у которого нет отвергнутой альтернативы, не решение, а первая попавшаяся идея. Когда в обсуждении звучит «рассматривали tabs, но контента в разделах слишком неравный объём — половина вкладок будет пустой», спорить становится не с вкусом, а с логикой.

### Вопросы, которые стоит задавать на ревью

• Какой пользовательский сценарий мы оптимизируем — первый заход или ежедневное использование?
• Что произойдёт с этим элементом, когда добавится ещё три фичи? Он масштабируется или мы заранее знаем, что переделаем?
• На мобильном этот паттерн остаётся тем же или превращается во что-то другое? Если другое — это сознательное решение или мы не думали?
• Есть ли в продукте уже похожая задача, решённая другим паттерном? Если да — почему здесь иначе?
• Что увидит пользователь, который пришёл по прямой ссылке и не проходил предыдущие шаги?

## Как проверить качество навигации в метриках

Часть проблем видна без пользователей, но финальное слово — за данными. Что имеет смысл смотреть конкретно для навигации.

### Минимальный набор сигналов

• Доля кликов по основным пунктам глобальной навигации. Если один-два пункта собирают почти всё, остальные — мёртвый груз. Если клики равномерно размазаны — иерархия не выстроена.
• Открытия burger и drawer без последующего клика внутри. Пользователь открыл, посмотрел, закрыл. Это либо разведка, либо разочарование — нужно сегментировать по сессии.
• Возвраты «назад» сразу после перехода по пункту меню. Сигнал, что подпись не соответствует содержимому.
• Использование поиска вместо навигации. Если в продукте с понятной структурой пользователи всё равно ищут — структура только кажется понятной.
• Глубина переходов от входа до целевого действия. Растёт после редизайна — что-то спрятали слишком глубоко.

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

## Чеклист перед тем, как отдать навигацию в разработку

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

• У каждого пункта глобальной навигации есть стабильный URL, на который можно дать прямую ссылку.
• Активное состояние видно с расстояния, а не угадывается по едва заметной подчёркивающей линии.
• Глубина иерархии не превышает трёх уровней; если превышает — для этого есть осознанная причина, а не «так получилось».
• Drawer и модалка не открываются поверх друг друга. Если возникает второй слой — пересматриваем флоу.
• Tabs не используются, когда содержимое одной вкладки в десять раз объёмнее другой.
• Breadcrumbs показывают путь, по которому реально можно вернуться, а не выдуманную иерархию для красоты.
• На мобильном для каждого паттерна есть осознанный аналог — не «то же самое, только уже».
• Состояние навигации сохраняется при возврате назад: открытый раздел остаётся открытым, прокрутка — на месте.
• Клавиатурная навигация работает: Tab проходит по элементам в логичном порядке, Esc закрывает оверлеи.
• Скринридер озвучивает текущий раздел и количество пунктов в списке, а не «button button button».

## Анти-паттерны, которые встречаются чаще всего

### Drawer как свалка для всего, что не поместилось

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

### Tabs, которые перезагружают страницу

Если переключение вкладки сбрасывает фильтры, закрывает открытые панели и возвращает скролл наверх — это уже не tabs, а скрытая навигация между разделами под видом локальной. Пользователь ожидает быстрого переключения контекста, а получает полноценный переход. Либо делаем настоящие tabs с сохранением состояния, либо честно называем это разделами.

### Breadcrumbs из одного элемента

Хлебные крошки, в которых всегда виден только «Главная > Текущая страница», не несут информации. Они занимают место, добавляют визуальный шум и создают ощущение глубины, которой нет. Если иерархия плоская — breadcrumbs не нужны.

### Burger на десктопе «для единообразия»

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

### Контекстное меню как единственный способ сделать действие

Если важное действие доступно только через right-click или троеточие, половина пользователей его не найдёт. Контекстное меню — это ускоритель для опытных, а не основной путь. Дублируем критичные действия в видимом интерфейсе.

## Вопросы, которые полезно задать на финальном ревью

• Если завтра придёт новый пользователь и откроет продукт впервые — какой пункт навигации он откроет первым? Мы знаем ответ или гадаем?
• Какие три действия пользователь выполняет чаще всего? Все они в один клик от старта или спрятаны?
• Что мы будем делать, когда продукт обзаведётся ещё одной крупной фичей? У нас есть место или мы будем втискивать?
• Если убрать половину пунктов меню — что-то сломается в реальных сценариях или станет только чище?
• Совпадает ли название пункта с тем, что пользователь увидит после клика? Или подпись — это маркетинговая формулировка, а внутри — другое слово?

## Короткий итог

Навигация — это не визуальный элемент, а решение о том, какие сценарии в продукте важнее остальных. Tabs, drawers, breadcrumbs, burger, command palette — каждый паттерн отвечает на свой вопрос, и подмена одного другим стоит не разговоров о вкусе, а реальных кликов и возвратов. Полезнее всего относиться к навигации как к гипотезе: фиксировать, что именно мы оптимизируем, какую альтернативу отвергли и по каким сигналам поймём, что ошиблись. Тогда следующий редизайн перестаёт быть «давайте всё переделаем» и становится точечной правкой одного слоя, который перестал работать.