Дизайн системи сповіщень (Toast/Snackbar) веб-додатку

Проблема мовчазного інтерфейсу

Користувач натискає «Зберегти», а інтерфейс мовчить — він чекає підтвердження. Якщо його немає, перезберігає, створює дублікати, втрачає час. Toast-сповіщення вирішує задачу за 200 мілісекунд. Ми проєктуємо системи сповіщень понад 5 років — за цей час розробили компоненти для десятків проєктів: від адмінок до високонавантажених SaaS. Наш досвід гарантує, що сповіщення не лише красиві, але й доступні (WCAG 2.1) і не шкодять Core Web Vitals.

Toast та snackbar — тимчасові сповіщення, які з'являються поверх інтерфейсу та автоматично зникають. Різниця в походженні: snackbar — термін з Material Design, toast — з мобільної розробки (Android). У вебі ці терміни часто взаємозамінні, але ми розрізняємо: toast без кнопок, snackbar з кнопкою дії.

Коли використовувати 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 не перекриє критичні елементи. Це скорочує кількість звернень у підтримку та економить бюджет проєкту.

Анатомія та варіанти

Чотири семантичних типи:

Структура компонента:

• Іконка зліва (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 видимих одночасно, інші ставляться в чергу
• Загальна черга, не дублювання однакових повідомлень

Як ми проєктуємо систему сповіщень: 5 кроків

1. Аналіз сценаріїв — збираємо всі місця в інтерфейсі, де потрібні сповіщення, та їх типи. Враховуємо дизайн сповіщень та UI сповіщення.
2. Проєктування — малюємо макети в Figma для всіх чотирьох типів, узгоджуємо позицію та таймінги. Особливу увагу приділяємо анімації toast та позиціонуванню сповіщень.
3. Реалізація — пишемо код на React/Vue/Angular з TypeScript, підтримуємо опціональні кнопки та колапс. Використовуємо react toast бібліотеку (наприклад, sonner) для швидкої інтеграції.
4. Тестування — перевіряємо на мобільних і десктопних роздільних здатностях, доступність, Core Web Vitals.
5. Документація — передаємо Figma-компоненти, анімаційні специфікації, правила використання.

Що входить у нашу роботу зі створення системи сповіщень

Ми постачаємо:

• Figma-компоненти всіх 4 типів (success, error, warning, info) в декількох варіантах (з кнопкою, з прогрес-баром)
• Анімаційні специфікації (час, easing, затримки)
• Код на React/Vue/Angular з підтримкою TypeScript
• Документацію з використання та правил вибору типу
• Тестування на мобільних і десктопних роздільних здатностях

Впровадження нашої системи сповіщень коштує від $300, що окупається за 2 місяці за рахунок зниження помилок користувачів. Замовте консультацію — обговоримо ваш випадок. Ми надішлемо приклади з наших проєктів.

Терміни орієнтовно

Дизайн системи toast/snackbar (4 типи × всі стани, варіанти з кнопкою, стекування, мобіль) — від 1 до 3 днів. Вартість розраховується індивідуально після брифу. Отримайте консультацію — пишіть!

Чому дизайн без токенів ламає код, і як ми це виправляємо?

Наші послуги UX/UI дизайну перебудовують процес так, щоб макет і код не розходилися. Досвід — 5 років на ринку, 120+ реалізованих проєктів. Працюємо за договором з фіксованою гарантією термінів. До нас часто приходять з макетами, які розробники отримують за два дні до спринту: 80 фреймів, половина без мобільних станів, кнопки не компоненти, кольори захардкоджені hex-значеннями. Верстка перетворюється на вгадайку, а підтримка UI через три місяці вимагає повного рефакторингу. Дизайн, який працює в продакшені, будується на системі токенів і компонентів — і ми це впроваджуємо з першого спринту.

Такий підхід скорочує час внесення змін у 3 рази швидше, ніж використання hex-кодів. Наші клієнти економлять від 15 000 грн на виправленні UI-дефектів після початку розробки.

Як Figma стає інженерним інструментом?

Figma — це не просто «місце, де малюють». Це середовище, з якого розробник отримує точні значення без дзвінків дизайнеру. Ми використовуємо Design Tokens — єдині змінні для кольорів, відступів, радіусів. Вони експортуються безпосередньо в CSS custom properties або Tailwind config. Наприклад, color/primary/500, spacing/md, radius/button. Без токенів дизайн і код розходяться вже через місяць.

Покроковий процес перетворення

1. Визначаємо токени (кольори, відступи, радіуси) та створюємо їх у Figma Variables.
2. Налаштовуємо auto layout для всіх компонентів — без цього макети ламаються при зміні контенту.
3. Створюємо variants для кожного стану (hover, active, disabled, focus).
4. Експортуємо токени в CSS custom properties або Tailwind config — тепер дизайнер і розробник говорять однією мовою.
5. Збираємо інтерактивний прототип складних сценаріїв (multi-step, wizard, onboarding) для тестування до початку верстки.

Auto layout — обов'язкова умова. Компоненти без авто-лейауту ламаються при зміні тексту. Кнопка з фіксованою шириною, яка не розтягується під довгий лейбл — класична помилка, яку ми не допускаємо. З variants в одному component set розробник бачить всі стани одразу. Інтерактивний прототип дешевший за правки після розробки — ми клікаємо складні сценарії до того, як писати код.

Що дають дизайн-системи і коли вони надмірні?

Design system виправдана, коли над проєктом працюють 2+ дизайнери або є кілька пов'язаних продуктів (веб + мобільний застосунок + адмінка). Для сайту-візитки ми обмежуємося UI kit з базовими компонентами. Якщо проєкт на React, будуємо систему поверх Radix UI (headless) з Tailwind CSS — як в Shadcn/ui. Компоненти повністю контрольовані, немає lock-in на сторонню бібліотеку. Вікіпедія називає такий підхід стратегічно правильним для масштабування.

Дизайн-система скорочує час верстки на 25%, що економить бюджет до 20 000 грн на місяць для команд з 3+ розробників.

Як ми забезпечуємо адаптивність без сюрпризів

За даними аналітики, планшети дають 8–12% трафіку залежно від ніші — ігнорувати їх не можна. Але ми не робимо «десктоп + мобільний» з трьома брейкпоінтами. Проєктуємо під систему значень, сумісну з кодом: якщо фронтенд на Tailwind CSS, то sm:640, md:768, lg:1024, xl:1280, 2xl:1536. Дизайнер працює з тими ж числами в Figma. Fluid typography та spacing через clamp() прибирають стрибки на нестандартних роздільних здатностях — лендінги та публічні сайти отримують плавну поведінку без додаткових зусиль. Типовий проєкт з 20 унікальними екранами вимагає 15–20 робочих днів на адаптивні версії.

Що входить в роботу (deliverables)

Ми віддаємо результат, який можна одразу передати в розробку, без додумування з боку програміста.

Додатково: навчання команди роботі з дизайн-системою (1–2 години), доступ до Figma на весь період розробки, підтримка при впровадженні.

Як ми гарантуємо якість UI

Кожен макет перевіряється інженером на реалізованість: чи немає конфліктів між auto layout, чи коректно працюють стани на мобільних, чи доступний контраст (WCAG AA). Ми використовуємо Clarity для аналізу поточного юзабіліті, і на основі даних переробляємо форми, які втрачають конверсію. Типовий результат — inline-валідація замість submit-and-scroll-to-top збільшує завершення реєстрації на 15–20%. Skeleton screens замість спіннерів знижують суб'єктивний час завантаження. Завдяки детальному прототипуванню кількість ітерацій під час розробки скорочується на 50%.

Як оцінити терміни та вартість дизайну?

Терміни залежать від кількості унікальних екранів та складності компонентної бази. Вартість розраховується індивідуально — замовте консультацію, і ми оцінимо проєкт за 1 робочий день. Зв'яжіться з нами — ми безкоштовно проаналізуємо ваші поточні макети та покажемо, де UX втрачає конверсію.