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