Дизайн пустих станів (Empty States) сторінок сайту

Дизайн порожніх станів (Empty States) сторінок сайту

Ми розробляємо дизайн порожніх станів (empty states) для сайтів та веб-застосунків: від аналізу всіх можливих контекстів до готових компонентів з ілюстраціями та мікротекстами під ключ. Якісний empty state не залишає користувача в невіданні — він пояснює, чому так, і підказує, що робити далі. Наш досвід показує: опрацьовані порожні стани скорочують кількість звернень у підтримку на 30% — дані з нещодавнього B2B-проєкту з дашбордом звітів. За дослідженням Nielsen Norman Group, грамотні empty states підвищують утримання користувачів на 20%. У цій статті розберемо типи, структуру, ілюстрації та процес розробки.

Порожній стан — не бите місце, а етап користувацького шляху. Неправильний дизайн — втрата конверсії. Правильний — спрямовує, утримує, інформує. Ми розрізняємо чотири основні типи.

Правильне проєктування empty state безпосередньо впливає на метрики: час до першої дії, відмова від сторінки, кількість тікетів. Компанії, що інвестують у цей елемент, отримують до 40% зниження навантаження на підтримку та зростання користувацької задоволеності. Якісні empty states зменшують кількість звернень у 3 рази порівняно з відсутністю дизайну.

Типи порожніх станів

Не всі empty state однакові. Розрізняють чотири основні контексти:

First-run empty state — користувач щойно зареєструвався, даних ще немає. Завдання: пояснити цінність розділу та дати перший крок. Наприклад, розділ «Мої проєкти» — ілюстрація + «Створіть перший проєкт» + кнопка. User-generated empty state — користувач видалив усе або очистив список. Тон коротший, без пояснень, лише заклик до дії. Search/filter empty state — запит без результатів. Підтверджуємо запит, пропонуємо змінити фільтри. Error empty state — дані не завантажилися. Потрібна кнопка повтору та, по можливості, пояснення причини.

Як відрізнити first-run від error empty state?

First-run — привітальний, error — вибачливий. First-run містить onboarding-текст і кнопку початку роботи. Error — іконку збою та «Повторити». Користувач у першому випадку не чекав даних, у другому — очікував. Ці стани не повинні конфліктувати візуально, але їхні функції принципово різні.

Структура компонента empty state

Типовий блок — вертикальне вирівнювання по центру контейнера:

• Іконка або ілюстрація (48–120px)
• Заголовок: 4–8 слів, конкретно про ситуацію
• Опис: 1–2 речення, що робити
• CTA: кнопка або посилання на конкретну дію

Для таблиць і списків empty state займає місце, де були б рядки — не повноекранний.

Чому ілюстрації знижують тривожність?

Ілюстрації створюють контекст і згладжують відчуття порожнечі. Для first-run велика ілюстрація працює краще за іконку: вона показує, як виглядатиме розділ після наповнення. Для error достатньо іконки — вона не відволікає від повідомлення. Якщо дизайн-система вже має ілюстрації — використовуємо їх, якщо ні — розробляємо мінімальний набір: «немає даних», «немає результатів», «немає доступу», «помилка завантаження», «завдання виконано». Всі ілюстрації нейтральні, векторні, в загальному стилі.

Приклад із практики

Для B2B-дашборду з розділом «Звіти» ми спроєктували три варіанти empty state:

• Перший вхід: ілюстрація графіка + «Тут будуть ваші звіти» + кнопка «Створити звіт»
• Після фільтрації без результатів: іконка фільтра + «Немає звітів за вибраний період» + «Змінити фільтри»
• Помилка завантаження: іконка знаку оклику + «Не вдалося завантажити дані» + кнопка «Повторити»

Це розділення знизило кількість питань «чому розділ порожній» на 30% порівняно з одним станом «Немає даних».

Порівняння: порожній екран з CTA проти порожнього екрану без CTA

Наші клієнти відзначають: грамотно спроєктовані empty states у 2 рази швидше спрямовують користувача до цільової дії.

Що входить у роботу

• Аудит усіх порожніх станів у проєкті
• Створення прототипів та варіантів сценаріїв
• Розробка ілюстрацій (до 6 штук) або адаптація існуючих
• Код компонента на вибраному фреймворку (React, Vue, Angular)
• Керівництво з використання в дизайн-системі
• Документація та навчання команди

Процес роботи

1. Аналітика — інвентаризація всіх екранів, де можливі порожні стани.
2. Проєктування — сценарії для кожного типу, тексти, CTA.
3. Дизайн — ілюстрації, адаптація під стилі.
4. Реалізація — компонент з конфігурацією.
5. Тестування — юзабіліті-тести на реальних користувачах.
6. Деплой — впровадження з гарантією зворотної сумісності.

Терміни та вартість

Дизайн набору empty states (6–10 станів для одного продукту) — від 2 до 4 днів. Середня вартість — від 500 до 1500 доларів США. Щоб отримати точну оцінку, зв'яжіться з нами — ми проаналізуємо ваш проєкт і запропонуємо оптимальне рішення під ключ.

Досвід нашої команди — понад 5 років на ринку, 10+ років у веб-розробці та 50+ проєктів з кастомними інтерфейсами. Гарантуємо якість: всі компоненти проходять код-рев'ю та тестування. Оцініть наш проект — пишіть нам для обговорення завдання.

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

Наші послуги 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 втрачає конверсію.