Пустое состояние интерфейса - экран, который объясняет, почему пока нет содержимого, и предлагает безопасный следующий шаг. Чтобы спроектировать его, сначала определите причину пустоты, затем подберите точный текст и действие, отделите отсутствие данных от ошибки и проверьте, что пользователь не потеряет информацию. Такой подход делает интерфейс понятнее и помогает начать работу без лишних объяснений.
Опорные решения для пустого состояния
- Различайте первое использование, пустую выдачу и сбой: причины требуют разных подсказок.
- Назовите ситуацию прямо и без обвинений пользователя.
- Предлагайте одно уместное действие, которое можно безопасно выполнить.
- Не обещайте результат, если он зависит от внешних условий или ещё не подтверждён.
- Перед запуском проверьте, что действие не удаляет данные и не меняет настройки неожиданно.
Определите причину пустоты и доступные действия пользователя
Подход пригодится при проектировании новых экранов и пересмотре существующего UX/UI дизайна интерфейса: например, списка заказов, истории операций, результатов поиска или панели проекта. Не добавляйте декоративный пустой экран, если пользователю уже достаточно стандартного сообщения об ошибке или если на экране нельзя предложить полезное действие.
Сначала установите причину отсутствия содержимого. Один и тот же визуально пустой список может означать, что пользователь ещё не создал запись, применил слишком строгий фильтр или данные не загрузились. Для каждой ситуации определите, что пользователь может сделать дальше и какие последствия у этого действия.
Выберите тон и визуальный образ без ложных обещаний
Для работы понадобятся карта состояний экрана, актуальные сценарии пользователя, тексты кнопок и доступ к макетам и компонентам. При проектировании дизайна интерфейса сайта или дизайна мобильного приложения проверьте, как сообщение помещается на целевых размерах экрана и не конфликтует с навигацией.
Тон должен соответствовать причине: нейтральный - для отсутствия данных, поддерживающий - для первого использования, конкретный и спокойный - для сбоя. Иллюстрация может усилить сообщение, но не должна затруднять чтение или создавать впечатление, что действие уже выполнено.
Сформулируйте подсказку, ведущую к конкретному следующему шагу
Перед пошаговой работой учтите риски и ограничения:
- Не называйте ошибку отсутствием данных, если система не подтвердила успешную загрузку.
- Не делайте создание, удаление или отправку данных единственным очевидным выходом, если действие необратимо.
- Не обещайте восстановление, синхронизацию или скорый результат без подтверждённого сценария.
- Убедитесь, что действие понятно и доступно пользователям с клавиатурой и вспомогательными технологиями.
- Зафиксируйте причину. Запишите, почему экран пуст и как интерфейс узнаёт об этом. Если причина неизвестна, покажите состояние загрузки или сбоя, а не утверждайте, что данных нет.
- Определите цель пользователя. Уточните, чего человек хочет добиться на этом экране. Следующее действие должно помогать этой цели, а не продвигать случайный сценарий.
- Напишите короткое объяснение. Сначала назовите состояние, затем при необходимости поясните его. Например: "Здесь пока нет проектов. Создайте первый проект, чтобы собрать материалы в одном месте".
- Выберите одно основное действие. Подпись кнопки должна описывать результат: "Создать проект" понятнее, чем "Начать". Если действие необязательно, не маскируйте его под единственный путь.
- Добавьте безопасный запасной путь. Для сбоя предложите повторить загрузку или перейти к поддержке, если такой канал действительно существует. Не предлагайте повторную отправку формы, пока не проверено, что первая попытка не была выполнена.
- Проверьте текст в контексте. Вставьте его в реальный макет, проверьте переносы, контраст, доступность действия и соответствие терминологии продукта. При необходимости согласуйте формулировки с командой, отвечающей за услуги UX/UI дизайна или разработку пользовательского интерфейса.
Разведите первое использование, отсутствие результатов и ошибку загрузки
Проверьте сценарий по списку:
- Для первого использования объяснено, что появится после начала работы.
- Для отсутствия результатов указано, что можно изменить в запросе или фильтрах.
- Для сбоя сообщается о проблеме загрузки, а не об отсутствии данных.
- Текст соответствует фактическому состоянию системы.
- Основное действие ведёт к ожидаемому экрану или результату.
- Повторная попытка не создаёт дубликаты и не отправляет данные повторно без предупреждения.
- Подсказка остаётся понятной на узком экране и при увеличенном масштабе.
Примеры различающихся формулировок: "Создайте первую заметку" - для первого использования; "По этому запросу ничего не найдено. Измените фильтры" - для пустой выдачи; "Не удалось загрузить список. Попробуйте ещё раз" - для сбоя.
Проверьте пустой экран на рискованные действия и потерю данных
Типичные ошибки при проектировании:
- Считать все пустые экраны одним состоянием и показывать одинаковый текст.
- Предлагать создать запись, когда пользователь ожидает уже существующие данные.
- Подменять понятную подпись кнопки абстрактным призывом вроде "Продолжить".
- Предлагать повторную отправку без проверки результата предыдущей попытки.
- Использовать шутливый тон при потере связи, сбое или возможной потере данных.
- Обещать, что контент появится автоматически, если это зависит от других участников или внешней системы.
- Скрывать фильтры и настройки, из-за которых результаты могли исчезнуть.
- Добавлять действие удаления или сброса рядом с основным без ясного предупреждения.
Оцените, помогает ли сценарий начать работу без лишних объяснений
Выберите способ подачи по ситуации:
- Короткий текст и одно действие. Подходит для очевидного первого шага, например создания проекта.
- Текст и ссылка на инструкцию. Уместны, если для следующего шага нужно объяснение, но подробности не должны перегружать экран.
- Подсказка рядом с фильтрами. Подходит для пустой выдачи, когда пользователь может сразу изменить параметры поиска.
- Сообщение о сбое с повтором. Используйте, если повторная загрузка безопасна и ошибка может быть временной.
Проведите проверку на типичных сценариях: может ли человек объяснить, почему экран пуст, и понимает ли, что произойдёт после нажатия. Если для ответа требуется устное пояснение команды, уточните текст или измените действие. Оценивайте не декоративность макета, а понятность и безопасность следующего шага.
Разбор пограничных сценариев пустого интерфейса
Что показать, если пользователь впервые открыл раздел?
Кратко объясните назначение раздела и предложите начать работу конкретным действием. Не показывайте действие, которое создаёт данные автоматически, если пользователь должен сначала выбрать параметры.
Как отличить пустую выдачу от ошибки загрузки?
Показывайте пустую выдачу только после успешного поиска без совпадений. Если запрос не завершился или сервер вернул ошибку, объясните проблему загрузки и предложите безопасный следующий шаг.
Нужно ли добавлять иллюстрацию?
Только если она помогает понять ситуацию или поддерживает тон продукта. Текст и действие должны оставаться понятными без иллюстрации.
Что делать, если пользователь не может выполнить предложенное действие?
Укажите доступную альтернативу: изменить фильтр, вернуться к списку или обратиться в поддержку, если такая возможность предусмотрена. Не оставляйте человека на экране с недоступным единственным действием.
Можно ли автоматически создавать первый объект?
Только если это ожидаемое и безопасное поведение, а объект можно изменить или удалить. Иначе предложите пользователю создать его самостоятельно и заранее объясните результат.
Как сообщить о возможной потере данных?
Назовите риск до действия и ясно опишите, что именно может быть потеряно. Если действие необратимо, не делайте его основной кнопкой пустого состояния.
Автор материала о пустых состояниях интерфейса
Елена Миронова - web-freelance.ru.