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

后者。两个主要原因：

1. 设计中要避免出现不可逆转的操作。

2.「删除前确认」这一操作易形成不假思索的肌肉记忆。

读过一些相关书籍的人应该很熟悉这一问题，其实很多很多的前人已经对此问题有过深入分析。

以下摘录自

第五章。

------------------------------------------------------------------------------------------------------------------------------------------

为了避免失误，计算机系统通常在执行某一指令之前，要求用户对该指令进行确认，尤其是那些能够破坏文件的指令。

但是这一要求出现的时机不对。它往往是在用户发出一项指令后就立即显示在屏幕上，然而用户在这时还并未意识到自己的操作失误。

下面是一段标准的人机对话：

用户：删除 “我最重要的工作” 这个文件。

计算机：你真的要把 “我最重要的工作” 这个文件除吗？

「是的。」

「你确信？」

「当然。」

「文件 “我最重要的工作” 已经被删除。」

「哎呀，真糟糕！」

用户让计算机删除了一个本该保留的文件，而计算机提出的确认要求不太可能防止这一失误。因为计算机让用户确认的只是一项操作，而不是文件名。

比较恰当的做法是避免设计出不可逆转的操作。比如说在上例中，计算机可以把刚刚除的文件时存放在某个地方，用户一旦发现自己误了某个文件，还可以将其恢复。

--------------------------------------------------------------------------------------------------------------------------------------------

在我曾经管理过的一个实验室，人们经常把文件或记录扔掉，第二天才发现被扔的东西还有用，于是后悔莫及。

为了解决这个问题，我们准备了7个纸篓，在每个纸篓上面写上星期几，也就是说，标有星期三的废纸篓只在星期三使用，到了星期三晚上就将这个废纸篓稳妥地存放起来，直到下个星期二才将里面的废纸倒掉。

后来发现，人们桌上的书和文件要比以前少多了，他们常会毫不犹像地扔掉自认为是无用的材料，反正现在扔东西很安全，即使出了也还有足够的时间把它拣回来。

然而，每种设计有其利弊。多出的6个废纸篓不仅占地方，还使我们与洁工之间发生了无休止的争执，因为他们总习惯在每天晚上把所有的垃圾都清除掉。

计算机中心的用户也对这些废篓产生了依心理，他们常把一些本该保存一段时间的文件不假思索地扔掉，万一清洁工或是我们自己在处理这些废纸篓时出现差错，麻烦可就大了。因此，在设计一个能够承受失误的系统时，最好将该项性能设计得可靠一些。

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

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

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

1.认知成本

2.开发成本

1.认知成本

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

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

我们梳理一下：

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

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

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

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

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

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

2.开发成本

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

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

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

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

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