加载状态就是产品本身

把你的产品一年里展示的每一次加载状态加起来。每个用户,每次会话,每次刷新。这个数字,以用户小时计,就是你交付的所有界面中被注视最多的一个。大多数团队却当它无人问津。

仪表盘有设计评审。空状态也有设计评审,如果你读过空状态就是产品本身的话。加载状态呢?只有一个来自 2012 年样式表的 16 像素转圈,外加一句祈祷。它是用户永远会看到的界面,也是没人去设计的界面。

加载状态是一种品牌印象

**每个加载状态都是一份信任契约。**产品在对用户说:“我在工作,我没崩溃,这段等待是有意为之。”接下来屏幕上说什么,就决定了这个品牌如何应对压力。

Linear 的加载状态有 Linear 的味道。形状像 issue 列表的骨架行,在服务器确认之前就提交的行内创建,节奏刻意的品牌化过渡。Stripe 的加载状态有 Stripe 的味道。支付按钮的微光、仪表盘里卡片形状的骨架、收据渐渐落定为最终状态。两者都把等待当作产品本身。

糟糕的版本是白底上的老旧转圈 gif。没有内容形状,没有进度信号,没有品牌。用户听到的是:“我们太忙了,忘了你还在这儿。”这同样是一种品牌印象,只不过不是团队想交付的那种。

加载状态的五种原型

大多数团队把“加载状态”当成一个设计问题。其实是五个。每一种适合不同类型的等待,也因不同的原因而失败。

1. 骨架屏

一个镜像最终内容形状的占位布局。该有行的地方放行,该有卡片的地方放卡片。内容到达之前,眼睛先锁定结构,于是等待看起来是在“逐步完成”,而不是“刚刚开始”。

Linear 的 issue 列表使用行形状的骨架,与最终列表精确到像素。Stripe Dashboard 在指标区使用卡片形状的骨架,随后变成填充好的卡片。Notion 使用块形状的占位,文档加载后变成真正的块。承诺都一样:加载时的形状预示最终的形状。

适用于结构已知的情况。不适用于布局足够动态、骨架会对接下来的内容撒谎的情况。

2. 乐观 UI

在服务器确认之前,立即渲染用户的操作。在后台进行对账。如果服务器认可,UI 不会闪烁。如果不认可,UI 会回滚,并给出可见的撤销路径。

Linear 的行内创建 issue 是黄金标准。按下 C,输入标题,回车,issue 在往返请求完成之前就已经在列表里了。Figma 的光标和选择移动在整个多人会话中都是乐观的。用户永远感觉不到网络。

适用于失败很少见且可逆的情况。不适用于操作具有破坏性,或用户需要先拿到服务器答复才能继续的情况。

3. 流式局部输出

第一块内容先渲染,其余部分还在传输途中。等待消失在输出里,因为用户已经在消费结果了。

Claude 的 token 流是目前交付得最干净的例子,节奏经过平滑,以人类阅读速度呈现。Cursor 逐 token 流式输出 diff,所以模型还没写完,用户就已经在读代码了。Vercel 实时流式输出部署日志,用户是在看构建,而不是在等构建。关于为 AI 延迟而设计的文章涵盖了更广泛的延迟策略。

适用于结果有天然节奏的情况。不适用于各个片段单独看毫无用处的情况。

4. 进度即内容

等待本身就是价值。部署日志、构建流水线、智能体的推理轨迹。用户不是在等结果,他们就是在阅读结果。

Vercel 的部署视图是经典范例。部署日志就是加载状态,也是平台上最常被看到的界面。GitHub Actions 用逐步的运行输出做了同样的事。Cursor 的智能体面板在工作时展示推理轨迹,让持续数分钟的任务显得有目的,而不是卡住了。v0 和 Lovable 把这一套用在提示词生成应用的界面上,构建流就是加载状态,预览就是奖励。

适用于等待本身就是价值的情况。不适用于用户只关心最终状态、这些步骤对他们没用的情况。

5. 品牌化转圈

微脉冲、渐变、微光。产品赢得个性标记的那一刻。Stripe 的支付按钮微光、Vercel 的渐变进度条、Linear 在过渡性等待中的微脉冲。它们没有一个是单打独斗的。它们叠加在前四种模式之一上面,为本来就有结构的等待增添品牌质感。

适用于等待很短且界面风险很高的情况。不适用于背后没有骨架或数据流的情况。底下没有前四种模式之一的品牌化转圈,就是一个 1996 年的转圈,配了个 2026 年的色值。

骨架屏几乎每次都胜过转圈

骨架预示即将到来内容的形状。转圈只表示某处正在发生点什么。同样的等待,两种截然不同的体验。

Stripe 仪表盘的骨架在时钟上几乎不比转圈版本快多少,但感知速度的差距要大得多。用户看到卡片形状的布局,在数据到达之前就开始定位。等指标出来时,眼睛已经就位。用转圈的话,用户只能盯着屏幕中央,等待被允许看向别处。如果你能预测布局,就用骨架。如果不能,就用一行状态文字。

乐观 UI 是作弊码

等待变得不可见,因为操作在等待开始之前就已经提交。

Linear 处处都是乐观的。创建 issue、更改状态、更换负责人、添加标签、移动 cycle。每一项都在意图产生时写入本地存储,服务器响应后再对账。Figma 多人协作在光标移动、选择和大部分编辑上是乐观的。Notion 在文档编辑上是乐观的。每个产品都像本地软件,因为网络被藏在了乐观层之下。

有两点让它成立。失败必须少见且可逆,否则 UI 会闪烁,用户就不再信任它。而且错误必须可见。一个悄悄吞掉服务器错误的乐观操作,比没有乐观还糟,因为它教会用户这个操作成功了,而实际上并没有。每一次乐观写入都需要撤销、提示条或用户看得见的回滚。

优秀加载状态的五条规则

五条命中四条,等待就显得是设计过的。命中三条,加载状态开始像是事后补上的。

1. **加载形状预示最终形状。**行用骨架行,卡片用骨架卡片。内容落定时不能有布局跳动。
2. **尽可能给等待以内容。**流式输出 token,交付日志,渲染局部结果。在阅读的用户就不是在等待。
3. **超过 800ms 的等待都要有反馈。**低于 800ms,干净的过渡就够了。超过 800ms,用户需要系统还活着的信号,哪怕只是先出结构、再出内容的渐进披露。
4. **乐观操作需要可见的撤销路径。**提示条、回滚、清晰的错误状态。有乐观而无恢复,就是煤气灯操控。
5. **没有品牌理由就不要转圈。**品牌化转圈叠加在前四种模式之上,绝不取而代之。如果屏幕上只有转圈,设计就没完成。

更深入的背景见更广泛的网页设计原则拆解,以及core web vitals如何把布局偏移视为感知性能的失败。

杀死加载状态的反模式

有六种失败模式出现的频率高得不应该。每一种都能修复,而且每一种此刻都在某个线上产品里。

**没有进度的无限转圈。**一个转了十五秒却没有任何信号的转圈。用户不知道请求是活着、死了还是卡住了。把它换成状态文字、进度条或流式界面。

**无法关闭的整页阻塞弹窗。**一个劫持整个屏幕的加载弹窗,不让用户滚动、复制或阅读产品的其余部分。等待变成了劫持人质。

**骨架落定时布局跳动。**骨架与真实布局不匹配。行错位,卡片重排,页头移动。骨架不是另一套设计,它就是没有内容的同一套设计。

**永远循环的“Loading...”文字。**三个旋转的点,没有进度,没有状态。用户在两次会话内就学会无视它,这也废掉了这条渠道,之后界面发出的任何真实状态都没人看。

**悄悄吞掉错误的乐观 UI。**操作在 UI 中提交,服务器失败,产品却从不告诉用户。解法是可见的提示条、撤销按钮或回滚。

**100ms 等待上的品牌化转圈。**为一段用户还没察觉就结束的等待放一道微光。纯属多余。快的界面配得上淡入。慢的界面配得上结构。

有意设计摩擦讲的是少数应当刻意让等待可见的情形。加载状态不属于其中。它们是应当不可见、被设计过或被变成内容的等待。

加载状态审查

六个问题。在下一次发布之前,让每个加载界面都过一遍。

1. **加载形状是否预示最终形状?**可预测的布局用骨架,不可预测的用状态文字。落定时没有布局跳动。
2. **等待是否承载了信息?**骨架、数据流、进度日志、状态文字。任何超过 800ms 却什么都没有的等待,都是漏洞。
3. 每次等待是否只有一条主要信息?“正在加载仪表盘”胜过四个相互重叠的信号。一个信号,让视觉层级去发挥作用。
4. **加载状态是否符合品牌语气?**把加载文案放在已填充的界面旁边读一读。如果语气变了,加载状态穿的就是另一个品牌的衣服。
5. **乐观操作失败时是否可逆且可见?**每次乐观写入都有撤销、提示条或回滚。没有静默失败。
6. **加载界面能向陌生人推销这个产品吗?**如果他们见过的唯一界面就是加载状态,它会像他们注册的那个产品吗?如果不会,你应用里被注视最多的界面,也是设计得最差的界面。

一个每个加载状态都通过这六问的产品,即使在慢网络上也让人觉得快。

选好模式,再交付等待

加载状态不是打磨层。它是品牌层、信任层和感知性能层,被压缩进用户看得比任何界面都多的那个屏幕。每一次等待都是一个设计选择,无论团队是不是有意为之。

结构已知,用骨架。失败可逆,用乐观。结果有节奏,用流式。等待即价值,用进度即内容。只有前四种已经各司其职时,才用品牌化转圈。落地页设计原则拆解就是这门功夫的营销页版本。

别再把加载状态当作为慢而道歉。累积起来,它就是产品。让这段等待值得他们花时间。

FAQ

骨架屏和加载转圈有什么区别?

骨架用占位布局预示最终内容的形状,所以用户在数据到达前就开始定位。转圈只表示有事在发生,没有形状,没有结构,没有预览。骨架会压缩感知到的等待。转圈不会。

什么时候该用乐观 UI,什么时候该用流式响应?

当用户的操作本身就是工作时用乐观 UI,比如添加 issue、切换状态或移动卡片。当服务器在做工作且结果有天然节奏时用流式,比如文本生成、日志输出或部署流水线。两者可以组合。

交付一个普通转圈有没有可以接受的时候?

只能作为一秒以内的兜底,只能在布局确实无法预测时,而且必须有品牌理由。骨架、状态文字或流式界面在每一项感知性能指标上都胜过转圈。默认把转圈放在最后。

设计等待,交付产品

等待是用户看得最多的屏幕。是他们最常得到的品牌印象,最常读到的信任信号,也是每次页面加载时他们都在进行的感知性能测试。一个花六周设计仪表盘、只花一个下午设计加载状态的团队,把工作量投错了比例,偏离了用户真正生活的地方。

如果你想要一个把加载状态当作产品一部分来设计、而不是上线前最后一个 sprint 才想起的团队,来找 Brainy。我们交付的产品里,等待是品牌的一部分,感知性能胜过实际性能。