「删除前确认」和「删除后允许撤销」两种处理方式哪个更好？ 第1页

似乎大部分答案都倾向于「删除后撤销」

第一反应确实应该是「删除后撤销」好一点，因为不管是「删除前二次确认」还是「删除后撤销」都是为了“误删”这个场景的，但是显然这个场景并不是经常出现的一个场景，而如果用「删除前二次确认」的方式，等于让所有用户在所有删除场景下都要被打断；用「删除后撤销」只会影响到误删场景下的用户，正常使用的用户则不会收到干扰和影响

但是为什么现在大部分的互联网产品还是使用「删除前二次确认」的方式？因为「删除后撤销」是有成本的，成本有两点：

1.认知成本

2.开发成本

1.认知成本

如果我问你，删除后的撤销入口应该放在哪里，你一定答不上来，因为你在脑袋里检索了以前所有使用过产品的撤销功能入口，一定是放哪都有：有在提示条上做撤销的；有在删除的位置上直接放个撤销的；有专门弄一个最近删除列表，在上面做撤销恢复的……

放哪都有意味撤销入口并没有一个标准，一个应该放哪里的标准，这也意味着每进到一个新产品，用户都需要重新认知撤销的入口在哪；而需要让用户能够认知到撤销入口（总不能误删了找不到怎么撤销吧），势必又要增加引导，加强用户的感知，而加强了感知，其实也就是分散了所有正常使用用户的注意力

我们梳理一下：

a.因为没有标准，用户不知道撤销入口在哪

b.需要加强引导让用户知道撤销入口在哪

c.考虑到用户在不是误删的情况下一般是不会注意和当前流程相关的引导，所以要在删除时进行提示和引导（不一定每次，但最起码是每次使用这个产品的第一次删除时）

d.所有用户在删除时都会看到这个提示和引导

所以饶了一个圈，本质上还是干扰和影响了全部的用户，那这种干扰和「删除前二次确认」比哪个更大呢？

一个是操作流程中的提示，一个是操作流程结束后的提示，大家可以想一想

2.开发成本

相比起调用一个模态对话框就能解决问题的「删除前二次确认」，和要写一堆代码才能实现的「删除后确认」，开发的成本是显然易见的。当然这里绝对不是想说开发懒（捂脸），但是在每次版本更新都会日赶夜赶，还有一堆需求做不完的情况下，这种非主要流程场景下的功能自然优先级会被降低，特别是没有看出来对用户有非常大的好处的情况下

那么是不是说其实还是应该用「删除前二次确认」呢？

不是，应该根据产品的具体情况进行分析。

以邮箱为例，web端的邮箱都会有固定的操作提示位置：提示条。在这种情况下用户在使用邮箱时会有一个稳定的提示点，在这个上面做“撤销”，对于认知成本和开发成本来说，都是非常低的，这就是适合做「删除后撤销」的情况

所以具体还是结合具体产品的认知成本和开发成本，才能说用哪个方式更合适