D1.10.3Local-result feedback设计研究
全局提示区不适合承载局部操作结果
别名: global notification · local feedback · toast notification · object-level feedback
概念解释
对象级结果反馈（local-result feedback）要求某个局部对象被添加、修改、删除、排序或校验后，其结果首先体现在该对象及其直接上下文中，而不只由页面统一的全局提示区承载。全局提示区适合跨范围事件、系统状态和历史汇总；局部操作结果的关键证据则是对象本身是否真的改变、处在何种状态、还能否继续操作。把「已保存」「删除成功」只做成顶角 toast，会让用户得到一句话，却看不到这句话指向的实际结果。
机制
局部操作需要建立动作—对象—结果的闭环。对象上的状态变化提供可核对证据，也让用户在反馈消失后仍能理解当前界面。全局提示脱离对象，若连续操作多个项目，用户难以将每条消息配对；若通知自动消失、被其他消息覆盖或在屏幕外，闭环就完全断裂。系统因而可能「正确地通知」却仍让用户重复操作、怀疑保存失败，或在错误对象上继续工作。
怎么研究
让参与者连续编辑、批量操作或在列表中处理同类对象，比较全局 toast、对象级状态和两者组合对结果定位、错误发现、重复操作和撤销使用的影响。观察任务中断后用户如何确认刚才作用的是哪一项，及通知消失后是否还能找到结果。测试不要只看单次成功率：全局提示最容易在一次孤立操作中通过，却在多项并行、滚动和异步完成时暴露配对失败。
边界
局部变化并不排斥全局通知。影响多个对象、后台完成、权限变化或需要跨页面留痕的事件仍应进入全局区域；局部表面空间不足或对象已消失时，也可能需要全局记录加可追踪入口。但对象级反馈不能把复杂系统错误全塞进一行小字，且删除后的对象无法原地展示时，要用邻近位置、撤销入口或明确的列表变化保留证据。
怎么落地
- 为每类局部命令定义对象上可见、可持续、可核对的结果：字段值、状态徽标、列表位置、错误标记或撤销占位。
- 将全局提示用于补充范围、历史、跨页或长任务，并让它链接到受影响对象，而不是代替对象变化。
- 连续操作时让每个对象独立显示自身状态，避免一条全局「已完成」覆盖多个不同结果。
- 用多对象任务验收：用户在通知消失、滚动或被打断后仍应准确指出哪一项改变了、现在是什么状态以及如何撤回。