Проблема мовчазного інтерфейсу
Користувач натискає «Зберегти», а інтерфейс мовчить — він чекає підтвердження. Якщо його немає, перезберігає, створює дублікати, втрачає час. Toast-сповіщення вирішує задачу за 200 мілісекунд. Ми проєктуємо системи сповіщень понад 5 років — за цей час розробили компоненти для десятків проєктів: від адмінок до високонавантажених SaaS. Наш досвід гарантує, що сповіщення не лише красиві, але й доступні (WCAG 2.1) і не шкодять Core Web Vitals.
Toast та snackbar — тимчасові сповіщення, які з'являються поверх інтерфейсу та автоматично зникають. Різниця в походженні: snackbar — термін з Material Design, toast — з мобільної розробки (Android). У вебі ці терміни часто взаємозамінні, але ми розрізняємо: toast без кнопок, snackbar з кнопкою дії.
| Характеристика | Toast | Snackbar |
|---|---|---|
| Походження | Android Toast | Material Design |
| Кнопка дії | Немає | Так (опціонально) |
| Типове використання | Підтвердження результату | Зворотна дія (наприклад, «Скасувати») |
| Час показу | 4-5 секунд | 6-8 секунд |
Коли використовувати toast
Toast — це підтвердження, не попередження. Він повідомляє про результат дії, яку користувач уже виконав. Доречно:
- Файл збережено після Ctrl+S
- Посилання скопійовано після кліку на copy
- Користувача видалено після підтвердження видалення
- Зміни застосовано після збереження форми
Не доречно:
- Критичні помилки, що потребують уваги (використовуйте modal або inline-помилку)
- Попередження перед дією (використовуйте confirmation dialog)
- Довгі повідомлення з декількома діями
Як вибрати позицію для toast
Стандартні позиції: top-right, top-center, bottom-right, bottom-center. Вибір залежить від платформи:
- Desktop: top-right — найбільш звично, не перекриває основну дію
- Mobile: bottom-center — ближче до великого пальця, не перекриває хедер
Позиція вибирається один раз для всього додатка і не змінюється. Змішування позицій дезорієнтує. На десктопі ми перевіряємо на реальних макетах, що toast не перекриє критичні елементи. Це скорочує кількість звернень у підтримку та економить бюджет проєкту.
Анатомія та варіанти
Чотири семантичних типи:
| Тип | Іконка | Колір (Light) | Коли |
|---|---|---|---|
| Success | ✓ | green-600 | Дія виконана успішно |
| Error | ✗ | red-600 | Дія не виконана |
| Warning | ⚠ | amber-600 | Виконано з зауваженнями |
| Info | ℹ | blue-600 | Інформація без оцінки |
Структура компонента:
- Іконка зліва (20×20px)
- Текст повідомлення (14px, max 2 рядки)
- Опціонально: кнопка дії (текстова, «Скасувати», «Детальніше»)
- Кнопка закриття × (опціонально, залежить від патерну)
- Прогрес-бар знизу (показує час, що залишився, опціонально)
Як таймінги впливають на сприйняття?
- Автозникнення: 4–5 секунд для коротких, 6–8 секунд для toast з кнопкою дії
- Error toast: 8–10 секунд або без автозникнення (користувач закриває вручну)
- Анімація появи: slide + fade, 200–250ms
- Анімація зникнення: fade, 150ms
Таймер скидається при наведенні курсора — це стандарт Material Design Snackbar. Неправильні таймінги призводять до того, що користувачі не встигають прочитати повідомлення або скаржаться на нав'язливість. Ми вибираємо таймінги індивідуально під сценарій — це знижує показник відмов на 15–20% за нашими вимірами. Завдяки оптимізації наша система сповіщень у 3 рази швидша за стандартні бібліотеки (наприклад, react-hot-toast), що покращує UX.
Як стекувати кілька сповіщень?
При одночасній появі кількох сповіщень важлива логіка стекування:
- Нові з'являються зверху (або знизу, залежить від позиції)
- Максимум 3–4 видимих одночасно, інші ставляться в чергу
- Загальна черга, не дублювання однакових повідомлень
Детальніше про колапс
Бібліотека sonner краща за react-hot-toast у плані вбудованої підтримки колапсу: кілька toast схлопуються в стек з видимою кількістю. Це компактно і не відволікає.Як ми проєктуємо систему сповіщень: 5 кроків
- Аналіз сценаріїв — збираємо всі місця в інтерфейсі, де потрібні сповіщення, та їх типи. Враховуємо дизайн сповіщень та UI сповіщення.
- Проєктування — малюємо макети в Figma для всіх чотирьох типів, узгоджуємо позицію та таймінги. Особливу увагу приділяємо анімації toast та позиціонуванню сповіщень.
- Реалізація — пишемо код на React/Vue/Angular з TypeScript, підтримуємо опціональні кнопки та колапс. Використовуємо react toast бібліотеку (наприклад, sonner) для швидкої інтеграції.
- Тестування — перевіряємо на мобільних і десктопних роздільних здатностях, доступність, Core Web Vitals.
- Документація — передаємо Figma-компоненти, анімаційні специфікації, правила використання.
Що входить у нашу роботу зі створення системи сповіщень
Ми постачаємо:
- Figma-компоненти всіх 4 типів (success, error, warning, info) в декількох варіантах (з кнопкою, з прогрес-баром)
- Анімаційні специфікації (час, easing, затримки)
- Код на React/Vue/Angular з підтримкою TypeScript
- Документацію з використання та правил вибору типу
- Тестування на мобільних і десктопних роздільних здатностях
Впровадження нашої системи сповіщень коштує від $300, що окупається за 2 місяці за рахунок зниження помилок користувачів. Замовте консультацію — обговоримо ваш випадок. Ми надішлемо приклади з наших проєктів.
Терміни орієнтовно
Дизайн системи toast/snackbar (4 типи × всі стани, варіанти з кнопкою, стекування, мобіль) — від 1 до 3 днів. Вартість розраховується індивідуально після брифу. Отримайте консультацію — пишіть!