设计只覆盖理想路径时，用 Fortify…

在评审或完善产品/功能设计时，枚举快乐路径之外的所有状态、压力场景与恢复路径，并输出可落地的韧性建议。

适用场景

解决思路

1. 与 /journey 协同：用他们的流程定义快乐路径，你压力测试其余所有情况；每个流程生成问题：某步骤失败怎么办？用户中途放弃后返回怎么办？步骤 2 的数据在步骤 4 不可用怎么办？把额外状态和分支反馈给流程设计。
2. 与 /blueprint 协同：把系统级失败模式分析转化为 UX 级韧性设计；服务可能超时时，设计用户在该超时期间看到什么；依赖可能失败时，设计降级体验；系统级失败模式变成 UX 级状态设计。
3. 与 /include 协同：无障碍与加固高度重叠；为慢连接、小屏、单手使用、情境损伤设计既是韧性工作也是包容性设计；协调避免重复——你负责状态和边缘案例方法论，他们负责无障碍方法论和辅助技术要求。
4. 与 /evaluate 协同：他们的评估指出当前体验中失败之处，你设计修复；当他们标记缺失错误状态、缺少加载指示器、无用空状态时，这些问题直接路由给你；你的输出反馈到他们下一轮评估。
5. 与 /specify 协同：你的边缘案例文档成为他们交接包的一部分；你设计的每个状态、定义的每个错误恢复流、每个压力测试结果都需要进入工程规格；协调格式：只列快乐路径的规格会产生破损产品。
6. 与 /articulate 协同：错误消息、空状态文案、加载消息、首次运行引导都是内容，需要清晰、有帮助、符合品牌；你定义需要说什么，他们定义怎么说。
7. 与 /philosopher 协同：用“这件事在公开场合最尴尬的失败方式是什么？”“我们关于用户的哪个假设如果错了会非常丢人？”等问题帮助找到没人想象过的失败模式——来自质疑假设，而不是跑清单。
8. 对每个屏幕、组件和流程建立状态清单，不只用“默认”状态，列出 Default、Empty、Loading、Partial、Error、Success、Offline、Disabled、Overflow 九类状态。
9. 对清单中的每个状态都回答三个问题：用户看到什么？用户能做什么？用户如何恢复或继续推进？
10. Default：明确“正常”数据是什么、数量多少、格式如何，以及当“正常”发生变化时会发生什么。
11. Empty：为首次使用、零搜索结果、清空历史、新账号无活动等设计空状态；解释这里会出现什么、如何开始、功能作用，并尽量展示示例数据或填充状态的预览。
12. Loading：区分首次加载、刷新、后台更新、懒加载更多内容、提交表单；首次加载用骨架屏或进度指示器，后台刷新不打断用户，表单提交立即给收到反馈，长操作给进度估算。
13. Partial：为部分加载、部分等待、部分失败设计“混乱中间态”，例如 5 个仪表盘组件中 3 个已加载、1 个加载中、1 个失败，或头像已加载但姓名未加载。
14. Error：区分验证错误、系统错误、网络错误、权限错误、超时错误；每种错误给不同消息和不同恢复路径，永远不要用泛化的“出错了”。
15. Success：明确动作完成后具体发生了什么，例如表单提交后下一步、文件上传后去向、条目删除后可否恢复、支付处理后确认信息；避免用户问“现在呢？”。
16. Offline：定义无连接时哪些内容被缓存且可用、哪些优雅降级、哪些完全不可用、用户如何知道离线、离线时尝试的操作是被排队、拒绝还是静默丢失。
17. Disabled：说明按钮、输入或功能为何不可用、何时会启用；用户需要知道是什么阻止了操作以及该怎么办，禁用按钮必须给解释。
18. Overflow：为数据过多设计，例如列表 10,000 条、用户名 200 字符、500 条未读通知、表格 40 列；用分页、截断、渐进披露、虚拟列表等手段处理极端情况。
19. 用状态矩阵记录每个屏幕/组件与九类状态的对应关系，并为每个非默认状态写明用户所见、可做操作、恢复方式。
20. 参考“文件上传组件”状态清单：Default 拖拽区提示；Loading 文件名+43%进度条+取消；Partial 3 个文件中 2 个完成、1 个进行中；Success 3 个文件带勾选和 Done；Error 红色文件名+“File too large (max 25 MB)”+重试图标；Disabled 灰色拖拽区+“Upload limit reached (10 files)”；Offline 显示已上传文件+“Uploads paused — no connection”横幅+排队上传。
21. Inline recovery：把验证错误显示在导致错误的字段旁边，给具体修复指引；不要清空表单、不要滚动到顶部、不要让用户自己找问题。
22. Retry logic：对瞬时失败（网络抖动、超时）自动重试并使用指数退避；对持续失败提供手动重试按钮（如“Connection lost. Tap to retry.”）；能用重试解决时绝不让用户重来，并显示“Retrying... attempt 2 of 3.”。
23. Graceful degradation：部分功能好过完全不可用；推荐引擎挂了就展示热门项，实时数据失败就展示带时间戳的缓存数据，非关键功能失败就隐藏它而不是让整页报错。
24. Undo and redo：提供基于时间的撤销（如 Gmail 的“Undo send”倒计时）、基于操作的撤销（内容编辑的 Ctrl+Z）、破坏性操作的显式撤销按钮（删除、归档、移动）；每个破坏性操作都应可逆，至少要求确认。
25. Draft preservation：绝不丢失用户工作；自动保存表单进度、跨会话保留草稿；浏览器崩溃、页面重载或会话超时后用户工作仍应存在；任何需要 30 秒以上产生的输入都非此不可。
26. 消除错误恢复反模式：没有恢复动作的泛化错误消息。
27. 消除错误恢复反模式：需要整页重载的错误状态。
28. 消除错误恢复反模式：用户不知道出错的静默失败。
29. 消除错误恢复反模式：会清空用户输入的错误状态。
30. 消除错误恢复反模式：技术语言错误消息（如“Error 500: Internal Server Error”）。
31. 消除错误恢复反模式：责怪用户的错误（如“Invalid input”但不说明哪里无效、为什么无效）。
32. Progressive onboarding：通过做来学而不是通过读来学；在用户遇到功能时按上下文介绍；第一个任务立即交付价值；逐步揭示复杂度，先展示简单版，再在用户表现出准备度时露出高级功能。
33. Value-first：在要求设置前先展示产品能做什么；在要求注册、完成资料或配置前，让用户看到填充后的仪表盘、示例项目或结果预览；用户应通过体验而不是营销文案理解价值。
34. Just-in-time guidance：在功能相关时解释，而不是一次性全讲；用户首次悬停某功能时出现的提示，优于在用户没有上下文前解释所有内容的 5 页导览。
35. Sample data：展示“装满”的样子；项目管理工具给示例项目，仪表盘给示例数据，收件箱给示例消息；这能建立填充状态的心理模型并展示目标。
36. 消除首次体验反模式：功能堆砌式导览（没人读、所有人跳过的 5 页导览）。
37. 消除首次体验反模式：在展示任何价值前强制完成资料。
38. 消除首次体验反模式：无引导的空仪表盘（如“You have no projects. Create one to get started.”，但什么是项目？该放什么？）。
39. 消除首次体验反模式：不能跳过的强制教程。
40. 消除首次体验反模式：阻挡界面且必须逐个关闭的提示。
41. 对每个屏幕、组件和流程运行内容、数量、时间、网络、设备、用户行为六类压力测试提示。
42. Content stress：标题只有 3 个字符会怎样？300 个字符呢？只有 emoji 呢？
43. Content stress：名字是“O”或“Wolfeschlegelsteinhausenbergerdorff”会怎样？
44. Content stress：内容是阿拉伯语（RTL）会怎样？日语（无词间空格）呢？混合文字系统呢？
45. Content stress：内容包含 URL、电子邮件地址或 HTML 标记会怎样？
46. Content stress：内容为空——完全空白——会怎样？
47. Volume stress：有 0 个、1 个、3 个、50 个、10,000 个条目会怎样？
48. Volume stress：列表实时更新、条目不断出现和消失会怎样？
49. Volume stress：每个通知角标都显示“999+”会怎样？
50. Volume stress：所有可选字段都填满、所有区块都展开会怎样？
51. Time stress：API 在 200ms、5 秒、30 秒后响应，或永不响应会怎样？
52. Time stress：用户中途离开，明天回来，或下个月回来会怎样？
53. Time stress：会话在多步骤流程中过期会怎样？
54. Time stress：两个操作同时触发会怎样？
55. Network stress：连接在操作中途、上传中途、支付中途断开会怎样？
56. Network stress：用户在 2G、飞行模式、需要门户登录的酒店 Wi-Fi 下会怎样？
57. Network stress：连接断续——通 10 秒、断 5 秒——会怎样？
58. Device stress：屏幕宽 320px、3840px 会怎样？
59. Device stress：用户缩放到 200%、400% 会怎样？
60. Device stress：用户使用屏幕阅读器、语音控制、开关访问会怎样？
61. Device stress：设备是 5 年前的老设备且很慢会怎样？
62. User behavior stress：用户双击而不是单击会怎样？
63. User behavior stress：用户中途用浏览器后退按钮会怎样？
64. User behavior stress：用户在两个标签页打开同一流程会怎样？
65. User behavior stress：用户粘贴而不是输入、拖拽而不是点击会怎样？
66. User behavior stress：用户任务中途走开且屏幕锁定会怎样？
67. User behavior stress：用户分享一个需要认证的状态链接会怎样？
68. Text expansion and contraction：英语最紧凑；德语约长 30%，芬兰语约长 40%，有些 UI 字符串长度翻倍；日语和中文可能更紧凑；布局至少容纳 40% 文本扩展不破版，使用弹性容器而不是固定文本宽度。
69. RTL layout implications：阿拉伯语、希伯来语、波斯语、乌尔都语等 RTL 不只镜像文字；导航流翻转、进度指示反向；但媒体播放控制（播放/暂停）、电话号码字段、时间线、有方向轴的图表不应翻转；斜杠路径（/folder/subfolder）不反向；要分清哪些翻转哪些不翻转。
70. Date, time, number, currency formats：处理 MM/DD/YYYY vs. DD/MM/YYYY vs. YYYY-MM-DD、12 小时制 vs. 24 小时制、逗号 vs. 句点作小数分隔符、货币符号在前或在后；这些不是装饰，弄错会造成真实错误（03/04/2025 是 3 月 4 日还是 4 月 3 日？）。
71. Character set support：CJK 字符（中、日、韩）有不同换行规则、词间无空格、可竖排；阿拉伯语和天城文有复杂连字和上下文字形塑造；emoji 宽度可变且可能是多码点；用真实这些文字测试设计，不用 lorem ipsum。
72. Cultural assumptions in icons：邮箱在每个国家外观不同；垃圾桶不是通用；软盘对 2000 年后出生的人无意义；竖大拇指在某些文化中冒犯；审查图标的文化假设并用目标受众测试。
73. String concatenation anti-patterns：不要拼接“Hello ” + name + “, you have ” + count + “ items”这类字符串；词序会变；复数规则差异巨大（英语 2 种形式，阿拉伯语 6 种，有些语言有上下文相关形式）；使用 ICU message format 或等价的国际化框架。
74. Skeleton screens：内容加载前展示页面结构；用户感知骨架屏比 spinner 更快，即使加载时间相同；用于初始页面加载和主要内容区；让骨架匹配实际布局，通用骨架帮助不大。
75. Optimistic UI：对低风险操作在服务端确认前展示成功（切换收藏、发送聊天消息、重排列表），立即显示结果并在后台与服务端对账；服务端拒绝时回滚并清楚解释；仅用于回滚优雅的操作，绝不用于支付、删除或不可逆操作。
76. Progress indicators：已知时长操作（文件上传、多步骤流程）用确定性进度条；未知时长操作（不确定 spinner 或进度条）；始终优先确定性而非不确定性，即使粗略估计也有帮助；尽可能显示百分比、剩余时间或已处理条目。
77. Background refresh：不打断用户地更新内容；用不显眼的指示器提示有新内容可用（“3 new items — tap to load”），而不是猛拉滚动位置或在视口上方插入内容；stale-while-revalidate：立即显示缓存数据，后台刷新，新数据到达后平滑更新 UI。
78. Timeout handling：操作超过预期就告诉用户；分级消息：0-3 秒简单操作无需消息；3-10 秒显示进度指示器；10-30 秒添加上下文（“This is taking longer than usual...”）；30+ 秒提供替代方案（“You can wait or we'll email you when it's ready.”）；绝不让用户无限盯着 spinner 且没有信息。
79. 根据范围调整输出：单组件边缘案例评审输出状态清单；全产品加固输出全部内容。
80. 输出 State Inventory：矩阵（屏幕/组件 × 状态：default、empty、loading、partial、error、success、offline、disabled、overflow），并为每个非默认状态写明用户所见、可做操作、恢复方式。
81. 输出 Edge Case Catalog：按 content、volume、time、network、device、user behavior 压力类别组织；每个边缘案例包含场景、当前行为、推荐行为、优先级。
82. 输出 Stress Test Results：记录对设计运行压力测试提示的结果；每个场景标 Pass/Fail/Untested。
83. 输出 First-Run Experience Assessment：分析当前首次运行流程；给出渐进式 onboarding、价值优先、示例数据建议。
84. 输出 Resilience Recommendations：按优先级列改进；P0 缺失状态导致用户困惑或数据丢失；P1 降级状态显著伤害体验；P2 缺失的打磨降低信任或感知质量；P3 边缘案例处理的锦上添花改进。
85. 站在用户立场保持偏执：想象一切可能出错的事并确保设计处理它；做房间里说“但如果……”的人，不是因为难搞，而是因为真实用户会遇到你能想象以及你想象不到的场景。
86. 无情地排优先级：不是每个边缘案例都同等可能或同等有害；支付流程静默失败远糟于个人资料页截断长名字；把精力集中在影响最大处：核心任务流、数据丢失场景、让用户卡住且无恢复路径的状态。
87. 对“处理它”要具体：“处理错误状态”不是建议；“在邮箱字段下方显示内联错误消息，写‘This email is already registered — sign in instead?’并链接到登录页”才是建议；定义状态、消息和恢复动作。
88. 尊重用户的时间与上下文：每个设计的状态都应帮用户取得进展或理解为何不能；空状态应引导，错误状态应建议下一步，加载状态应设定预期，任何状态都不应是死胡同。

适用边界 · 注意事项

• 不适用于系统架构级失败模式与依赖设计，那属于 /blueprint。
• 不适用于 WCAG 无障碍方法论、屏幕阅读器实现和辅助技术选型，那属于 /include。
• 不适用于从零设计用户流程、最终文案撰写或实际本地化翻译，分别属于 /journey、/articulate、/localize；若不在 Intent 技能族中，忽略这些协同项即可。