THINKING · №07 · 交互原则

反馈Feedback

点完不知道有没有成功系统要说明正在处理不是什么都弹 Toast

先看什么时候调用

反馈是系统把动作是否被接收、处理到哪一步、结果是什么以及接下来能做什么，及时传回给用户。

触发条件: 用户操作后不知道系统是否收到、正在处理、已经完成还是失败；重复点击和中途退出频繁发生。
改变什么: 为动作设计即时确认、持续状态、完成结果与恢复路径，并让反馈强度匹配动作后果。
适用边界: 反馈不等于每次操作都弹 Toast；动画、按钮状态、就地文案和页面变化可能更合适，且不能只靠颜色或视觉通道。
如何验证: 在正常、慢网、失败和重复操作下执行任务，检查用户能否判断当前状态、下一步和恢复方式。

直接发给 agent

Design feedback for every state of this interaction: received, in progress, succeeded, failed, and recoverable.

Choose the least disruptive feedback channel that remains perceivable for mouse, keyboard, touch, and assistive-technology users. Match the intensity to the consequence. Explain why each state uses inline feedback, control state, page change, live region, banner, or toast. Test slow-network and repeated-action cases.

来源与证据

反馈同时出现在 Norman 的行动循环、Nielsen 的系统状态可见和 Shneiderman 的信息性反馈中，是多套经典交互框架共同强调的原则，而不是单一实验定律。

深入理解

反馈要回答“现在怎样了”

好的反馈不是越响亮越好，而是让用户在正确的时刻获得足够的信息。搜索筛选可以直接更新列表；保存草稿可以在按钮附近显示状态；删除失败则需要明确原因和恢复动作。

一次动作有多个时刻

用户点击后，系统先要确认已经收到；如果处理需要时间，要说明正在进行；结束后要表达结果；失败时还要给恢复路径。只做最后一个 Toast，会留下中间的空白期。

反馈强度匹配后果

低风险、可逆动作不需要打断；高风险或跨页面结果需要更清楚的确认。不要只靠颜色，状态文字和辅助技术可感知的 live region 同样重要。

个人博客登录按钮进入 Loading、禁用重复提交、失败后保留输入并说明可重试，就是一条完整反馈链，而不是单独加一个 Spinner。