缩小手段是反馈与状态表达
别名: 状态表达 · 反馈设计 · 结果比较 · 最小充分证据
概念解释
缩小评估鸿沟（Gulf of Evaluation）要把系统状态表达成用户可感知、可解释、可比较的证据：及时反馈说明事件发生；状态表达说明对象、阶段、数量、时间、错误和后续；结果视图支持用户与目标比较。这一条是组内的收尾条目：前两条分别定义了评估鸿沟是什么、它在"是否成功"这个典型场景里具体长什么样，这一条给出对应的修补手段——而且这个手段恰好和"执行鸿沟"那一组的三层修补手段（可见性、意符、约束）形成镜像：一组解决"我能不能做"，这一组解决"我做完之后知不知道结果"。
机制
有效的反馈可以拆成四层，分别对应任务进行的四个时刻：确认（系统收到了请求）、变化（处理正在推进）、完成（达到了终态）、失败（未能达到终态及原因），这四层各自成立的条件不同，缺一层就会在对应的时刻留下一段用户感知不到任何证据的空白。状态表达要解决的是另一个问题：即使反馈按时出现了，如果表达它的词汇本身含糊——比如不同页面用"处理中""进行中""待确认"指代同一件事，或者同一个词在不同场景下代表不同阶段——用户依然无法把感知到的信息映射回自己能理解的概念，这一步映射失败和反馈缺失产生的效果是一样的，都是用户判断不出真实状态。真正决定设计质量的不是"显示了多少信息"，而是"在用户需要做判断的那个时间点，有没有给出判断所需的最小充分证据"——多余的字段不会帮用户判断得更准，只会增加他从一堆信息里挑出关键那几项的认知成本，这也是为什么反馈设计不能简单地等同于"多显示点东西就更透明"。
边界
反馈过量本身会制造新的问题：如果每一次小的状态变化都触发一条通知或提示，用户会在大量常规提示里逐渐丧失对提示本身的敏感度，真正需要被立刻注意到的严重异常反而会被淹没在一堆无关紧要的常规反馈里——这和"狼来了"式的信任消耗是同一种机制。动画本身也不能替代语义：一个持续转动的加载图标只能表达"系统还没结束"，无法回答"结束之后会是什么结果"，如果设计者误以为动效已经完成了状态表达的任务，实际上真正的语义层从未被填上。受权限限制的状态也是一处边界：某些用户没有权限看到完整的处理细节（比如审批链条上其他环节的具体内容），这种情况下应该展示用户权限范围内的摘要信息，并给出一个明确的诊断或申请入口，而不是因为怕越权就干脆什么都不说。乐观界面（先展示预期结果、后台再确认）必须在确认失败时立即撤回并纠正这个预期展示，绝不能让用户带着一个已经被推翻的假象继续往下操作。
怎么落地
- 为每一个操作明确定义接收、处理、成功/失败和下一步这四层反馈，缺哪一层就单独补齐哪一层，而不是笼统地"加个提示"了事。
- 全产品统一状态用词并对每个词给出清楚的阶段定义，比如约定"已发送"专指离开本地、"已确认"专指对方系统已接收，不允许不同团队各自发明相近但含义不同的词。
- 提供结果摘要时包含时间、影响范围、错误原因和撤销/重试入口，让用户不用额外操作就能拿到判断所需的关键信息。
- 验证办法：在关键节点做验证访谈，请用户用自己的话说出"是否成功、发生了什么、接下来会怎样"，凡是回答含糊或者说错的，说明当前反馈提供的信息量没有达到这一刻判断所需的最小充分证据，需要针对性补充，而不是不分场景地整体加量。