Пустое состояние интерфейса: как различить первый запуск, отсутствие результатов и сбой

Если один и тот же список может быть пустым по разным причинам, пользователю нужен не просто аккуратный экран без данных, а точное объяснение: что произошло и что делать дальше. Для первого запуска, нулевой выдачи по фильтру и сбоя нужен не один универсальный макет, а три разных состояния с разными сообщениями, действиями и логикой появления.

Ниже разберем, как развести эти случаи так, чтобы человек не гадал, работает ли система, не начал нажимать лишние кнопки и не перепутал проблему с нормальным результатом. В конце будет условный учебный кейс с одним списком задач и тремя отдельными макетами.

Почему один пустой экран на все случаи только запутывает

Самая частая ошибка выглядит безобидно: в любой непонятной ситуации список показывает одинаковую надпись вроде «Здесь пока ничего нет». Для команды это экономия времени на макетах, а для пользователя — потеря смысла. Если экран одинаково выглядит и при новом проекте, и после слишком узкого фильтра, и при неудачной загрузке, то человек не понимает, нужно ли создавать данные, менять условия поиска или просто повторить запрос.

Пустое состояние должно сообщать статус системы, а не только украшать пустое место. Иначе интерфейс вынуждает пользователя строить догадки: запрос еще выполняется, данные закончились или что-то сломалось. Отдельная проблема возникает, когда продукт слишком рано показывает «Нет записей», а затем через несколько секунд подгружает контент. Такое поведение учит не доверять интерфейсу и провоцирует лишние обновления страницы.

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

Как развести три причины пустоты в структуре макета

Удобнее всего отличать состояния по двум вопросам: завершился ли запрос успешно и существовали ли данные в принципе. Если пользователь еще ничего не создавал, это первый запуск. Если данные могли быть, но по текущему фильтру не нашлись, это нулевая выдача. Если запрос не завершился корректно, это ошибка, и экран не должен притворяться, будто данных просто нет.

Для одного и того же списка полезно сохранить общую рамку: заголовок, место списка, панель фильтров. Меняться должны центральное сообщение, пояснение и главное действие. Тогда пользователь видит: он все еще находится в разделе «Список», но причина пустоты другая.

Есть и важное соседнее состояние, которое часто путают с пустым экраном, — загрузка. Пока система еще обрабатывает запрос, лучше показать индикатор процесса, скелетон или другой явный признак ожидания. Только после успешного завершения запроса можно честно сказать, что результатов нет. Это простое правило убирает двусмысленность между «пока не загрузилось» и «действительно пусто».

Что писать в сообщении и какое действие давать

У каждого пустого состояния есть три рабочих части: заголовок, пояснение и следующее действие. Заголовок отвечает на вопрос «что случилось», пояснение — «почему так», действие — «что мне делать сейчас». Если убрать хотя бы один слой, экран становится менее понятным. Например, кнопка без пояснения заставляет угадывать причину, а пояснение без кнопки оставляет пользователя на месте.

Для первого запуска текст должен объяснять будущее содержимое списка. Хороший вариант: «В проекте пока нет задач» и ниже «Когда вы создадите первую задачу, она появится здесь». Главная кнопка — «Создать задачу». Такой экран не только сообщает статус, но и немного обучает: пользователь узнает, что именно будет отображаться в этой зоне.

Для нулевой выдачи важно связать пустоту с текущими условиями. Вместо безличного «Ничего не найдено» полезнее написать: «По фильтру ‹Высокий приоритет› и запросу ‹договор› задач не найдено». Тогда причина не выглядит как сбой. Главное действие — «Сбросить фильтры» или «Очистить поиск». Если условий несколько, стоит дать короткий способ вернуться к более широкому запросу за одно нажатие.

Для сбоя текст должен оставаться спокойным и конкретным: «Не удалось загрузить задачи. Попробуйте еще раз». Кнопка — «Повторить». Если у пользователя были введены фильтры или запрос, лучше сохранить их после повтора, чтобы ошибка не превращалась во вторую проблему. Плохой вариант для такого случая — использовать тот же экран, что и для отсутствия результатов: человек начнет менять фильтры, хотя проблема не в них.

Учебный пример: три макета одного списка задач

Учебный пример. Представим веб-сервис управления проектами. В разделе «Задачи» есть список, строка поиска и фильтр по статусу. Мы проектируем три макета для одного и того же контейнера списка.

Исходные данные. Сценарий А: новый проект, в базе 0 задач, фильтры не выбраны. Сценарий Б: в проекте есть 12 задач, но пользователь ввел поиск «договор» и включил статус «Выполнено», при этом совпадений 0. Сценарий В: в проекте тоже есть 12 задач, но запрос к серверу завершился ошибкой, поэтому система не знает, что нужно показать.

Действия в макетах. Для сценария А в центре контейнера стоит заголовок «В проекте пока нет задач», ниже — одна строка пояснения о том, что новые задачи будут появляться здесь, и кнопка «Создать задачу». Для сценария Б в том же месте появляется заголовок «Ничего не найдено», ниже — уточнение «По запросу ‹договор› и статусу ‹Выполнено›», а основной CTA — «Сбросить фильтры». Для сценария В заголовок меняется на «Не удалось загрузить задачи», под ним — короткое пояснение без технических подробностей и кнопка «Повторить».

Проверяемый результат. У трех экранов разный смысл и разное действие: создать, расширить поиск, повторить запрос. Проверка простая: если закрыть названия сценариев и показать макеты коллеге, он должен по одному экрану понять причину пустоты и следующий шаг без устных пояснений. Дополнительно проверяем логику данных: при 12 существующих задачах экран первого запуска уже не должен появляться; при ошибке загрузки нельзя показывать текст, который утверждает, что задач нет; при нулевой выдаче сообщение появляется только после успешного завершения запроса.

Практический результат для работы. После такого разделения дизайнер и разработчик получают не абстрактное «пустое состояние списка», а понятную матрицу из трех условий. Это снижает риск, что в реализации ошибка будет замаскирована под «пустой список», а пользователь начнет лечить не ту проблему.

Как проверить сценарии до передачи в разработку

Лучше всего проверять пустые состояния не по красоте, а по переходам между ними. Для каждого экрана стоит описать три вещи: условие входа, действие пользователя и ожидаемый следующий экран. Например, после создания первой задачи экран первого запуска исчезает и уступает место обычному списку. После нажатия «Сбросить фильтры» в сценарии нулевой выдачи должен открыться либо непустой список, либо более честное состояние, если данных действительно нет. После «Повторить» в сценарии ошибки пользователь должен увидеть либо список, либо то же сообщение об ошибке, но не экран первого запуска.

Полезно составить маленькую таблицу сценариев прямо в макете или в спецификации:

1. Новый раздел без данных, без фильтров — показываем первый запуск.
2. Данные есть, но текущий поиск вернул 0 — показываем отсутствие результатов.
3. Запрос завершился ошибкой — показываем сбой.
4. Запрос еще выполняется — не показываем ни один из трех пустых экранов, а используем состояние загрузки.

Отдельно проверьте пограничные случаи. Например, что произойдет, если список был заполнен, а затем пользователь удалил все элементы сам: это уже не обязательно «первый запуск», даже если в разделе снова ноль данных. Или что делать, если сеть пропала после уже успешной загрузки: оставлять старые данные на фоне и показывать локальную ошибку сверху, либо заменять весь контейнер. Ответ зависит от задачи продукта, но это решение должно быть осознанным, а не случайным.

Если вы хотите потренировать такие сценарии в обучении, полезно смотреть, есть ли в программе не только Figma, но и практика по пользовательским сценариям, исследованиям и анимации состояний интерфейса. По официальной странице курса Contented «Профессия UX/UI-дизайнер» в программе есть блоки про интервью, коридорные тесты, CJM, базовые метрики и анимацию состояний интерфейса. Для темы пустых состояний это уместно: хороший макет здесь рождается не из декоративной иллюстрации, а из сценария, текста и проверки переходов.