可撤销优于确认 | 设计交互 | 做产品
可撤销优于确认
与其在操作前问「你确定吗」，不如让操作先发生，再给一个能反悔的窗口。
你会遇到的现象
-
用户对所有确认弹窗都直接点确定，从来不读
-
批量操作时要一个个确认，烦到不想用
-
真的删错了，除了找你恢复没有别的办法
确认弹窗的问题在于它的成本分摊反了：一百次操作里可能只有一次是误操作，但一百次都被打断。而且弹得多了，用户会形成肌肉记忆，看到弹窗直接点确定——那一次真正的误操作照样拦不住。
撤销把成本挪到了出错的那一次：正常操作完全不被打断，出错的那次花一秒钟点一下撤销。
什么时候还是要确认
情况用哪种为什么 删一条笔记、归档一封邮件撤销可逆，影响只在自己 批量删除、批量修改状态撤销逐个确认会让人放弃使用 发送消息、提交表单撤销给几秒钟的撤回窗口就够 付款、转账确认钱出去了收不回来 作废合同、公开发布确认影响到别人，且对外可见 物理删除、清空数据确认真的没了。这时候还要提高确认成本
判断依据是两条：这个动作可不可逆，以及后果影响几个人。两条都答「可逆、只影响自己」，就用撤销。
确实需要确认的时候，要提高确认的成本，让人无法条件反射地点过去：要求输入合同编号、把主按钮改成危险色、把「确定」换成具体的动词（「作废合同」而不是「确定」）。
一格是一次操作，红色那格是真正的误操作
先确认再执行
五十次操作，五十次都被打断 而其中只有一次是误操作 —— 成本分摊反了
先执行，给一个能反悔的窗口
正常操作完全不被打断 出错的那一次，花一秒钟点一下撤销
而且弹得多了，用户会形成肌肉记忆——看到弹窗直接点确定，那一次真正的误操作照样拦不住。 判断依据只有两条：这个动作可不可逆、后果影响几个人。两条都答「可逆、只影响自己」，就用撤销。
确实需要确认的时候，反而要提高确认的成本，让人无法条件反射地点过去：要求输入合同编号、把主按钮改成危险色、把「确定」换成具体的动词（「作废合同」而不是「确定」）。
撤销怎么做
-
**底层用软删除。**加一个删除标记而不是真的删掉。有了它，撤销就是把标记改回来，成本极低。
-
**撤销入口跟结果反馈放在一起。**删除后的提示条上直接带「撤销」，用户不用去别处找。
-
**窗口期给足。**五到十秒是常见值。批量操作可以更长，或者干脆做成回收站。
-
**撤销之后要能看到东西回来了。**只弹一句「已撤销」不够，列表里那一条要真的出现。
-
**回收站是撤销的长期版本。**短窗口来不及的时候，用户还有第二条路。
这套做法对 vibecoding 有个额外好处：软删除加撤销，本质上是让数据不会真的消失。AI 生成的代码在删除逻辑上出错的概率不低，有这一层兜底，出错的代价小很多。
接着看
操作必有反馈 撤销入口就长在结果反馈上。那一篇讲三层反馈分别该出现在什么时候。
提示的五种形式 很多确认弹窗其实是越级使用了强提示。改成撤销之后，强度可以降到轻提示。
数据模型先行 软删除标记要在建表时就加上。后补的话，已有数据的处理会很麻烦。