.svg)
Коротко:
- Алерт, тост и бейдж решают разные задачи - путаница между ними раздражает пользователей и снижает доверие к продукту.
- Выбор компонента зависит от трёх вещей: срочности, требуется ли действие и нужно ли прерывать пользователя.
- Самая частая ошибка - показывать всё подряд через один и тот же паттерн, обычно через всплывающее сообщение в углу экрана.
- Молчать тоже важно: не каждое системное событие заслуживает визуальной реакции.
- Иерархия приоритетов должна быть зафиксирована в дизайн-системе, иначе каждый экран решает эту задачу по-своему.
Уведомления в продукте кажутся мелочью - пока их не становится слишком много. Пользователь открывает приложение и сразу видит три всплывающих сообщения, красный кружок на иконке профиля, баннер о новой функции и предупреждение о незаполненном поле. Ни одно из них не требует немедленного ответа. Но вместе они создают ощущение, что продукт кричит.
Проблема не в самих компонентах - а в отсутствии системы. Дизайнер добавляет тост, потому что «так принято», разработчик вешает бейдж, потому что «надо привлечь внимание», менеджер просит баннер, потому что «важно, чтобы все заметили». В итоге интерфейс работает как несколько человек, говорящих одновременно.
В этой статье разберём типологию паттернов, логику выбора между ними и конкретные правила, которые помогут выстроить систему - а не набор случайных решений.
Три основных паттерна и чем они отличаются
Прежде чем выбирать компонент, нужно понять, что каждый из них делает по природе своей.
Алерт (alert) - это прерывание. Он блокирует или существенно перекрывает текущий контекст и требует реакции: подтвердить, отклонить, прочитать. Алерт говорит: «Стоп, сначала разберись с этим». Это уместно для критических ошибок, деструктивных действий и ситуаций, где продолжение без ответа невозможно или опасно.
Тост (toast) - это информирование без прерывания. Появляется на несколько секунд, сообщает о результате действия и исчезает. Пользователь может его проигнорировать. Подходит для подтверждений: «Файл сохранён», «Письмо отправлено», «Настройки обновлены». Ключевое свойство - тост не требует ответа.
Бейдж (badge) - это пассивный счётчик. Маленький кружок с цифрой или точкой на иконке, который сигнализирует: что-то есть, когда будешь готов - посмотри. Он не прерывает, не исчезает сам и не требует немедленного внимания. Уместен для непрочитанных сообщений, задач в очереди, обновлений.
| Паттерн | Прерывает? | Требует действия? | Исчезает сам? | Типичный сценарий |
|---|---|---|---|---|
| Алерт | Да | Да | Нет | Удаление данных, критическая ошибка |
| Тост | Нет | Нет | Да (3-5 сек) | Успешное сохранение, подтверждение |
| Бейдж | Нет | Нет | Нет | Непрочитанные, счётчик задач |
Есть ещё несколько смежных паттернов. Инлайн-сообщения появляются прямо внутри контента - рядом с полем формы, в строке таблицы, под кнопкой. Они не прерывают, но остаются видимыми, пока проблема не решена. Баннеры занимают горизонтальную полосу сверху или снизу экрана - их используют для системных предупреждений, технических работ или глобальных статусов. Снэкбар (snackbar) - это фактически тост, только в терминах Material Design; по поведению они идентичны.
Как выбрать паттерн: три вопроса
Прежде чем добавить любой компонент, ответьте на три вопроса.
Насколько это срочно? Если пользователь не среагирует сейчас - что произойдёт? Потеряет несохранённые данные? Тогда нужен алерт. Просто не узнает, что письмо отправлено? Достаточно тоста. Не увидит новое сообщение прямо сейчас? Хватит бейджа.
Требуется ли действие? Если да - алерт или инлайн-сообщение, в зависимости от того, блокирует ли ошибка весь флоу. Если нет - тост или бейдж.
Нужно ли прерывать пользователя? Это самый важный вопрос. Прерывание стоит дорого: человек теряет контекст, раздражается, начинает машинально закрывать все попапы. Прерывайте только тогда, когда продолжение без ответа невозможно или когда цена ошибки очень высока.
Пример: Пользователь нажимает «Удалить аккаунт». Это деструктивное, необратимое действие - алерт с подтверждением уместен. Пользователь нажимает «Сохранить черновик» - тост «Черновик сохранён» достаточен. Пользователь получает новое сообщение в чате, пока работает в другом разделе - бейдж на иконке чата, без прерывания.
Иерархия приоритетов: когда один паттерн не справляется
В реальных продуктах события редко бывают одного уровня важности. Система авторизации падает - это не то же самое, что «ваш профиль на 80% заполнен». Смешивать их в одном компоненте - значит обесценивать оба.
Хорошая практика - разделить события на уровни и зафиксировать это в дизайн-системе:
- Критический уровень - блокирует работу, требует немедленного ответа. Алерт или полноэкранное состояние ошибки.
- Предупреждение - не блокирует, но требует внимания в ближайшее время. Баннер или инлайн-сообщение.
- Информация - подтверждение успешного действия, нейтральный статус. Тост.
- Пассивное обновление - что-то изменилось, пользователь увидит, когда будет готов. Бейдж.
Если в продукте нет такой иерархии, каждый новый экран или фича решают этот вопрос самостоятельно. Со временем интерфейс превращается в коллекцию несогласованных решений.
Алерты в интерфейсе: когда прерывание оправдано
Алерты - самый дорогой паттерн с точки зрения внимания пользователя. Они буквально останавливают работу. Именно поэтому их так легко обесценить: если алерт появляется при каждом мелком событии, пользователь начинает закрывать его машинально, не читая.
Алерт оправдан в трёх ситуациях:
- Действие необратимо и критично - удаление данных, отмена подписки, выход без сохранения.
- Продолжение флоу технически невозможно без ответа - например, отсутствует обязательное разрешение.
- Ошибка произошла на уровне всей системы, а не отдельного поля.
Хороший алерт содержит: чёткий заголовок (что произошло или что требуется), короткое объяснение без технического жаргона, одно-два действия с понятными метками. Плохой - называет кнопку «ОК» без объяснения, что именно подтверждает пользователь, или показывает стек-трейс вместо человеческого текста.
Частая ошибка: использовать алерт для информирования. «Ваш файл успешно загружен» в виде модального окна с кнопкой «ОК» - это не алерт, это тост в чужом теле. Пользователь вынужден кликнуть, чтобы продолжить работу, хотя никакого выбора у него нет.
Toast уведомления в UI: правила и ограничения
Тосты - самый популярный паттерн для фидбека на действие. Именно поэтому их так часто используют не по назначению.
Хорошо работают для подтверждения завершённого действия: сохранение, отправка, копирование, удаление (с возможностью отмены). Плохо работают для ошибок, которые требуют исправления: тост исчезнет через три секунды, а пользователь не успеет понять, что именно пошло не так и где.
Несколько правил, которые стоит зафиксировать в гайдлайнах:
- Один тост одновременно. Если три действия завершились почти одновременно, не показывайте три сообщения подряд - пользователь не успеет их прочитать.
- Длительность 3-5 секунд для простых сообщений. Если тост содержит ссылку или кнопку «Отменить» - дайте минимум 5 секунд, лучше оставьте до явного закрытия.
- Позиция должна быть консистентной внутри продукта. Угол экрана или нижняя полоса - выберите одно и не меняйте от экрана к экрану.
- Не используйте тост для сообщений, которые пользователь может захотеть перечитать. Он исчезнет, и найти информацию будет негде.
Отдельная история - тост с кнопкой «Отменить» после удаления. Это один из лучших UX-паттернов: мягкое деструктивное действие без блокирующего алерта до, но с возможностью отмены после. Gmail использует его для архивации писем, Notion - для удаления блоков. Паттерн снижает тревогу пользователя и убирает лишний шаг подтверждения.
Бейджи в дизайне: когда точка важнее цифры
Бейдж - самый ненавязчивый способ сигнализировать об обновлении. Но и у него есть логика, которую легко нарушить.
Числовой бейдж (цифра в кружке) уместен, когда количество важно: непрочитанные сообщения, задачи в очереди, уведомления. Точка без цифры - когда важен сам факт обновления, а не количество. Например, новый раздел в настройках или непросмотренная категория.
Проблемы начинаются, когда бейджи появляются везде. Красный кружок на пяти иконках одновременно - это не «пять важных обновлений», это визуальный шум, который пользователь научится игнорировать. Через несколько дней он перестанет реагировать даже на действительно важные события.
Ещё одна ловушка - бейдж, который никогда не обнуляется. Пользователь нажал на раздел, просмотрел содержимое, но цифра осталась. Это технический баг, который ощущается как ложь интерфейса.
Вакансии для дизайнеров
Правило: Бейдж должен исчезать ровно в тот момент, когда пользователь выполнил предполагаемое действие - открыл раздел, прочитал сообщение, просмотрел обновление. Не раньше и не позже.
Паттерны уведомлений UX: что происходит, когда их слишком много
Исследования внимания показывают, что люди быстро адаптируются к повторяющимся стимулам и начинают их игнорировать. В UX это называется «баннерной слепотой» - термин пришёл из веб-рекламы, но работает и для системных сообщений.
Если продукт регулярно показывает уведомления, которые не несут ценности для пользователя, он обесценивает весь канал. Когда появится действительно важное сообщение - его тоже закроют машинально.
Признаки того, что в продукте слишком много сигналов:
- Пользователи жалуются на «шум» или «рекламу» внутри приложения
- CTR на уведомления падает со временем, хотя контент не менялся
- В сессионных записях видно, что тосты закрывают сразу, не дочитав
- На интервью пользователи говорят «я просто нажимаю ОК, не читая»
Хорошее правило для аудита: каждое уведомление должно отвечать на вопрос «что пользователь сделает по-другому, зная это?». Если ответа нет - событие не заслуживает визуальной реакции.
Типичные ошибки при проектировании системы нотификаций
Разберём конкретные случаи, которые чаще всего ломают опыт пользователя.
Показывать ошибку через тост. Тост исчезнет через три секунды. Если пользователь не успел прочитать, где именно ошибка, он продолжит заполнять форму в неправильном месте. Ошибки нужны инлайн - рядом с тем элементом, к которому они относятся.
Использовать алерт для маркетинговых сообщений. «Попробуйте нашу новую функцию!» в модальном окне с кнопкой «Закрыть» - это не алерт, это реклама, замаскированная под системное сообщение. Пользователь чувствует манипуляцию.
Показывать тост после каждого автосохранения. Если продукт сохраняет изменения каждые 30 секунд, сообщать об этом каждый раз - значит создавать фоновый шум. Автосохранение должно быть тихим: маленький статус в углу редактора, а не всплывающее сообщение.
Ставить бейдж на иконку без связи с реальным событием. Некоторые продукты добавляют бейдж на раздел «Что нового», чтобы привлечь внимание к обновлению. Если пользователь уже видел это обновление, но бейдж не исчезает - доверие к индикатору падает навсегда.
Не предусматривать состояние для нескольких одновременных сообщений. Что показать, если три разных события случились почти одновременно? Без заранее продуманной логики один компонент перекрывает другой или система показывает их цепочкой, и пользователь не понимает, на что реагировать.
Notification design best practices: что зафиксировать в дизайн-системе
Отдельные решения на уровне экрана работают до тех пор, пока продукт маленький. Когда команда растёт и добавляет новые функции, без документированной системы начинается хаос.
Минимальный набор решений, которые стоит зафиксировать:
- Классификация событий по уровням приоритета с примерами для каждого
- Какой компонент соответствует каждому уровню
- Правила позиционирования и длительности для временных сообщений
- Максимальное количество одновременно видимых элементов
- Поведение при переполнении (что происходит, если событий много)
- Правила для мобильной платформы - они могут отличаться от десктопа
Если дизайн-система уже существует, уведомления должны быть частью компонентной библиотеки с документированными вариантами состояний: информация, успех, предупреждение, ошибка. Без этого каждый дизайнер будет изобретать свой вариант красного баннера.
Когда лучше не показывать ничего
Это самое недооценённое решение в системе нотификаций. Молчание тоже является выбором.
Несколько сценариев, где лучше не добавлять визуальный сигнал:
- Фоновые процессы, которые пользователь не инициировал и которые не влияют на его текущую задачу
- Технические события, о которых пользователю не нужно знать (синхронизация, кеширование, обновление токена)
- Повторяющиеся подтверждения одного и того же действия, которое пользователь делает часто
- Маркетинговые события, которые не связаны с текущим контекстом
Хорошее приложение сообщает только тогда, когда это меняет поведение пользователя. Всё остальное - шум, который снижает доверие к тем сообщениям, которые действительно важны.
Чеклист для аудита системы уведомлений
- Каждое событие классифицировано по уровню приоритета.
- Выбор компонента обоснован - не «так принято», а «потому что требует/не требует действия».
- Алерты используются только для критических и деструктивных ситуаций.
- Тосты не используются для сообщений об ошибках, требующих исправления.
- Бейджи обнуляются в правильный момент - не раньше и не позже.
- Нет двух одновременно активных прерывающих элементов.
- Маркетинговые сообщения не замаскированы под системные.
- Для каждого уведомления есть ответ: что пользователь сделает иначе, узнав это?
- Поведение консистентно на всех экранах продукта.
- Мобильная версия учитывает ограниченное пространство и тач-взаимодействие.
FAQ
Чем тост отличается от алерта?
Тост информирует о результате действия и исчезает сам, не требуя ответа. Алерт прерывает работу и ждёт реакции пользователя. Основной критерий выбора - нужно ли пользователю принять решение прямо сейчас.
Когда бейдж лучше, чем всплывающее сообщение?
Когда событие не срочное и пользователь сам решит, когда с ним разобраться. Непрочитанные сообщения, новые задачи, обновления в фоне - всё это не требует немедленного внимания и хорошо работает как пассивный счётчик.
Можно ли использовать тост для ошибок?
Только для ошибок, которые не требуют исправления прямо сейчас и не связаны с конкретным полем или элементом. Например, «Не удалось загрузить данные, попробуйте позже» - уместно как тост. «Неверный формат email» - нет, нужно инлайн-сообщение рядом с полем.
Как понять, что уведомлений стало слишком много?
Смотрите на поведение, а не на ощущения команды. Если пользователи закрывают сообщения не читая, CTR на действия в уведомлениях падает, а на интервью слышите «я просто нажимаю ОК» - это сигнал для аудита.
Как проектировать нотификации для мобильного приложения иначе, чем для десктопа?
На мобильном меньше пространства и больше прерываний. Тосты должны быть короче и появляться снизу (там, где большой палец). Алерты занимают больше места экрана, поэтому их нужно использовать ещё осторожнее. Бейджи работают так же, но конкурируют с системными уведомлениями ОС.
Нужно ли показывать тост после каждого успешного действия?
Нет. Если результат действия виден прямо на экране - товар добавлен в корзину, файл появился в списке, галочка переключилась - дополнительное сообщение избыточно. Тост нужен тогда, когда результат не очевиден из визуального состояния интерфейса.
Итог
Система нотификаций работает хорошо, когда она незаметна: пользователь получает нужную информацию в нужный момент и не чувствует, что на него давят. Это достигается не через красивые компоненты, а через чёткую логику выбора - срочность, необходимость действия, цена прерывания.
Алерт, тост и бейдж - это не взаимозаменяемые варианты одного и того же. У каждого своя роль, и замена одного другим всегда что-то ломает. Зафиксируйте иерархию событий и правила выбора компонента в дизайн-системе - тогда каждый новый экран не будет решать этот вопрос заново.
И помните: лучшее уведомление - то, которое вы решили не показывать. Если событие не меняет поведение пользователя, оно не заслуживает его внимания.