状态设计

用户对 APP 的信赖，一半来自你把不正常的四种情况都提前设计好了。状态设计，就是不只画"正常态"，连"空的、加载中的、出错的"也一起画好——让用户在任何情况下都"知道现在是怎么回事、接下来能干嘛"。

为什么只画正常态会"打脸"

很多新手设计师只画"正常态"——界面数据满满、加载一秒完成、一切顺利。交稿后开发做好，用户一用就"打脸"：网络一卡，页面白屏；没有消息，列表空荡荡；连不上服务器，点哪都没反应。为什么被打脸？因为真实 APP 不是永远"正常"的——有加载、有空、有错误。状态设计，就是"把不常见的情况也设计好"，让用户在每种情况下都不懵、不慌、有出路。

真实 APP 不是永远正常：加载、空、错误是每天都会发生的情况。

四大状态：正常、加载、空、错误

微信首页下拉刷新，就是"加载态 → 正常态"的切换：下拉时"正在加载…"的转圈出现，数据加载完转圈消失。

一个界面 / 一个页面，通常要覆盖四种状态。正常态是数据都有了、完美展示（最常画的那版）；加载态是数据还在路上，先给个"正在加载"的反馈；空状态是没数据，告诉用户"这里什么都没有"并引导去添加；错误态是请求失败，告诉用户"出错了"并给重试 / 返回的出路。一句话记：正常 + 加载 + 空 + 错误，四态都要设计。

四态口诀：正常 + 加载 + 空 + 错误。

状态流转：状态机思维

发一条微信消息，是一条完整的"状态机"：

状态	长相	怎么来的	出路
发送中	气泡灰蒙 + 小沙漏	点击发送	防止重复点（告知"正在发"）
发送成功	气泡恢复彩色，正常显示	网络通，自动切换	无
发送失败	气泡变红 + "ⓘ 发送失败"	网络断，自动切换	点一下弹出"重试"

注意细节：微信发送失败的气泡是唯一能"点一下救回"的元素——这就是"错误态给出路"的实战样本。而"发送中"的沙漏还有一个作用：防止用户重复发送（他以为没发出去会再点一次，沙漏告诉他"正在发，别急"）。状态设计连"防止用户误操作"都替你考虑到了。

状态不是散乱的一堆图，而是有起点、有出口、能切换的一套系统。设计师要想清楚三件事：① 有哪几种状态（正常/加载/空/错误）；② 每种状态长什么样（长相 + 文案 + 出路）；③ 状态之间怎么切换（自动，如加载中→正常；用户触发，如失败→点重试→重新发送）。第三点尤其重要：状态不是静态的"四张图"，而是一条会动的"路"——要把这条"路"走通，别只画终点。

加载 / 空 / 错误怎么写文案

三态文案各有心法：

• 加载态：告诉用户"还在加载，请稍等"，别让用户以为卡死了。可用转圈（通用）或骨架屏（用灰色占位块模拟真实布局，视觉上更"有盼头"，高端产品常用）。
• 空状态：告诉用户"现在没数据"，并引导下一步。"暂无消息"是"说明现状"，"去和好友打个招呼吧 + 按钮"是"给出出路"。空态最重要的是别让用户觉得坏了，要让他知道"这里本来就空，你可以去干点啥"。
• 错误态：告诉用户"出错了"，并给重试 / 返回的出路。文案要具体、可操作——"网络开小差了，请检查网络后重试"比"错误"两个字有用得多。错误态最忌讳把用户堵死，一定要给"重试"或"返回"。

三态文案心法：加载态"请稍等"、空状态"说明现状 + 引导下一步"、错误态"具体可操作 + 重试/返回出路"。

边界：不是每页都做四张图

状态设计不是"每页都做四张图"，而是预判哪里会出状况：数据从网络来的（列表、详情、首页内容）→ 需要加载态、错误态；数据可能为空的（聊天列表、收藏、历史记录）→ 需要空态。数据是本地写死的（比如设置页的固定开关）→ 几乎不会加载 / 失败，正常态够了，不必硬凑四张图。判断标准："这块数据会不会没有？会不会加载慢？会不会失败？" 会的，就给它配对应的状态；不会的，别浪费。

深度 状态与组件是同一套思维、不同粒度：组件的多态（normal 正常 / pressed 按下 / disabled 禁用）和这里的页面四态，都是"元素不只一种长相，要设计全"。组件状态聚焦"按钮 / 卡片这种小零件"，页面状态聚焦"整个页面 / 整块区域"。任何元素都要问一句"它有哪些状态？都设计了吗？"——组件多态的深化见 22 组件库。

配态判断标准：这块数据会不会没有？会不会加载慢？会不会失败？会就配，不会别浪费。

深度

状态机为什么是"路"不是"图"？ 状态机思维想清三件事：有哪些状态、每种长什么样、状态之间怎么切换。微信发消息就是典型：发送中→成功是自动跳，失败→重试是用户救回。设计时要把这条"路"走通，别只画终点。

依赖与联动：本知识点依赖 13 Auto Layout（做组件 / 页面时状态区域也要能自适应伸缩）和 16 信息架构（空态 / 错误态的"去往哪"要符合用户心智找路逻辑）；"状态与组件"的深化见 22 组件库（组件多态 normal / pressed / disabled 与本知识点同思维）。

实例：完整跑一遍微信消息状态机：

用户点发送
  └─ 发送中：气泡灰蒙 + 小沙漏（告知"正在发"，别重复点）
        ├─ 网络通 → 发送成功：气泡恢复彩色，正常显示
        └─ 网络断 → 发送失败：气泡变红 + "ⓘ 发送失败"
              └─ 用户点消息 → 弹出"重试" → 重新走发送中…

误区

误解	正解
"只画正常态就够了"	正常态只是四分之一。加载 / 空 / 错误是客观存在的，不设计就是让用户对着白屏 / 报错干瞪眼。
"状态是开发补的，不归我管"	状态是设计师先定义的——空态写什么文案、加载用转圈还是骨架屏、错误给不给重试按钮，都是设计决策。
"状态设计 = 每页画四张图"	要有判断地配态：本地写死、不会失败的数据不必硬凑四态。
"状态是四张静态图"	状态是会流转的状态机，重点在想清"状态之间怎么切换、有没有出路"。
"空态 / 错误态随便写句'暂无 / 失败'就行"	空态要引导下一步，错误态要给具体可操作的文案 + 重试 / 返回，别把用户堵死。

练习

即时题 一个网购 App 的"订单列表"页面，设计师只画了正常态（订单满满、加载一秒完成）。如果不设计加载态、空态、错误态，用户分别在哪些真实场景会"懵掉"？并为这三种情况各给出你建议的文案和"出路"按钮。

模块题 你要为微信"发消息"设计状态。请：

1. 列出这条消息会经历的所有状态（含发送中、成功、失败）。
2. 说明失败态要给用户什么"出路"，以及为什么"发送中"要显示沙漏。
3. 用"状态机"的思维，画出"点发送 → … → 成功"和"点发送 → … → 失败 → 重试 → 成功"两条流转路径。
4. 说明不设计失败态，用户会遭遇什么糟糕体验。

迷你案例：重建微信"消息列表"四态 + 发消息状态机 在 Penpot 新建一个 375×812 画板（依赖 13 Auto Layout 让四态都能自适应伸缩）：

1. 先做一个"消息列表"正常态：放进 5~6 条对话（Auto Layout 纵向，gap=16）。
2. 复制三份，分别改成加载态（灰色骨架屏占位块 + "正在加载…"）、空态（中央空图示 + "暂无消息，去和好友打个招呼吧" + "去发现"按钮）、错误态（"网络开小差了，请检查网络后重试" + "重新加载"按钮）。
3. 对比四份：正常态之外的三种，是不是都"有说明 + 有出路"？
4. 再做发消息状态机：画一个聊天气泡，做三版——发送中(灰 + 沙漏)、成功(彩)、失败(红 + "ⓘ 发送失败")。用箭头标出流转：发送中→成功；发送中→失败→(点重试)→发送中→成功。
5. 想一步：为什么"发送失败"的气泡要特别醒目、且能"点一下救回"？

做完你会明白：好产品的可靠性，一半来自把"不正常的四种情况"都设计好了。

素材

• 👉 打开交互演示：状态设计 — 同一消息列表切换正常 / 加载 / 空 / 错误四态，动态跑一遍微信"发消息状态机"（发送中→成功 / 发送中→失败→重试→成功）。
• 微信观察：发一条消息看它的状态流转（发送中→成功 / 失败→重试），下拉首页看加载态，新建号看聊天列表空态——这是最好的"状态设计"活教材。
• Material Design 3：Progress indicators（加载态）、Empty states / Error states 相关章节（官方标准做法）。
• Apple HIG：Loading 与 Error 相关指南（官方规范）。
• 概念解析：搜索 "empty state UI design" / "skeleton screen" / "state machine UI"（讲空态、骨架屏、状态机设计）。
• 后续衔接：本知识点（页面四态）→ 22 组件库（组件多态 normal/pressed/disabled，同思维）→ 20 反馈动效（状态切换的动效表现）。

---