让操作有回头路
真正让人安心的界面，不是把每个动作都做得很隆重，而是在关键动作之后留出一条可以回头的路。用户按下按钮时，最需要的往往不是庆祝动画，而是三个判断：刚才发生了什么、有没有影响重要内容、如果按错了能不能恢复。
这也是“撤销”比“确认弹窗”更温和的地方。很多低风险动作不必在发生前拦住用户，因为拦截会打断节奏，让界面变得像一连串关卡。更好的做法是让动作先完成，再用轻量反馈说明结果，并在短时间内提供撤销入口。比如归档一封邮件、移除一个标签、移动一个任务，完成后出现一条安静的提示：“已归档，可撤销。”
但这不意味着所有操作都应该靠撤销解决。删除账户、支付、公开发布、覆盖大量数据这类高风险动作，仍然需要更明确的确认、后果说明和二次判断。关键不在于是否弹窗，而在于界面有没有按照风险分层：轻动作给回头路，重动作给停顿和解释。
很多产品的误区，是把反馈做成单纯的“成功提示”。绿色勾、烟花、toast 都只能证明系统收到了动作，却没有帮助用户理解后果。真正好的状态反馈会把操作结果放回工作现场：对象去哪了、页面为什么变了、下一步还能做什么。
追问： 如果把一个常用功能里的所有“确认弹窗”拿掉，哪些动作应该改成撤销，哪些动作必须保留停顿？
[!quote] 参考资料