Дизайн пустых состояний (Empty States) страниц сайта

Дизайн пустых состояний (Empty States) страниц сайта

Мы разрабатываем дизайн пустых состояний (empty states) для сайтов и веб-приложений: от анализа всех возможных контекстов до готовых компонентов с иллюстрациями и микротекстами. Качественный empty state не оставляет пользователя в неведении — он объясняет, почему так, и подсказывает, что делать дальше. Наш опыт показывает: проработанные пустые состояния сокращают количество обращений в поддержку на 30% — данные из недавнего B2B-проекта с дашбордом отчётов. В этой статье разберём типы, структуру, иллюстрации и процесс разработки.

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

First-run — для новых пользователей с нулевыми данными, требует onboarding-текста. User-generated — когда пользователь очистил раздел, короткий призыв. Search/filter — запрос без результатов, предлагаем изменить фильтры. Error — сбой загрузки, кнопка повтора.

Правильное проектирование empty state напрямую влияет на метрики: время до первого действия, отказ от страницы, количество тикетов. Компании, инвестирующие в этот элемент, получают до 40% снижения нагрузки на поддержку и рост пользовательской удовлетворённости.

Типы пустых состояний

Не все 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 дней. Стоимость рассчитывается индивидуально в зависимости от сложности иллюстраций и количества состояний. Чтобы получить точную оценку, свяжитесь с нами — мы проанализируем ваш проект и предложим оптимальное решение.

Опыт нашей команды — 10+ лет в веб-разработке и 50+ проектов с кастомными интерфейсами. Гарантируем качество: все компоненты проходят код-ревью и тестирование.

Свяжитесь с нами для обсуждения задачи.

Почему дизайн без токенов ломает код, и как мы это чиним

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

Как Figma превращается в инженерный инструмент

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

Auto layout — обязательное условие. Компоненты без авто-лейаута ломаются при изменении текста. Кнопка с фиксированной шириной, которая не растягивается под длинный лейбл — классическая ошибка, которую мы не допускаем. С variants в одном component set разработчик видит все состояния (hover, disabled, pressed) сразу, а не переспрашивает перед каждым блоком. Интерактивный прототип дешевле правок после разработки — мы кликаем сложные сценарии (multi-step, wizard, onboarding) до того, как писать код.

Что дают дизайн-системы и когда они избыточны

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

Как мы обеспечиваем адаптивность без сюрпризов

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

Что входит в работу (deliverables)

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

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

Как мы гарантируем качество UI

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

Ориентиры по срокам и стоимости

Сроки зависят от количества уникальных экранов и сложности компонентной базы. Стоимость рассчитывается индивидуально — пишите, и мы оценим проект за 1 рабочий день. Получите консультацию по вашему сценарию — расскажем, на каких страницах UX теряет конверсию и как это исправить.