Состояние загрузки и есть продукт

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

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

Состояние загрузки это впечатление о бренде

Каждое состояние загрузки это договор доверия. Продукт говорит пользователю: «Я работаю, я не упал, ожидание задумано». Что бы экран ни показал дальше, это становится тем, как бренд ведёт себя под давлением.

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

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

Пять архетипов состояния загрузки

Большинство команд считает «состояние загрузки» одной дизайн-задачей. На деле их пять. Каждая подходит для своего вида ожидания и проваливается по своей причине.

1. Скелетон-экран

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

Список задач в Linear показывает скелетоны в форме строк, совпадающие с итоговым списком с точностью до пикселя. Stripe Dashboard показывает скелетоны в форме карточек в блоке метрик, которые превращаются в заполненные карточки. Notion показывает заглушки в форме блоков, которые становятся настоящими блоками, когда документ загрузится. Обещание одно: форма загрузки предсказывает итоговую форму.

Используйте, когда структура известна. Пропускайте, когда макет настолько динамичен, что скелетон будет врать о том, что придёт дальше.

2. Оптимистичный UI

Отрисуйте действие пользователя сразу, до подтверждения сервера. Сверьте состояние в фоне. Если сервер согласен, интерфейс не мерцает. Если нет, интерфейс откатывается с видимым путём отмены.

Inline-создание задач в Linear это золотой стандарт. Нажали C, ввели заголовок, нажали enter, и задача уже в списке до завершения запроса. Курсор и перемещения выделения в Figma оптимистичны на протяжении всей мультиплеерной сессии. Пользователь никогда не чувствует сеть.

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

3. Потоковый частичный вывод

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

Поток токенов в Claude это самый чистый из выпущенных примеров, со сглаженным ритмом, который читается на человеческой скорости. Cursor стримит дифф токен за токеном, так что пользователь читает код, пока модель ещё не закончила писать. Vercel стримит лог деплоя вживую, так что пользователь смотрит на сборку, а не ждёт её. Материал про дизайн для задержек ИИ раскрывает более широкую стратегию работы с задержками.

Используйте, когда у результата есть естественный ритм. Пропускайте, когда фрагменты бесполезны сами по себе.

4. Прогресс как контент

Само ожидание и есть ценность. Лог деплоя, пайплайн сборки, трасса рассуждений агента. Пользователь не ждёт результата. Он читает результат.

Экран деплоя в Vercel это канонический пример. Лог деплоя и есть состояние загрузки, и самый часто показываемый экран платформы. GitHub Actions делает то же самое с пошаговым выводом запуска. Панель агента в Cursor показывает трассу рассуждений по ходу работы, так что многоминутная задача ощущается осмысленной, а не зависшей. v0 и Lovable делают это на поверхностях «промпт в приложение», где потоковая сборка и есть состояние загрузки, а превью это награда.

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

5. Брендированный спиннер

Микро-пульсация, градиент, мерцание. Момент, когда продукт зарабатывает токен личности. Мерцание кнопки оплаты у Stripe, градиентный прогресс-бар у Vercel, микро-пульс Linear на переходных ожиданиях. Ни один из них не работает в одиночку. Они едут поверх одного из первых четырёх паттернов, добавляя бренд-лоск к ожиданию, у которого уже есть структура.

Используйте, когда ожидание короткое, а поверхность ответственная. Пропускайте, когда за ним нет скелетона или потока. Брендированный спиннер без одного из первых четырёх паттернов под ним это спиннер 1996 года с hex-кодом из 2026-го.

Скелетоны почти всегда бьют спиннеры

Скелетон предсказывает форму того, что идёт. Спиннер лишь сигналит, что где-то что-то происходит. То же ожидание, два разных опыта.

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

Оптимистичный UI это чит-код

Ожидание становится невидимым, потому что действие фиксируется до начала ожидания.

Linear сделал оптимистичность везде. Создание задачи, смена статуса, смена исполнителя, добавление метки, перенос в цикл. Каждое действие пишет в локальное хранилище по намерению и сверяется после ответа сервера. Мультиплеер Figma оптимистичен на движениях курсора, выделении и большинстве правок. Notion оптимистичен на правках документа. Каждый продукт ощущается как локальный софт, потому что сеть спрятана под оптимистичным слоем.

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

Пять правил отличных состояний загрузки

Попадите в четыре из пяти, и ожидание читается как спроектированное. Попадите в три, и состояние загрузки начнёт ощущаться как запоздалая мысль.

1. Форма загрузки предсказывает итоговую форму. Скелетон-строки для строк, скелетон-карточки для карточек. Никакого скачка макета, когда контент появляется.
2. Ожидание по возможности наполнено контентом. Стримьте токены, показывайте лог, рендерите частичный результат. Читающий пользователь не ждёт.
3. Любое ожидание дольше 800 мс получает обратную связь. До 800 мс хватит чистого перехода. Дольше 800 мс пользователю нужен сигнал, что система жива, пусть даже это просто прогрессивное раскрытие: сначала структура, потом контент.
4. Оптимистичным действиям нужен видимый путь отмены. Тост, откат, понятное состояние ошибки. Оптимизм без восстановления это газлайтинг.
5. Никакого спиннера без бренд-причины. Брендированные спиннеры едут поверх одного из первых четырёх паттернов и никогда их не заменяют. Если на экране только спиннер, дизайн не закончен.

Более глубокий контекст лежит в общем разборе принципов веб-дизайна и в том, как core web vitals трактуют сдвиг макета как провал воспринимаемой производительности.

Антипаттерны, которые убивают состояния загрузки

Шесть видов провала выходят в релиз чаще, чем должны. Каждый исправим, и каждый прямо сейчас где-то работает в продакшене.

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

Блокирующая страницу модалка, которую нельзя закрыть. Модалка загрузки, которая захватывает весь экран и не даёт пользователю прокручивать, копировать или читать остальной продукт. Ожидание превращается в ситуацию с заложником.

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

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

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

Брендированные спиннеры на ожидании в 100 мс. Мерцание для ожидания, которое заканчивается раньше, чем пользователь его заметит. Чистые накладные расходы. Быстрым поверхностям нужен fade. Медленным нужна структура.

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

Аудит состояний загрузки

Шесть вопросов. Прогоните через них каждую поверхность загрузки перед следующим релизом.

1. Предсказывает ли форма загрузки итоговую форму? Скелетоны для предсказуемых макетов, строки статуса для непредсказуемых. Никакого скачка макета при появлении контента.
2. Несёт ли ожидание информацию? Скелетон, поток, лог прогресса, строка статуса. Любое ожидание дольше 800 мс, на котором ничего нет, это утечка.
3. Есть ли одно главное сообщение на одно ожидание? «Загружаем дашборд» лучше четырёх накладывающихся сигналов. Один сигнал, работу делает визуальная иерархия.
4. Соответствует ли состояние загрузки голосу бренда? Прочитайте текст загрузки рядом с заполненным экраном. Если тон меняется, состояние загрузки носит другой бренд.
5. Обратимы ли оптимистичные действия и видны ли при сбое? У каждой оптимистичной записи есть отмена, тост или откат. Никаких тихих сбоев.
6. Продал бы экран загрузки продукт незнакомцу? Если бы единственным экраном, который он увидел, было состояние загрузки, ощущался бы он как продукт, на который он подписался? Если нет, самый просматриваемый экран вашего приложения ещё и самый плохо спроектированный.

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

Выберите паттерн, затем выпускайте ожидание

Состояния загрузки это не слой полировки. Это слой бренда, слой доверия и слой воспринимаемой производительности, сжатые в экран, который пользователь видит чаще любого другого. Каждое ожидание это дизайнерский выбор, сделала команда его осознанно или нет.

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

Перестаньте относиться к состоянию загрузки как к извинению за медлительность. В совокупности это и есть продукт. Сделайте ожидание достойным их времени.

FAQ

В чём разница между скелетон-экраном и спиннером загрузки?

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

Когда использовать оптимистичный UI, а когда потоковый ответ?

Оптимистичный UI, когда работа это действие самого пользователя: добавить задачу, переключить статус, переместить карточку. Стриминг, когда работу делает сервер и у результата есть естественный ритм: генерация текста, вывод логов, пайплайн деплоя. Эти два подхода сочетаются.

Бывает ли нормально выпустить обычный спиннер?

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

Проектируйте ожидание, выпускайте продукт

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

Если вам нужна команда, которая проектирует состояния загрузки как часть продукта, а не как последний спринт перед запуском, нанимайте Brainy. Мы выпускаем продукты, где ожидание часть бренда, а воспринимаемая производительность побеждает буквальную.