撤销优先于确认
别名: 撤销优先 · undo over confirm · 事后补救优于事前拦截
概念解释
面对一个可能出错的操作，系统可以在它发生之前拦一下（弹出确认对话框，要求用户再点一次才算数），也可以让它直接发生，但保留一段时间可以把结果收回来（撤销）。这条讲的是两者之间的默认取舍：对大多数场景，应该优先选撤销，而不是确认。原因不是确认没用，而是确认的成本发生在每一次操作上，撤销的成本只发生在真正出错的那一次——多数时候用户并没有做错，确认却让所有人每次都多付一次代价。
机制
确认对话框和撤销窗口在成本结构上完全不对称。确认框不管这次操作对不对，都会在操作路径上插入一次额外的交互，用户必须停下、读、点，哪怕这次操作百分之百是他想要的；这个成本按操作发生的次数线性累积，操作越频繁，总代价越高。撤销则相反：只要操作没有出错，撤销功能完全不产生任何成本，用户甚至不会意识到它的存在；只有当错误真的发生时，用户才需要花一次代价去调用撤销。这意味着在操作频繁、多数情况下都是对的场景里，撤销的期望总成本远低于确认，因为撤销把代价精确地摊在了真正需要付代价的那些少数情形上，而不是摊在全部操作上。
怎么研究
比较两种策略的实际效果，常见做法是分别统计"确认模式"下用户完成同类高频操作的平均耗时与放弃率，以及"撤销模式"下实际发生错误后用户是否成功、及时地使用了撤销——如果撤销模式下的错误恢复率足够高，而它节省的每次操作耗时又显著，说明撤销在这类场景下整体更划算。这类比较需要同时纳入一个容易被忽略的变量：确认对话框本身的防护效果会随着重复出现而系统性下降，用户很快学会不看内容直接点掉它，这一衰减规律削弱了确认作为长期策略的可持续性，是判断该用哪种策略时必须考虑的部分。
边界
这个偏好不是没有前提的。它成立的两个条件是操作可逆、且操作频繁发生；一旦其中一个条件不成立，结论就会反转。如果一个操作后果不可逆或极其严重——资金已经转出、消息已经发给不该看到的人、物理设备已经启动——撤销窗口在错误已经生效之后才启动，往往来不及阻止实质性的损害，这类场景应该优先选择用强制功能一类"不满足前提就无法继续"的手段在操作发生之前就把它挡住，而不是留到之后收拾——挡住发生和事后可退回是两种不同阶段的策略，前者的成本也发生在每次操作上，但换来的是错误根本没有机会造成实质影响，这个交换在低频、不可逆的场景里才划算，在高频、可逆的场景里则相反。如果一个操作发生得极其罕见（比如账户注销），单次操作的额外确认成本可以忽略不计，此时用确认或更强的拦截手段并不会带来太大效率损失，值得为了保险起见多问一句。也就是说，撤销并不是在任何时候都比"事前拦住"更优，只是在"高频"与"可逆"同时成立时，它的总成本才明显更低；一旦操作变得低频或不可逆，权衡的天平会倒向在操作发生前就把它挡住，而不是依赖之后的补救。
怎么落地
对每一个可能触发确认对话框的操作，先判断它是否可逆、发生频率是否高。可逆且高频的，去掉确认对话框，换成"操作立即执行 + 一段时间内可撤销"的模式，撤销入口要清晰可见，不能藏在菜单深处。低频且不可逆的操作，不要依赖撤销，应在操作发生前设置更强的拦截。验证办法：统计某个操作从"确认模式"改为"撤销模式"前后，用户实际因为操作错误而寻求人工客服或反复重试的比例——如果这个比例没有上升甚至下降，同时操作路径的平均耗时缩短，说明撤销确实是更划算的选择；如果错误后果的申诉量明显上升，说明这个操作可能被误判为可逆或高频，需要重新划入前置拦截的范围。