Модальное окно, drawer или страница: как выбрать UI-компонент без дизайнера

Каждая команда рано или поздно упирается в вопрос: что использовать для этой задачи — модальное окно, drawer (выдвижную панель) или отдельную страницу? На первый взгляд, мелочь. Но неправильный выбор раздражает пользователей, ломает сценарии и прячет важный контекст. Дело не в красоте, а в эффективности и удовлетворённости.

Проблема в том, что у разработчиков часто нет под рукой чётких UX-правил. Когда дизайнера рядом нет, команда выбирает то, что проще реализовать, а не то, что удобнее. Отсюда модалки для сложных многошаговых задач (потому что это быстро) и страницы для простых действий (потому что это привычно). И то, и другое — мимо.

Простое правило выбора

После многих лет исправления ошибок чужих команд я вывел короткую формулу:

• Короткая сфокусированная задача → модальное окно. Подтверждение действия, быстрый ввод.
• Задача, где нужен контекст текущего экрана → drawer. Настройки, фильтры, дополнительные данные.
• Многошаговый процесс → страница. Онбординг, оформление заказа.

Это не панацея, но работает в 80% случаев. Почему? Потому что каждый компонент по-разному влияет на когнитивную нагрузку.

Как это работает на самом деле

Модальное окно: сила ограничения

Модалка затемняет фон и зажимает задачу в маленькое пространство. Это механически снижает когнитивную нагрузку: мозг не отвлекается на посторонний контекст. Идеально для «Удалить файл?» или «Добавить тег».

Если вместо модалки взять drawer, фон остаётся видимым, внимание рассеивается. Если сделать страницу — пользователь уходит с текущего экрана и потом мучительно возвращается.

Drawer: сохраняем пространственную непрерывность

Drawer выезжает поверх экрана, не заменяя его. Пользователь видит основной контент и одновременно работает с дополнительным. Классика — фильтры в интернет-магазине: вы меняете параметры и видите, как меняется сетка товаров.

Модалка в этом сценарии скрыла бы контент, заставив полагаться на память. Страница — разорвала бы процесс на два отдельных шага.

Страница: место для сложных процессов

Страница даёт неограниченное пространство для последовательных шагов. Здесь уместны индикаторы прогресса, подробные сообщения об ошибках, разделы. Онбординг или checkout — это страница, без вариантов.

Засунуть такой процесс в модалку — значит заставить пользователя дышать в тесной коробке. Drawer будет отвлекать видимым фоном, из-за чего человек потеряет нить.

Сравнение компонентов

Типичные ошибки и краевые случаи

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

Drawer для критического предупреждения. Например, уведомление об ошибке оплаты. Drawer конкурирует с фоном, и пользователь его банально не замечает. Мозг игнорирует всё, что не относится к главному. Тут нужна модалка — она намеренно прерывает действие.

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

И ещё один момент: если задача одновременно короткая и требует контекста, правило даёт сбой. Редкий случай, но бывает. Тогда вспоминайте главное: минимизируйте переключение контекста и когнитивную нагрузку. И тестируйте на живых людях.

Чек-лист перед выбором

1. Сколько времени займёт задача? Меньше минуты — модалка.
2. Пользователю нужно видеть предыдущий экран? Да — drawer.
3. Шагов больше трёх? Это уже страница.
4. Задачу можно прервать без потери данных? Модалка допустима и для длинных процессов.
5. Есть сомнения? Спросите любого, кто будет пользоваться.

Итог

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