Состояния загрузки: деталь, определяющая скорость продукта
Разрыв между реальной и ощущаемой скоростью
Каждый клиент, с которым я работал, рано или поздно задавал одну и ту же версию вопроса: «А можно сделать так, чтобы это ощущалось быстрее?» Обычно это происходит уже после того, как команда разработки оптимизировала запросы к базе данных, добавила кэширование, сжала изображения и сократила время ответа API до вполне приличных значений. Продукт по всем техническим меркам быстрый. И тем не менее пользователи всё равно называют его медленным. Именно в этом разрыве — между тем, что реально делает сервер, и тем, что, по мнению человека перед экраном, происходит, — и живут состояния загрузки.
Ощущаемая скорость — это не второстепенная, «мягкая» метрика. Это метрика, которая определяет, доверяет ли человек продукту, бросит ли он оформление заказа на середине, нажмёт ли кнопку дважды, потому что не был уверен, сработало ли первое нажатие. Исследования времени отклика от Nielsen Norman Group актуальны уже десятилетиями: меньше 0,1 секунды ощущается как мгновенная реакция, меньше секунды — как непрерывный поток мысли, а всё, что дольше 10 секунд, заставляет человека мысленно отключиться и заняться чем-то другим. Основная интересная работа дизайнера разворачивается как раз в этой мутной средней зоне — от 1 до 10 секунд, — потому что именно там пустой экран, замёрзшая кнопка или плохо продуманный спиннер могут превратить вполне приемлемую трёхсекундную загрузку в ощущение пятиминутного ожидания.
Я наблюдал это буквально на одной и той же кодовой базе. У команды, с которой я консультировал, страница результатов поиска возвращала данные примерно за 1,8 секунды. При обычном белом экране в это время пользователи в юзабилити-тестах называли приложение «медленным». Мы ничего не меняли в бэкенде. Мы добавили skeleton-разметку, имитирующую будущие карточки результатов, с лёгкой мерцающей анимацией. Те же 1,8 секунды. Слово «медленно» почти исчезло из обратной связи по сессиям. Ничего не стало быстрее. Просто ожидание было спроектировано.
В этом и заключается главный тезис статьи: состояния загрузки — это не техническая мелочь, которую добавляют на этапе QA. Это полноценный интерфейс, заслуживающий не меньшего внимания, чем пустые состояния, состояния ошибок и онбординг. Если вы фрилансер или агентство, презентующее дизайн-работу клиенту, это ещё и один из самых простых способов продемонстрировать ценность, которую клиент почувствует сразу — даже если не сможет объяснить, почему именно.
Почему мозг воспринимает ожидание как невыносимое — или нормальное
Чтобы хорошо проектировать состояния загрузки, полезно понимать несколько вещей о том, как люди на самом деле переживают ожидание, — потому что дизайнерские решения естественным образом вытекают из этого понимания.
Первое — неопределённость. Незаполненное время ощущается длиннее заполненного, и это вдвойне верно, когда человек не знает, сколько времени осталось и происходит ли вообще что-то. Поэтому прогресс-бар, который застрял на 40% на десять секунд, а потом резко прыгнул на 100%, ощущается хуже, чем тот, что движется равномерно, даже если общее время идентично. Мозг измеряет не длительность секундомером — он измеряет тревогу. Спиннер без всякого контекста — просто бесконечно вращающийся неопределённый кружок — это чистейшая форма такой тревожной неопределённости. Он сообщает «возможно, что-то происходит», но никогда не обещает «это закончится, и вот примерно когда».
Второе — иллюзия труда, термин из исследований воспринимаемых усилий. Люди больше доверяют результату и терпеливее его ждут, когда видят доказательства того, что ради них выполняется работа. Именно поэтому сайты поиска авиабилетов вроде Kayak показывают фейковую анимированную последовательность «поиск среди 200 авиакомпаний» вместо того, чтобы просто крутить спиннер те же три секунды: демонстрация труда делает ожидание оправданным, а не потраченным впустую. Это манипуляция, если используется, чтобы замаскировать лень (см. искусственные задержки, добавленные исключительно ради эффектной анимации загрузки), но это законный и полезный приём, если работа реально происходит, просто пользователь не может увидеть её на сервере.
Третье — концепция порога Доэрти, названного в честь исследователей IBM, обнаруживших, что продуктивность и вовлечённость резко растут, когда компьютер отвечает на действие пользователя в пределах 400 миллисекунд. Ниже этого порога взаимодействие ощущается непрерывным — ход мысли пользователя не прерывается. Выше него мозг фиксирует разрыв, и этот разрыв нужно чем-то заполнить осмысленным, иначе доверие пользователя к системе начинает разрушаться. Именно поэтому худшее из возможных состояний загрузки — это часто вообще его отсутствие: клик, который полсекунды не даёт вообще никакой обратной связи, оставляя пользователя в неведении, попал ли он по кнопке.
Четвёртое — и его дизайнеры недооценивают сильнее всего — это правило пика и конца. Люди запоминают опыт не как среднее значение всех моментов, а как пиковый момент интенсивности и финал. Если ожидание завершается чисто и приятно — контент плавно проявляется, подтверждение появляется с приятной микроанимацией, — всё предшествующее ожидание задним числом ощущается короче и приятнее, чем было на самом деле. И наоборот: если состояние загрузки заканчивается резко, со скачком верстки или вспышкой неоформленного контента, последнее впечатление пользователя окажется неприятным, и это окрасит воспоминание обо всём взаимодействии в целом, даже если сама загрузка была быстрой.
Сложите эти четыре принципа вместе — и получите вполне конкретное техническое задание: снижать неопределённость, показывать реальные доказательства работы там, где это возможно, реагировать в пределах 400 мс на любое действие пользователя и следить, чтобы завершение ожидания было плавным, а не резким. Всё остальное в этой статье — по сути, тактики на службе этих четырёх принципов.
Рабочая классификация: какое состояние загрузки для какой ситуации
«Добавить состояние загрузки» — это не единое решение, а целая категория, включающая как минимум шесть по-настоящему разных паттернов, каждый из которых подходит для разной длительности, разной предсказуемости и разной эмоциональной значимости. Если относиться к ним как к взаимозаменяемым, именно отсюда и берётся большинство неудачных решений. Спиннер, воткнутый на страницу, которой нужен skeleton, или прогресс-бар для задачи с неизвестной длительностью — оба создают трение, которого можно было бы избежать чуть иным выбором.
Мгновенная обратная связь (0–400 мс)
Это зона, где вам нужен не столько «loading-state», сколько «response-state». Кнопка должна менять вид — состояние нажатия, лёгкое уменьшение масштаба, сдвиг цвета — в тот же момент, когда палец или курсор её касается, независимо от того, завершилось ли реальное действие. Это чистое управление восприятием: вы не лжёте о состоянии системы, вы подтверждаете, что ввод получен, пока реальная обработка догоняет его. Пропуск этого шага — самая частая ошибка, которую я вижу в продуктах на ранней стадии, потому что разработчики часто реализуют состояние «успех», но полностью забывают про состояние «принято». Пользователи кликают дважды, дважды отправляют формы и заводят баг-репорты со словами «ничего не произошло», хотя на самом деле что-то происходило — просто незаметно.
Короткое ожидание (400 мс–2 с): skeleton-экраны вместо спиннеров
Это зона, в которой живёт большинство насыщенных контентом интерфейсов — загрузка ленты, отрисовка профиля, возврат результатов поиска. Инстинкт подсказывает взять спиннер. Не делайте этого. Спиннер сообщает «подождите, неизвестно чего», а skeleton-экран сообщает «сейчас появится вот такой конкретный контент, и вот его форма». Люк Вроблевски, а затем и дизайн-команда Facebook популяризировали skeleton-экраны именно потому, что они снижают ощущаемое ожидание, давая глазу структурированный ориентир вместо абстрактного знака «обработка идёт». Skeleton, повторяющий реальную разметку — контуры карточек, плейсхолдеры текстовых строк, кружки аватаров, — заранее настраивает пространственные ожидания пользователя, поэтому, когда появляется реальный контент, он ложится в уже подготовленный мозгом слот, а не вызывает резкую перекомпоновку.
Оговорка: skeleton работает, только если он достаточно похож на реальный контент, чтобы задать точные ожидания. Универсальный серый прямоугольник, используемый для абсолютно всех экранов приложения независимо от того, что там на самом деле загружается, перестаёт давать этот эффект и превращается просто в навороченный спиннер. Создание skeleton-состояний, привязанных к конкретной разметке пяти-шести ключевых экранов, требует реального дизайнерского времени, и это время стоит закладывать в план явно, а не относить к «приятным доработкам» в конце спринта.
Среднее ожидание (2–10 с): постепенное раскрытие и определённый прогресс
После двух секунд статичный skeleton начинает ощущаться нечестным — пользователь замечает, что ничего на самом деле не меняется, и тревога неопределённости возвращается. Здесь работают две техники: постепенная загрузка (сразу отрисовать то, что уже готово, а остальное подгружать по мере поступления) и определённые индикаторы прогресса (реальный процент или счётчик шагов, а не расплывчатая пульсирующая полоса).
Постепенную загрузку используют реже, чем следовало бы, потому что она требует сотрудничества с бэкендом — API должен уметь возвращать частичные данные, либо фронтенду нужно запрашивать независимые куски отдельно, а не ждать один монолитный ответ. Но выигрыш велик: дашборд, мгновенно показывающий шапку и навигацию, а затем заполняющий каждый виджет по мере поступления данных, ощущается значительно быстрее, чем тот, что ничего не показывает, пока не готовы данные для всех виджетов сразу — даже если общее время до полной загрузки одинаково или чуть больше.
Определённые прогресс-бары важны именно здесь, потому что расплывчатые начиная с определённой длительности реально работают против вас. Если вы знаете, что процесс состоит из дискретных этапов — загрузка файла, затем обработка, затем генерация миниатюры — покажите эти этапы. «Загрузка (1/3)… Обработка (2/3)… Завершение (3/3)» превращает тревожную неизвестность в понятную последовательность, а понятную последовательность гораздо легче переждать, даже при той же общей длительности, потому что она даёт мозгу контрольные точки для измерения прогресса вместо недифференцированного куска времени.
Долгое ожидание (10 с и больше): задать ожидания и дать людям уйти
После десяти секунд вы уже управляете не восприятием, а напрямую терпением и доверием. Это территория экспорта видео, обработки крупных файлов, генерации сложных отчётов, инференса тяжёлых AI-моделей. Правильный паттерн здесь почти никогда не предполагает, что человек будет пялиться на спиннер. Он предполагает, что вы сообщите, сколько примерно придётся ждать («это обычно занимает около 2 минут»), позволите уйти и заняться чем-то другим, пока уведомление не сообщит о завершении, и обеспечите постоянный, видимый индикатор того, что задача всё ещё выполняется где-то в фоне, если пользователь покинул страницу.
Ошибка, которую я до сих пор вижу в инструментах команд, не продумавших это до конца: полноэкранный модальный лоадер, блокирующий весь интерфейс на время двухминутного экспорта, без возможности закрыть, без оценки времени и без уведомления, если процесс завершится уже после того, как внимание пользователя переключилось на что-то другое. Именно это решение может стать разницей между тем, доверит ли человек вашему инструменту свою реальную работу, или откроет вторую вкладку, чтобы выполнить задачу где-то ещё, пока ваш экспорт незаметно завершается во вкладке, о которой уже забыли.
Оптимистичный интерфейс: пропустить ожидание там, где можно
Самое мощное состояние загрузки — то, которое вообще не нужно. Оптимистичный UI обновляет интерфейс мгновенно, предполагая, что действие завершится успехом, и только потом сверяется с сервером или откатывается назад, если тот не согласен. Лайк поста, добавление товара в корзину, отметка задачи как выполненной, отправка сообщения в чате — во всех этих случаях процент успеха настолько высок (в большинстве систем заметно выше 99%), что показ состояния «отправлено» или «понравилось» мгновенно, ещё до подтверждения сервером, даёт куда лучший опыт, чем ожидание round-trip-подтверждения на каждое взаимодействие.
Ответственность дизайнера, которая идёт в комплекте с оптимистичным UI, — грамотно обработать сценарий сбоя, который команды часто пропускают, потому что это неблагодарный 1%-й случай. Если сообщение отображается как отправленное, а сервер позже его отклоняет, пользователю нужен ясный, ненавязчивый сигнал — небольшая иконка повтора, состояние «не удалось отправить, нажмите для повтора» — а не молчаливое исчезновение сообщения или зависание всего интерфейса ради объяснения ошибки. Сделанный правильно, оптимистичный UI близок к магии: продукт ощущается мгновенным, потому что с точки зрения пользователя он таким по большей части и является.
Индикаторы фоновой синхронизации
Шестой паттерн, и самый незаметный при правильной реализации, — это фоновый индикатор: небольшая надпись «синхронизация», «сохранено» или значок соединения, который живёт в тулбаре или строке состояния и тихо сообщает о ходе фоновой работы, не требуя внимания. Надпись «все изменения сохранены на Диске» в Google Docs — канонический пример. Никто на неё специально не смотрит, но именно её присутствие (и её редкий переход в состояние «сохранение…») заставляет людей достаточно доверять продукту, чтобы закрыть вкладку не задумываясь. Убрать её или сделать ненадёжной — значит подорвать доверие, на выстраивание которого ушли месяцы последовательного поведения, а разрушить его могут несколько неудачных случаев.
Где дизайнеры чаще всего ошибаются
Просмотрев множество чужих файлов в Figma и запущенных продуктов, я вижу, что ошибки группируются вокруг нескольких повторяющихся паттернов. Назвать их явно полезно, потому что большинство из них легко исправить, как только их замечаешь.
Первая — проектирование состояния загрузки в последнюю очередь или вообще никак, с расчётом на то, что тот, кто реализует экран, придумает что-нибудь сам. Состояния загрузки, придуманные разработчиками под давлением дедлайна, по умолчанию превращаются в то, что фреймворк даёт «из коробки» — обычно это центрированный спиннер, независимо от типа контента и длительности. Это не критика разработчиков — это проблема распределения ресурсов. Если в дизайн-файле есть только «счастливый путь» — полностью загруженный экран, — состояния загрузки и ошибки по определению будут реализованы без участия дизайнера. Каждая передача экрана в разработку должна включать как минимум состояние загрузки, пустое состояние и состояние ошибки в виде отдельных артбордов, а не упоминание вскользь в комментарии.
Вторая — искусственная задержка: добавление спиннера или фейковой анимации прогресса к ответу, который и так быстрый, потому что заказчику кажется, что интерфейс должен выглядеть так, будто он «что-то делает», прежде чем показать результат — особенно это касается AI-функций. Я понимаю этот инстинкт: мгновенный ответ от ИИ может показаться подозрительным, будто его «не продумали как следует». Но искусственно создавать задержку ради иллюзии труда — трюк, который срабатывает ровно один раз. В момент, когда пользователь замечает, что задержка фейковая — а внимательные пользователи её замечают, особенно если одна и та же фейковая задержка повторяется каждый раз одинаково, — доверие рушится быстрее, чем если бы вы просто сразу показали результат. Если хотите просигналить «реальная работа была проделана», делайте это через контент (покажите источники, которые использовала модель ИИ, покажите конкретные пройденные шаги), а не через секундомер.
Третья — несогласованный «словарь загрузки» в рамках одного продукта: skeleton-экран на дашборде, спиннер на странице настроек, прогресс-бар в потоке экспорта, каждый оформлен чуть по-своему, с разной анимацией и таймингами. Пользователи выстраивают интуитивную модель «что здесь означает загрузка» при повторяющемся взаимодействии, и несогласованность заставляет их заново учить эту модель на каждом экране — что подсознательно читается как недостаток мастерства. Компоненты состояний загрузки в дизайн-системе заслуживают такой же строгости, как компоненты кнопок или полей ввода — один компонент skeleton, один компонент спиннера, один компонент прогресс-бара, используемые последовательно, а не изобретаемые заново каждой продуктовой командой.
Четвёртая — игнорирование скачка верстки при завершении состояния загрузки. Это напрямую связано с правилом пика и конца: даже прекрасно продуманный skeleton теряет смысл, если при появлении реального контента всё «прыгает» на пару сантиметров, потому что высота карточки в skeleton не совпала с высотой реальной карточки, заполненной реальным текстом. Cumulative Layout Shift — измеримая, хорошо известная проблема в веб-производительности именно по этой причине, и это в равной степени дизайнерская, а не только инженерная проблема: дизайнерам нужно задавать минимальные высоты, ограничения по числу строк и примерное количество символов в плейсхолдерах, приближающих реальные размеры контента, а не просто приблизительную форму.
Пятая — избыточная проработка самой анимации загрузки. Я видел прототипы с проработанными кастомными иллюстрированными последовательностями загрузки — маскотами, шагающими по экрану, многоэтапными анимированными иллюстрациями — применёнными на экранах, которые у большинства пользователей с нормальным соединением грузятся меньше секунды. Такие анимации часто по-настоящему обаятельны сами по себе, но бьют по продукту двумя способами: они удлиняют ощущаемое время, давая глазу что-то сложное для отслеживания (новое, сложное движение воспринимается как более долгое, чем оно есть на самом деле), и становятся откровенно раздражающими при повторных просмотрах, как только очарование выветривается — примерно на пятый-шестой раз, когда ежедневный пользователь их видит. Приберегите проработанные иллюстрации загрузки для действительно редких и действительно долгих ожиданий — первого онбординга, крупных экспортов, — где новизна и длительность оправдывают вложения. Для всего, что пользователь видит десятки раз в день, сдержанность и скорость завершения важнее «характера».
Шестая, и, пожалуй, самая коварная — забывать про обратный случай: состояние загрузки, которое появляется и исчезает так быстро, что вызывает вспышку, а не ощущение надёжности. Если фрагмент данных обычно грузится за 150 мс, но иногда — за 2 секунды, безусловный показ skeleton означает, что большинство пользователей увидит резкое мерцание — skeleton, затем реальный контент, всё в пределах шестой доли секунды, — что читается как глюк, а не как плавность. Решение — небольшая задержка перед показом любого индикатора загрузки, обычно в диапазоне 200–300 мс: если данные приходят раньше этого порога, состояние загрузки вообще пропускается и сразу показывается контент; если нет — только тогда появляется skeleton или спиннер. Эта единственная деталь — задержка самого индикатора загрузки — устраняет огромную долю ощущаемых глюков в быстрых, но нестабильных сетях, и её редко указывают в дизайн-файлах, потому что это не визуальное решение, а решение о таймингах, которое нужно явно проговорить в заметках для разработчиков.
Практический фреймворк выбора и спецификации состояний загрузки
Учитывая всё вышесказанное, вот процесс, который я реально использую, когда проект доходит до этапа проработки поведения загрузки — независимо от того, работаю ли я в одиночку или брифую внутреннюю команду разработки клиента.
Начните с аудита каждого асинхронного действия в продукте и разбейте их по группам в зависимости от ожидаемой длительности в реалистичных сетевых условиях, а не только в быстром офисном Wi-Fi. Звучит очевидно, но большинство команд проектируют и тестируют исключительно на быстрых соединениях, а затем удивляются, когда пользователи с реальным 3G или перегруженной сетью сообщают о заметно худшем опыте. Я обычно запрашиваю у разработки p50 и p95 время ответа по каждому эндпоинту, потому что проектирование под медиану скрывает «хвост» — те 5% пользователей, у которых загрузка занимает 8 секунд, как раз и уходят и оставляют плохие отзывы, даже если остальные 95% ничего не замечают.
Затем для каждой группы применяйте соответствующий паттерн из классификации выше, а не то, что быстрее всего реализовать. Взаимодействия короче 400 мс получают мгновенные состояния «нажато/принято». Диапазон 400 мс–2 с получает skeleton, повторяющий форму контента, с встроенной задержкой появления в 200–300 мс. Диапазон 2–10 с получает постепенную отрисовку там, где это технически возможно, или определённый многошаговый прогресс там, где нет. Всё, что дольше 10 секунд, получает оценку времени, способ уйти и уведомление о завершении. Действия с высокой уверенностью и низким риском — лайки, сохранения, простые отправки форм — получают оптимистичный UI с явно продуманным сценарием сбоя, а не общим тостом об ошибке.
Затем спроектируйте сценарии сбоя и крайние случаи прежде, чем полировать анимацию «счастливого пути». Что делает skeleton, если запрос полностью провалился — висит вечно или переходит в состояние ошибки после тайм-аута? Что происходит, если пользователь запускает то же действие дважды, пока оно ещё загружается — кнопка отключается или ставится вторая заявка в очередь? Что делает прогресс-бар, рассчитанный на определённую скорость загрузки, при медленном соединении — заметно замирает или нечестно продолжает ползти вперёд? Эти вопросы важнее, чем кривая easing у мерцающей анимации, но им уделяют гораздо меньше внимания, потому что визуально они не так интересны.
Документируйте временные пороги явно в любом инструменте спецификации или передачи задач, которым вы пользуетесь — комментарии в Figma, общий документ, тикеты для разработки. «Показать skeleton, если ответ занимает больше 250 мс; показать сообщение "занимает больше обычного", если превышено 8 секунд; автоматически повторить попытку дважды, прежде чем показать жёсткую ошибку» — это спецификация, по которой разработчик может собрать точное решение. «Добавить нормальное состояние загрузки» — нет, и это гарантирует, что вы получите то, что по умолчанию выдаёт фреймворк, а затем потратите цикл ревью на споры о том, что можно было определить одним предложением заранее.
Наконец, тестируйте состояния загрузки в искусственно замедленных условиях перед релизом, а не только на собственной быстрой машине и сети. Троттлинг сети в Chrome DevTools или простое тестирование на телефоне с выключенным Wi-Fi и мобильным интернетом в зоне слабого сигнала выявляет проблемы, которые никогда не проявятся в студии с гигабитным оптоволокном. Я не раз ловил баги со скачком верстки, вспышки неоформленного skeleton и прогресс-бары, зависающие на 90% на целых десять секунд, исключительно с помощью такой пятнадцатиминутной проверки перед релизом, и каждый раз это обходилось дешевле, чем ловить проблему уже после потока тикетов в поддержку.
Как обосновать инвестиции в это перед бизнесом
Если вы фрилансер или агентство, сложность не в том, чтобы это понимать, — а в том, чтобы убедить клиента или продакт-менеджера выделить на это время, когда бэклог полон фич, которые кажутся более очевидно ценными, чем «починить лоадер». Вот аргумент, который сработал у меня и который не требует цитировать научные статьи скептически настроенному заказчику.
Представьте состояния загрузки как рычаг конверсии и удержания — потому что именно так они и работают, измеримо. Часто цитируемое внутреннее исследование Amazon о том, что каждые 100 мс задержки обходились компании примерно в 1% продаж, обычно приводят в контексте реальной скорости бэкенда, но исследования восприятия говорят о том, что грамотно спроектированные состояния загрузки способны отвоевать значительную часть этого же эффекта, вообще не трогая индексы базы данных — потому что часть «задержки», как её переживает пользователь, на самом деле является «неопределённостью», которую дизайн может напрямую снизить. Если клиент не готов тратить спринт на производительность бэкенда, но хочет улучшить процент завершения оформления заказа или конверсию из триала в платную подписку, укажите, что рычаг ощущаемой скорости часто дешевле в использовании, чем рычаг реальной скорости, и его можно реализовать силами дизайнера и фронтенд-разработчика за считанные дни, вместо миграции базы данных или переделки CDN.
Приносите в презентации и кейсы конкретные примеры «до/после» вместо абстрактных утверждений. Короткая запись экрана, сравнивающая ожидание с пустым экраном и ожидание со skeleton-экраном, проигранная клиенту в реальном темпе, доносит разницу примерно за четыре секунды — быстрее любого слайда с цитатами исследований. Это, откровенно говоря, ещё и одна из лучших вещей для портфолио UI/UX-дизайнера, потому что это редкий случай, когда можно продемонстрировать влияние дизайна на метрику (показатель отказов, завершение задач, обращения в поддержку про «зависание приложения») без полугодового A/B-теста.
Позиционируйте это как снижение рисков конкретно для AI-функций, потому что именно с этим сейчас приходит больше всего запросов от клиентов. Функции на базе ИИ — генерация, поиск, суммаризация, агентные сценарии — регулярно отвечают от 3 до 30 секунд, что на порядок медленнее, чем взаимодействия, к которым пользователи привыкли в остальном продукте. Клиенты, разрабатывающие такие функции, часто настолько сосредоточены на качестве модели и проработке промптов, что опыт ожидания привинчивается в последнюю очередь, и именно он часто становится реальной причиной плохого принятия отлично реализованной AI-функции: не потому, что результат был плохим, а потому что ожидание его увидеть казалось ненадёжным или бесконечным. Это плодородная, недооценённая territoria для дизайнеров прямо сейчас, и стоит явно предлагать «давайте спроектируем опыт ожидания для ваших AI-функций» как отдельную услугу, а не растворять её в общей полировке интерфейса.
Общая нить через всё это в том, что состояния загрузки находятся ровно на пересечении психологии, инженерных ограничений и мастерства, где и должен работать хороший UI/UX-дизайн. Они непрезентабельны при просмотре портфолио, их легко задвинуть в конец списка на планировании спринта, и они почти незаметны, если сделаны хорошо, — именно поэтому их и стоит делать хорошо. Никто не сохраняет скриншот состояния загрузки на сайты с дизайн-вдохновением. Но каждый на каком-то уровне чувствует разницу между продуктом, который уважает его внимание, пока заставляет ждать, и тем, который этого не делает, — и это ощущение накапливается, экран за экраном, определяя, достаточно ли человек доверяет продукту, чтобы продолжать им пользоваться.
