Паттерны пустых состояний: как помочь пользователю сделать следующий шаг

Пустое состояние должно объяснять, почему нет содержимого, и предлагать полезный следующий шаг. В новом проекте нужен способ создать первый файл; при поиске без совпадений — изменить запрос; после сбоя запроса — восстановить работу. Если во всех трёх случаях написать «Здесь ничего нет», пользователю придётся самому выяснять причину.

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

Ниже разобраны пустые состояния в файловых разделах, поиске, дашбордах и общих рабочих пространствах: от сообщения и действия восстановления до логики состояний для передачи в разработку. Эти рекомендации дополняют материалы о дизайне панели навигации (на английском) и сценариях подтверждения в дизайне всплывающих окон.

Начните с задачи пользователя

Прежде чем выбирать иконку или писать сообщение, определите, что человек пытался сделать. «Нет файлов» может означать, что команда ещё не создала ни одного файла, фильтр скрыл все файлы, импорт продолжается или у пользователя нет доступа. Этим состояниям нужны разные объяснения и действия.

Сформулируйте состояние коротко:

«В этом проекте пока нет файлов. Участник с правом редактирования проекта может создать первый файл».

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

Перед проектированием компонента составьте короткую запись о состоянии:

Эта запись пригодится при передаче в разработку: она не позволит визуальному решению сообщать то, что продукт не может подтвердить.

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

Первое использование

Коллекция действительно новая. В одном предложении объясните её назначение и предложите минимальное действие, которое принесёт пользу. Например, на доске проекта можно написать «Фиксируйте здесь решения и ответственных» и показать кнопку «Создать доску». Не заставляйте человека читать длинное руководство, прежде чем он попробует функцию. Если полезен шаблон, предложите его как дополнительный вариант, а не единственный путь.

Нет результатов

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

Всё выполнено или содержимое намеренно отсутствует

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

Ограничение доступа или ошибка

Интерфейс не может получить ожидаемые данные либо текущему пользователю нельзя их просматривать. Разделяйте эти причины. После сбоя запроса можно предложить «Повторить попытку»; при подтверждённом ограничении прав — «Запросить доступ», если продукт поддерживает такой путь. Сохраняйте запрос и введённые данные. Если продукт не вправе раскрывать даже существование ресурса, используйте согласованное нейтральное сообщение, не подтверждая его название или содержимое.

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

Сформулируйте одно понятное действие восстановления

Основное действие должно называться глаголом, понятным в данном контексте: «Создать проект», «Сбросить фильтры», «Повторить попытку», «Запросить доступ» или «Импортировать файлы». Разместите его рядом с объяснением и после выполнения сохраняйте текущий контекст страницы. Если кнопка открывает другой сценарий, обозначьте это в названии, а не прячьте за словом «Продолжить».

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

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

Сохраняйте контекст поиска и фильтров

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

Когда действует несколько фильтров, точно покажите, что изменит действие восстановления. Если отключение фильтра «Архивные» действительно вернёт нужные результаты, «Убрать фильтр „Архивные“» понятнее, чем «Сбросить». Если приложение не знает, какой фильтр привёл к пустой выборке, дайте возможность отключать фильтры по одному или сбросить все. Не обещайте, что конкретное изменение вернёт результаты, без проверки. Оставьте видимым название сохранённого представления, чтобы «нет результатов в этом представлении» не путалось с «в рабочем пространстве нет элементов».

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

Отдельно объясняйте ограничения доступа

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

Тот же принцип действует в файловых разделах и инструментах совместной работы. Общая папка может выглядеть пустой для одного участника и содержать файлы для другого. Спроектируйте компонент так, чтобы действия зависели от роли, но структура страницы не менялась. В области загрузки файлов укажите реальные ограничения и путь восстановления; смежные примеры есть в материале о дизайне интерфейса загрузки файлов (на английском).

Проверьте компонент на реальном содержимом

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

Компонент должен учитывать и частичный результат. В списке уже могут отображаться карточки, хотя один запрос завершился ошибкой; первая страница может оставаться пустой, пока в фоне продолжается импорт. В таких случаях показывайте локальный статус возле затронутой области, а не заменяйте всю страницу пустой панелью. Сохраните успешно загруженное содержимое и объясните, что ещё меняется.

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

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

Создайте и сравните пустые состояния в Pixso →

Опишите состояния для передачи из дизайна в разработку

Зафиксируйте название состояния, условие его появления, видимый текст, действие, событие аналитики и поведение при возврате. Обычно достаточно простой таблицы:

При обновлении результатов поиска на той же странице делайте сообщение о результате доступным вспомогательным технологиям, не уводя фокус с поля поиска. Короткое сообщение вроде «По запросу „счёт“ ничего не найдено» можно передать подходящим механизмом статуса. Если же объявить весь блок результатов динамической областью live region, сообщения могут повторяться. Перемещайте фокус лишь при действиях, которые действительно меняют контекст, например при открытии диалогового окна. Запишите это поведение рядом с сообщением и названием действия. Различие объясняет руководство W3C по сообщениям о состоянии (на английском).

Проверьте сообщения в реалистичных сценариях

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

Проверьте пограничные случаи, которые легко упустить:

1. Повторный запрос успешен, но на странице осталось старое сообщение об ошибке.
2. Поисковый запрос содержит символы, которые экранируются или обрезаются.
3. Переведённое название действия занимает три строки и меняет ширину кнопки.
4. Пользователь теряет право доступа, пока пустое состояние открыто.
5. Коллекция пуста, потому что импорт ещё продолжается.
6. Действие недоступно участнику с правом только на чтение.

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

Испытайте компонент в трёх проблемных ситуациях

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

Дополнительные материалы

• W3C: сообщения о состоянии — Understanding Status Messages (на английском)
• W3C: рекомендации по доступности веб-контента WCAG 2.2 (на английском)
• MDN: доступное имя — Accessible name (на английском)