系统需要确认操作成功或状态变化时：设计即时、确认…

当系统必须向用户确认成功或变化时，用反馈模式设计确认、状态更新和通知，避免用户不确定操作是否注册。

适用场景

解决思路

1. 设计反馈机制，用来确认操作、传达状态并引导下一步。
2. 点击按钮时改变按钮状态。
3. 输入时做内联验证。
4. 切换控件时给出视觉响应。
5. 拖拽时更新拖拽位置。
6. 操作完成后显示成功 toast/snackbar。
7. 完成时播放或显示对勾动画。
8. 给出已完成内容的摘要。
9. 对可逆操作提供撤销选项。
10. 对进行中的过程显示进度指示器。
11. 显示状态徽章（待处理、进行中、已完成）。
12. 显示活动指示器（输入中、上传中、同步中）。
13. 显示系统健康指示器。
14. 对事件显示应用内通知。
15. 对未读项显示徽章计数。
16. 对系统级消息显示横幅警告。
17. 对时间敏感项发送推送通知。
18. 使用视觉通道：颜色变化、图标、动画、徽章。
19. 使用文本通道：Toast 消息、内联文本、状态标签。
20. 使用音频通道：点击音、通知提示音、警报音。
21. 使用触觉通道：点击反馈、成功振动、警告震动。
22. 首选内联/上下文反馈，最靠近操作发生的位置。
23. 其次使用组件级反馈，在当前组件内。
24. 再次使用页面级反馈，在页面级显示横幅或 toast。
25. 最后使用系统级反馈，在当前视图之外发通知。
26. Toast 在 3-5 秒后自动消失。
27. 错误持续显示，直到解决或被关闭。
28. 确认信息短暂显示，并提供撤销窗口。
29. 状态信息在相关期间持续显示。
30. 确认每一个用户操作。
31. 让反馈强度与操作重要性匹配。
32. 不要为次要确认打断用户流程。
33. 提供撤销，而不是使用“你确定吗？”。
34. 确保反馈可访问，不要只依赖颜色。
35. 测试反馈时机是否合适。

适用边界 · 注意事项

• 等待状态（加载中、处理中）应使用 loading-states，而不是本技能。
• 失败或错误处理应使用 error-handling-ux，而不是本技能。