Modal vs Drawer vs Bottom-Sheet — что выбрать
Decision matrix для выбора overlay-паттерна по контексту, частоте, фокусу и mobile-поведению. Без шаблонного «modal для всего».
Действуй как senior interaction designer. Задача — не «выбрать красивее», а выбрать паттерн, который меньше всего мешает работе.
Сценарий: {{scenario}} Частота открытия: {{frequency}} Платформы: {{platforms}}
Три паттерна — что они на самом деле
| Паттерн | Что обещает пользователю | Что забирает |
|---|---|---|
| Modal (центр) | «Стоп. Реши прямо сейчас, иначе никуда не пойдёшь.» | Весь контекст вокруг. Возврата к фоновому состоянию нет. |
| Drawer (сбоку) | «Это рядом с задачей. Контекст под рукой.» | Часть ширины экрана. На mobile — почти всю. |
| Bottom-Sheet | «Я снизу. На mobile — самое естественное место для большого пальца.» | На desktop выглядит инородно. Глубокая вложенность ломается. |
6 критериев выбора (по этим — решение, не по «нравится»)
1. Modal stealing context — это плюс или минус?
- Плюс → modal. Юзер должен решить (delete confirm, payment, terms agreement).
- Минус → drawer. Юзер сравнивает с фоном (edit item рядом со списком, filters рядом с результатами).
2. Глубина задачи
- 1-2 поля, секунды → bottom-sheet (mobile) / inline popover (desktop).
- 5-10 полей, минута → drawer. Скролл, можно подсматривать назад.
- Многошаговая → full-page route, НЕ overlay. Overlay не выживает рефреш.
3. Частота
- Раз в сессию → modal оправдан (heavy interruption — ОК).
- Постоянно (filters, edit row) → drawer. Modal каждые 30 секунд бесит.
4. Нужен ли возврат к фону?
- Да, регулярно (сравниваю текст с правкой) → drawer.
- Нет, решение финальное → modal.
5. Mobile-поведение
- Mobile primary → bottom-sheet. Большой палец, безопасная зона снизу.
- Desktop primary, mobile fallback → drawer с full-screen на mobile.
- Только desktop → modal или drawer одинаково, по другим критериям.
6. Стек overlay'ев
- Если поверх уже открыт modal — НЕ открывай второй modal. Используй inline confirm или slide-in panel.
- Drawer внутри modal — антипаттерн. Это знак, что задача сложнее overlay'я и нужен route.
Что сделать
- Прогони сценарий по 6 критериям выше. На каждом — короткий ответ.
- Выбери паттерн. Если 2 критерия указывают на разные паттерны — выигрывает тот, который про частоту и контекст (1 и 3).
- Опиши spec для выбранного паттерна:
- Trigger (откуда открывается)
- Размер (по контенту / fixed / responsive)
- Dismiss (X, Esc, click-outside, swipe-down — что работает, что нет)
- Что с focus trap, scroll lock, body-scroll
- Что показывается на mobile (если основной — desktop) и наоборот
- Опиши edge cases:
- Form внутри dirty, юзер закрывает — что происходит?
- Длинный контент — где скролл (внутри overlay / на body)?
- Подтверждающий action — что disable во время запроса, что после успеха?
Формат вывода
Решение
Одна строка: «<modal/drawer/bottom-sheet>, потому что <2 главных критерия>».
Таблица критериев
# | Критерий | Ответ | Указывает на
Spec
- Trigger:
- Размер:
- Dismiss:
- Focus / scroll:
- Mobile fallback:
Edge cases
3-5 пунктов: вопрос → ответ.
Альтернатива (если бы я ошибся)
Что было бы вторым выбором и в каком случае стоит туда уйти.
Anti-patterns (НЕ делать)
- ❌ Modal по умолчанию «потому что все так делают». Modal — самый агрессивный паттерн, требует обоснования.
- ❌ Modal внутри modal. Это сигнал, что архитектура задачи сломана.
- ❌ Bottom-sheet на desktop без причины. На широких экранах это выглядит как мобильный костыль.
- ❌ Drawer шириной 30% экрана с формой на 12 полей — пользователь будет горизонтально скроллить или сжимать поля.
- ❌ Overlay без Esc и click-outside dismiss. Если ловушка нужна по UX — это modal с явным confirm.
- ❌ Сохранять состояние формы в URL для overlay'я и делать рефреш-сейф — это не overlay, это route. Перенеси.
Billing-страница
Что показывать: план, история, способ оплаты, инвойсы, отмена.
Сгенерировать варианты UI-компонента
Создать 4-6 разных подходов к компоненту с разным визуальным языком и трейд-оффами.
UI-критика с глазом дизайнера
Жёсткая оценка визуала: типографика, сетка, иерархия, ритм, цвет, детали.