Материал статьи
«Ничего не найдено» — плохой универсальный ответ. За ним могут скрываться новый аккаунт, слишком строгий фильтр или сломавшийся запрос. Пользователю нужны разные подсказки: создать первый объект, изменить условия поиска или дождаться восстановления сервиса. С этого различия и начинается проектирование пустых состояний.
Пустой лоток и открытая папка: первое использование рабочего раздела.
Оглавление
- У пустого экрана должна быть причина
- Первый запуск: объяснить ближайшее действие
- Ничего не нашлось: сохранить условия поиска
- Сбой: не заставлять пользователя чинить систему
- Как составить карту состояний до рисования макетов
- Разберём пустой список заказов по шагам
- Текст, кнопки и иллюстрация: распределяем работу
- Переходы, медленная сеть и доступность
- Что измерять после запуска
- Как принять эти экраны у команды
- По теме
У пустого экрана должна быть причина
Представьте личный кабинет поставщика. В разделе документов нет ни одной строки. Поставщик только зарегистрировался? Бухгалтер ещё не загрузил акт? Выбран прошлый год? У сотрудника нет прав? Сервер не ответил? На макете все пять ситуаций выглядят одинаково, в работе — совершенно по-разному.
Поэтому задание «нарисовать заглушку» лучше заменить небольшим перечнем состояний. Для каждого укажите, что система знает достоверно и что человек может сделать. Если причина неизвестна, не пишите «У вас пока нет документов»: это уже утверждение о данных. При сбое корректнее сообщить, что список не удалось загрузить.
Отдельно проверьте загрузку. Пока запрос выполняется, экран ещё не пустой. Кратковременное сообщение об отсутствии заказов, которое затем сменяется заказами, заставляет сомневаться в интерфейсе. Здесь нужен индикатор ожидания, а окончательный ответ — после завершения запроса.
Первый запуск: объяснить ближайшее действие
В новом проекте действительно ничего нет. Это подходящее место для короткого объяснения: «Здесь будут счета, которые вы выставите клиентам». Рядом — действие «Создать счёт». Так человек узнаёт назначение раздела и может сразу проверить его в работе.
Не стоит превращать этот экран в рекламный буклет. Пользователь уже пришёл в продукт; сейчас ему важнее понять, какие данные понадобятся для первого счёта. Если нужны реквизиты компании, подскажите это заранее. Если счёт сначала сохраняется как черновик, тоже скажите: страх случайно отправить документ может остановить новичка.
Демонстрационные данные помогают, когда без примера трудно понять устройство раздела. Но пример должен явно отличаться от настоящей записи. Чужое имя и правдоподобная сумма без пометки могут выглядеть как утечка данных. Хороший демонстрационный объект можно открыть, изучить и убрать; он не попадает в финансовые отчёты.
Ничего не нашлось: сохранить условия поиска
У покупателя, который искал настольную лампу, другая проблема. Он уже совершил действие и не получил результата. Сбрасывать запрос или все фильтры без спроса нельзя: человек потеряет контекст и не поймёт, какое ограничение оказалось лишним.
Покажите введённый запрос и активные фильтры. Затем предложите обратимые изменения. Например: «В выбранном магазине нет ламп с таким цоколем. Посмотреть наличие во всех магазинах». Это полезнее кнопки «В каталог», которая отправляет в начало длинного пути.
Если неизвестно, какой именно фильтр исключил товары, не выдумывайте объяснение. Можно предложить снять последнее условие или показать результаты без фильтров. Альтернативные товары стоит отделять от точных совпадений: иначе поиск формально перестаёт быть пустым, но начинает обманывать ожидания.
Для административных интерфейсов важно ещё одно различие: отсутствие объектов и отсутствие доступа. Сообщение о правах должно содержать доступный способ их запросить, но не раскрывать названия закрытых документов и другие лишние сведения.
Три причины пустого экрана: начало работы, отсутствие совпадений и сбой.
Сбой: не заставлять пользователя чинить систему
«Попробуйте позже» оставляет человека с двумя вопросами: сколько ждать и не пропала ли его работа. Если форма уже заполнена, сохраните значения на экране, насколько это допускает безопасность. Если операция могла выполниться, сначала проверьте её состояние: повторная отправка иногда создаёт дубль.
Кнопка «Повторить загрузку» уместна для чтения списка. Для создания заказа она требует более осторожной логики. Пользователь не должен выбирать между потерей заказа и риском оформить его дважды. Такое поведение обсуждают с разработчиком, а не решают одним удачным текстом.
Слишком весёлая иллюстрация здесь редко помогает. Человек потерял доступ к рабочим документам; ему нужны понятное описание ограничения, безопасное действие и канал связи, если проблема затянулась. Не обещайте восстановление через минуту, если система этого не знает.
Как составить карту состояний до рисования макетов
Начните не со списка красивых заглушек, а с одного рабочего раздела. Например, клиент видит таблицу актов и выбирает организацию, период, статус подписания. Для этого раздела достаточно выписать условия появления каждого экрана. Так обнаружится, что «актов нет» — лишь одна ветка, а остальные требуют других данных и действий.
Условную карту можно оформить следующим образом. Это пример задания для команды, а не обязательный перечень состояний любого кабинета.
Что известно системе | Что показываем | Какое действие доступно |
|---|---|---|
Запрос ещё выполняется | Загрузка списка актов | Можно вернуться в другой раздел |
Организация выбрана, ответ получен, документов за всё время нет | Акты появятся после завершения первой услуги | Посмотреть условия получения документов |
Документы есть, выбранный период пуст | За этот период актов нет | Изменить период, не меняя организацию |
Список не получен из-за сбоя | Не удалось загрузить акты | Повторить чтение списка |
Право на документы не предоставлено | Для просмотра требуется доступ | Отправить запрос администратору, если это предусмотрено |
Документ готовится в фоновой операции | Акт формируется | Посмотреть состояние операции |
Для каждой строки нужен ответственный за достоверность. Дизайнер определяет подачу, но не может решить, как сервер отличает отсутствие документов от отсутствия прав. Если API во всех случаях возвращает пустой массив, макет с пятью сообщениями не получится реализовать честно. Придётся уточнить контракт ответа или сократить количество обещаний интерфейса.
Особенно полезна колонка «Что должно произойти дальше». После смены периода открывается новый список; после запроса доступа появляется подтверждение; после восстановления соединения можно повторить загрузку. Если следующий шаг не описан, команда нередко делает кнопку, которая визуально реагирует, но возвращает человека на ту же заглушку.
Добавьте к карте приоритеты. Если пользователь не авторизован, сообщение о выбранном фильтре может быть преждевременным: сначала нужно восстановить сессию. Если запрос завершился ошибкой, нулевое количество записей не считается достоверным. Приоритет состояний лучше зафиксировать словами до разработки, чем исправлять противоречивые условия в разных компонентах.
Что делать с частично загруженными данными
Не каждый сбой требует закрыть весь экран. В кабинете может загрузиться список заказов, но не подтянуться предварительная стоимость доставки. Тогда разумнее сохранить доступ к заказам и отдельно обозначить недоступный расчёт. Полноэкранная ошибка лишает человека возможности выполнить действия, которые всё ещё работают.
Однако частичные данные нужно обозначать. Если итоговый отчёт собран не по всем филиалам, нельзя показывать общую сумму как окончательную. Подпись «Данные по двум филиалам ещё загружаются» полезнее маленького индикатора без объяснения. Кнопка экспорта должна либо учитывать неполноту, либо явно сообщать, какие сведения попадут в файл.
Разберём пустой список заказов по шагам
Рассмотрим вымышленный сервис заказа печати. Клиент зарегистрировался, открыл кабинет и увидел раздел «Заказы». Простое решение — большая картинка и кнопка «Заказать». Но первый заказ требует выбрать изделие, прикрепить макет и указать тираж. Человеку, который ещё не подготовил файл, такая кнопка кажется началом необратимого оформления.
Более точный вариант текста: «Здесь будут ваши заказы на печать. Начните с выбора изделия — макет можно добавить на следующем шаге». Кнопка называется «Выбрать изделие». Обещание про макет допустимо только в том случае, если это действительно предусмотрено процессом. Когда файл обязателен сразу, лучше заранее назвать подходящий формат и дать ссылку на требования.
Теперь клиент сделал заказ, но через неделю вернулся по сохранённой ссылке с фильтром «В работе». Заказ уже выдан, поэтому таблица пуста. Прежняя фраза о первом заказе становится неверной. Здесь достаточно: «Сейчас нет заказов в работе», затем действие «Показать завершённые». Оно должно изменить статус, а не сбросить заодно период, организацию и остальные настройки.
Третий вариант: у клиента две организации, и заказ оформлен от другой. Не стоит автоматически переключать организацию ради наполнения экрана. Документы, цены и полномочия могут различаться. Если у человека есть доступ к обеим организациям, интерфейс может предложить проверить переключатель; раскрывать данные недоступной организации нельзя.
Четвёртый вариант: оплату приняли, но создание заказа ещё продолжается. Сообщение «Заказов пока нет» способно подтолкнуть к повторной покупке. Нужен отдельный статус ожидаемой операции: обращение получено, результат появится после обработки. Текст не должен обещать точное время без технического основания; полезнее показать идентификатор обращения и способ проверить его судьбу.
Наконец, человек отменил единственный черновик. Это уже не знакомство с сервисом. Можно подтвердить удаление и вернуть список в пустое состояние. Если отмена доступна, предложите её рядом с подтверждением. Если удаление окончательное, не рисуйте кнопку «Вернуть» только ради привычного дизайна: за ней должна стоять реальная операция восстановления.
Так один раздел получает несколько коротких, но осмысленных экранов. Они отличаются не длиной текста и не иллюстрациями, а пониманием ситуации. Проверять их удобнее в контексте полного маршрута: от регистрации до завершения заказа и повторного обращения.
Первая карточка на доске нового проекта.
Текст, кнопки и иллюстрация: распределяем работу
Хороший заголовок сообщает состояние: «Нет заказов за выбранный период», «Пока нет сохранённых товаров», «Не удалось получить список». Пояснение отвечает на вопрос, который заголовок оставил открытым. Кнопка выполняет ближайшее полезное действие. Если все три элемента повторяют «Начните пользоваться сервисом», экран занимает место, но не помогает.
Проверять текст можно простой редакторской процедурой. Закройте иллюстрацию и прочитайте оставшееся вслух. Можно ли понять причину и следующий шаг? Затем оставьте только заголовок и кнопку. Не получится ли, что «Нет доступа» соседствует с «Создать документ», хотя создание тоже запрещено? Такие противоречия обычно заметнее без оформления.
На пустом экране необязательно должна быть основная кнопка. Если документы появляются только после действия бухгалтера, клиент сам не может их создать. Подходящее решение — объяснить порядок появления и при необходимости дать контакт. Кнопка «Обновить» без изменения состояния превращается в бесполезный ритуал и создаёт лишние запросы.
Когда действий два, назначьте им разные роли. В первом запуске конструктора отчётов основным может быть «Создать отчёт», второстепенным — «Открыть пример». Не делайте две одинаково яркие кнопки с непонятным выбором «Начать» и «Продолжить». Человек не должен изучать терминологию продукта, чтобы выйти из пустого раздела.
Иллюстрация помогает показать назначение или смягчить визуальную пустоту, но не заменяет сообщение. Для отказа платежа, потери соединения или недоступного документа шутка может быть неуместна. У первого списка избранного допустим более спокойный дружелюбный тон; у заблокированного кабинета важнее точность. Один и тот же персонаж с воздушным шаром не решает обе задачи.
Размер картинки тоже связан с контекстом. В небольшом блоке рекомендаций она не должна отодвигать основной контент. В рабочем кабинете на телефоне заголовок, пояснение и действие должны оставаться доступными без длинного декоративного экрана. Полезная проверка: убрать иллюстрацию на узком разрешении и убедиться, что смысл и управление не потерялись.
Когда нужны примеры вместо пустоты
В сложном инструменте можно предложить отдельный учебный проект. Он позволяет изучить отчёт или канбан-доску до загрузки своих данных. Но учебный режим стоит обозначить в названии, внутри проекта и при выходе из него. Пользователь должен знать, что пример нельзя принять за собственную статистику.
Не копируйте демонстрационные записи в настоящий аккаунт незаметно. Они могут попасть в экспорт, поиск, уведомления и расчёт лимитов. Если пример становится реальным шаблоном, действие должно быть явным: «Создать свой проект по этому образцу». После этого человеку понятно, какие объекты принадлежат ему и что можно менять.
Переходы, медленная сеть и доступность
Макет показывает момент, а пользователь видит последовательность. Поэтому нужно проверить не только пустой экран, но и то, как он появляется и исчезает. На медленной сети особенно заметен плохой порядок: сначала «Ничего нет», затем индикатор, затем записи. Это три разных сообщения за одно открытие раздела, хотя состояние данных ещё ни разу не было подтверждено.
Есть и менее очевидная ошибка. Человек быстро меняет два фильтра. Ответ на первый запрос приходит позже ответа на второй и заменяет актуальный список старым пустым результатом. Здесь редактура не поможет: требуется обработка устаревших ответов. В проверке стоит отдельно воспроизвести быстрые переключения, а не только дождаться каждого фильтра по очереди.
После удаления последней строки таблица может исчезнуть вместе с кнопкой, на которой находился клавиатурный фокус. Нужно предусмотреть логичное продолжение: например, перевод к сообщению о результате или доступному действию в том же разделе. Самопроизвольный прыжок в начало страницы дезориентирует, особенно если удаление было в нижней части длинного кабинета.
Проверка со скринридером нужна для динамических изменений: видимое сообщение ещё не означает, что пользователь вспомогательной технологии узнает о нём. Способ объявления выбирают с учётом важности и частоты события. Не стоит превращать каждую мелкую смену количества результатов в навязчивое прерывание; но и значимая ошибка не должна оставаться без обратной связи.
Не прячьте причину пустоты только в изображении. Текст должен быть обычным текстом интерфейса, доступным при увеличении масштаба и в разных режимах отображения. Если рисунок декоративный, он не должен заставлять пользователя слушать длинное описание, которое повторяет соседнее сообщение. Конкретную разметку проверяют в используемом компоненте, а не предполагают по картинке макета.
Сохранённые данные и работа без соединения
Если приложение умеет показывать прежний список без сети, обозначьте его актуальность. «Показаны данные, полученные сегодня в 09:40» отличается от «Нет записей». Действия, которые требуют связи, стоит объяснить отдельно. Просмотр сохранённого заказа может работать, а изменение адреса — нет; блокировать оба сценария без необходимости неудобно.
При восстановлении сети не теряйте выбор пользователя. Если он раскрыл карточку, листал список или менял фильтр, обновление не должно каждый раз сбрасывать его в начало. Поведение зависит от приложения, но требование можно проверить обычным сценарием: открыть раздел, отключить соединение, выполнить доступное действие и вернуть сеть.
Что измерять после запуска
Количество показов пустого экрана само по себе не характеризует качество. В новом продукте первый запуск увидит почти каждый, а в истории заказов постоянного клиента такой экран может быть редкостью. Смешанные данные приведут к ложному выводу: улучшили подсказку для новичков, а оценили её по людям с проблемой доступа.
Разделяйте события по причине: первый объект, пустой фильтр, отсутствие прав, ошибка загрузки. Для каждого смотрите осмысленное продолжение. В первом случае это создание объекта, во втором — изменение условий и получение подходящего результата. Для сбоя полезно знать, восстановился ли доступ, а не просто сколько раз нажали «Повторить».
Не передавайте в аналитику названия частных документов, адреса клиентов или полный поисковый запрос без оценки необходимости и допустимости. Часто для проверки гипотезы достаточно категории состояния, раздела и технического результата. Детальные данные не становятся полезными только потому, что их легко записать.
С ростом кликов тоже нужна осторожность. Новая кнопка может привлекать внимание, но вести в тупик. Сравните не только нажатия, но и завершение следующего шага, повторные возвраты на пустой экран, обращения в поддержку по этой причине. Для небольшого числа пользователей несколько наблюдений за выполнением задачи дадут больше контекста, чем график с нестабильным процентом.
Полезно сохранять перечень обнаруженных проблем: неверная причина, неработающее действие, потерянный фильтр, недоступное сообщение. Это конкретные дефекты, которые можно исправить и перепроверить. Общая оценка «заглушка выглядит уныло» не позволяет понять, что именно мешало человеку.
Как принять эти экраны у команды
Для проверки не нужен большой сценарий исследования. Создайте новый аккаунт, выполните заведомо безрезультатный поиск, включите несколько фильтров и воспроизведите ошибку загрузки в тестовой среде. Попросите человека, который не видел макет, объяснить, что случилось и что он сделает дальше.
Если ответы расходятся с реальностью, сначала исправляйте причину и действие, а не размер картинки. Особенно внимательно проверяйте названия кнопок: «Начать» ничего не обещает, а «Добавить первый товар» обозначает конкретный шаг.
При разработке сайта или личного кабинета пустые состояния стоит включить в состав макетов и приёмочных сценариев. Иначе они появятся в последний момент — обычно в виде одного и того же «Нет данных» на всех экранах. Хорошее пустое состояние не заполняет пустоту: оно помогает из неё выйти.