H3.02.1name the failed outcome first设计研究
说明发生了什么
别名: 错误结果陈述 · what happened · 失败状态
概念解释
恢复流程的第一句话要回答发生了什么：哪一次提交没成立、哪笔款没划走、哪份草稿没写上服务器。人要先重建当前世界，才能决定下一步。这条只负责把失败结果说成任务事件，不负责解释原因、不负责给出修法，也不负责语气好不好听。
机制
错误把人从「我在推进任务」甩到「世界和我以为的不一样」。工作记忆里还装着刚才的意图，但系统状态已经变了或没变。若界面只闪红、只说「失败」或只丢一个码，人无法判断：是没发出去、发出去被拒、还是已经成功只是页面没刷新。结果陈述把差异翻译成任务对象上的事实（订单仍是待支付、照片还在本地、权限没有增加）。没有这句，后面的原因和修法都没有附着点——人会拿最常见的猜测去行动，于是修错对象。
怎么研究
给同一失败注入三种表面：只有图标或颜色、一句结果、结果加原因。让人在不能再点下一步之前用自己的话复述「现在是什么状态」。
自变量：是否说出失败对象与结果、是否与真实后台状态一致、是否把部分成功说成全部失败。 因变量：状态复述正确率、错误归因方向、立即重试还是改别的、放弃率。
实验室里「假失败」若不影响被试自己的内容，复述会偏乐观。更硬的做法是让人刚输入的一段文字「没保存成功」，再问这段话现在在哪。
边界
瞬时、自动恢复且对用户无可见后果的失败可以不打断，不必为了「完整三要素」硬弹一层。结果未知时（支付超时）要说「状态还不知道」，不能把未知写成确定的失败或成功。安全场景可以少说内部机制，但仍必须说清用户侧结果：登录没成功、转账没发出。多个对象部分成功时，一句「操作失败」是在说谎。
怎么落地
- 每条错误的首句写成「对象 + 结果」：哪张表没提交、哪笔钱没扣、哪项权限没改上。
- 对照真实后台状态写这句话；前端超时不得默认写成「失败」，要写成「还在确认」。
- 把结果放在人刚才操作的那一块，而不是只在页面顶部闪一下。
- 验证：挡住后续按钮，问刚经历失败的人「现在到底怎样了」。说不出对象或说错已发生/未发生，首句就没成立。