「刪除前確認」和「刪除後允許撤銷」兩種處理方式哪個更好？

12-13

似乎大部分答案都傾向於「刪除後撤銷」

第一反應確實應該是「刪除後撤銷」好一點，因為不管是「刪除前二次確認」還是「刪除後撤銷」都是為了「誤刪」這個場景的，但是顯然這個場景並不是經常出現的一個場景，而如果用「刪除前二次確認」的方式，等於讓所有用戶在所有刪除場景下都要被打斷；用「刪除後撤銷」只會影響到誤刪場景下的用戶，正常使用的用戶則不會收到干擾和影響

但是為什麼現在大部分的互聯網產品還是使用「刪除前二次確認」的方式？因為「刪除後撤銷」是有成本的，成本有兩點：
1.認知成本
2.開發成本

1.認知成本
如果我問你，刪除後的撤銷入口應該放在哪裡，你一定答不上來，因為你在腦袋裡檢索了以前所有使用過產品的撤銷功能入口，一定是放哪都有：有在提示條上做撤銷的；有在刪除的位置上直接放個撤銷的；有專門弄一個最近刪除列表，在上面做撤銷恢復的……

放哪都有意味撤銷入口並沒有一個標準，一個應該放哪裡的標準，這也意味著每進到一個新產品，用戶都需要重新認知撤銷的入口在哪；而需要讓用戶能夠認知到撤銷入口（總不能誤刪了找不到怎麼撤銷吧），勢必又要增加引導，加強用戶的感知，而加強了感知，其實也就是分散了所有正常使用用戶的注意力

我們梳理一下：
a.因為沒有標準，用戶不知道撤銷入口在哪
b.需要加強引導讓用戶知道撤銷入口在哪
c.考慮到用戶在不是誤刪的情況下一般是不會注意和當前流程相關的引導，所以要在刪除時進行提示和引導（不一定每次，但最起碼是每次使用這個產品的第一次刪除時）
d.所有用戶在刪除時都會看到這個提示和引導
所以饒了一個圈，本質上還是干擾和影響了全部的用戶，那這種干擾和「刪除前二次確認」比哪個更大呢？
一個是操作流程中的提示，一個是操作流程結束後的提示，大家可以想一想

2.開發成本
相比起調用一個模態對話框就能解決問題的「刪除前二次確認」，和要寫一堆代碼才能實現的「刪除後確認」，開發的成本是顯然易見的。當然這裡絕對不是想說開發懶（捂臉），但是在每次版本更新都會日趕夜趕，還有一堆需求做不完的情況下，這種非主要流程場景下的功能自然優先順序會被降低，特別是沒有看出來對用戶有非常大的好處的情況下

那麼是不是說其實還是應該用「刪除前二次確認」呢？
不是，應該根據產品的具體情況進行分析。
以郵箱為例，web端的郵箱都會有固定的操作提示位置：提示條。在這種情況下用戶在使用郵箱時會有一個穩定的提示點，在這個上面做「撤銷」，對於認知成本和開發成本來說，都是非常低的，這就是適合做「刪除後撤銷」的情況

所以具體還是結合具體產品的認知成本和開發成本，才能說用哪個方式更合適

後者。兩個主要原因：
1. 設計中要避免出現不可逆轉的操作。
2.「刪除前確認」這一操作易形成不假思索的肌肉記憶。

讀過一些相關書籍的人應該很熟悉這一問題，其實很多很多的前人已經對此問題有過深入分析。
以下摘錄自The Design of Everyday Things第五章。

------------------------------------------------------------------------------------------------------------------------------------------
為了避免失誤，計算機系統通常在執行某一指令之前，要求用戶對該指令進行確認，尤其是那些能夠破壞文件的指令。

但是這一要求出現的時機不對。它往往是在用戶發出一項指令後就立即顯示在屏幕上，然而用戶在這時還並未意識到自己的操作失誤。

下面是一段標準的人機對話：

用戶：刪除「我最重要的工作」這個文件。
計算機：你真的要把「我最重要的工作」這個文件除嗎？

「是的。」
「你確信？」
「當然。」
「文件「我最重要的工作」已經被刪除。」
「哎呀，真糟糕！」

用戶讓計算機刪除了一個本該保留的文件，而計算機提出的確認要求不太可能防止這一失誤。因為計算機讓用戶確認的只是一項操作，而不是文件名。

比較恰當的做法是避免設計出不可逆轉的操作。比如說在上例中，計算機可以把剛剛除的文件時存放在某個地方，用戶一旦發現自己誤了某個文件，還可以將其恢復。

--------------------------------------------------------------------------------------------------------------------------------------------
在我曾經管理過的一個實驗室，人們經常把文件或記錄扔掉，第二天才發現被扔的東西還有用，於是後悔莫及。

為了解決這個問題，我們準備了7個紙簍，在每個紙簍上面寫上星期幾，也就是說，標有星期三的廢紙簍只在星期三使用，到了星期三晚上就將這個廢紙簍穩妥地存放起來，直到下個星期二才將裡面的廢紙倒掉。

後來發現，人們桌上的書和文件要比以前少多了，他們常會毫不猶像地扔掉自認為是無用的材料，反正現在扔東西很安全，即使出了也還有足夠的時間把它揀回來。

然而，每種設計有其利弊。多出的6個廢紙簍不僅佔地方，還使我們與潔工之間發生了無休止的爭執，因為他們總習慣在每天晚上把所有的垃圾都清除掉。

計算機中心的用戶也對這些廢簍產生了依心理，他們常把一些本該保存一段時間的文件不假思索地扔掉，萬一清潔工或是我們自己在處理這些廢紙簍時出現差錯，麻煩可就大了。因此，在設計一個能夠承受失誤的系統時，最好將該項性能設計得可靠一些。

後悔葯永遠比再思考來的強。

如果是在說文件管理，並且二者互不相容的話，後者更好。
「刪除前請求確認」的作用基本上完全被局限在防止誤操作，即防止用戶誤觸 Delete 鍵。
「刪除後允許撤銷」除了可以防止誤操作，更允許對正確操作的「反悔」。

其實這兩種刪除的著眼點有區別

刪除前確認動作意在防誤觸，而刪除後允許撤銷意在允許反悔，給你復原的可能性。

如果解決方式妥善的話，這兩種方式是可以並存的。

例如可以加長化刪除手勢使得刪除依然是一步完成，只是由於手勢特殊使得誤觸幾乎不可能在你無意識的情況下發生。
同時提供一種依然是一步完成，但需要手勢折向（例如L字形），滿足那些想要一步刪完東西也不想被確認所煩的人。

其實，所謂的確認，由於特殊手勢（或者按鍵組合）的存在，在你的大腦中已經過了一遍，無論從哪個層面上看，打斷人操作的「確認」選項都是多餘的。

以上兩步當然還需要開發者提供自然的用戶引導，例如
正常狀態——普通刪除——強制刪除（不可恢復）

普通刪除後的東西依然提供可以找回的方式，具體怎麼操作那就是另外一件事情了。

如果真的要刪除：

前者需要兩次操作
後者需要一次操作

如果不需要刪除：

前者需要兩次操作
後者需要兩次操作

所以總體來說還是後者較為省操作數。（感謝 @張一休提醒）

我的想法是：

對於私人的任何東西，直接刪除最好，這也是最為自然的方式；對於刪除操作會立即被 Publish 並導致他人受影響的，先提示吧。

突然明白為什麼我喜歡上mac的刪除方式了。

以下只討論刪除設計的區別。

Mac

-刪除快捷鍵command+delete
-無詢問，直接丟廢紙簍，有提示音
-廢紙簍無空間上限，誤刪可恢復
-傾倒廢紙簍前需要確認。快捷鍵command+shift+delete。只傾倒廢紙簍，不會用來直接刪除文件。

對比win：

-刪除快捷鍵delete，默認需要確認，確認後丟進回收站。
-徹底刪除快捷鍵shift+delete，默認需要確認，無法恢復。
-沒有清空回收站的快捷鍵。
-回收站默認有10%的分區大小上限。

我從瘟3.2一直玩到瘟8，win下刪文件的機制基本沒有變過。而且自從我知道了shift+delete後，回收站的利用機會幾乎是0，因為我討厭選擇多選擇一次是否。但這也讓我誤刪過很多東西。原因如排名最高的答案所述，肌肉記憶。隨手就按了回車確認刪除。
沒錯，回收站可以設置，但我懶。更別說多少初級用戶連回收站可以設置都不知道。
況且刪除前不要確認，萬一某天腦抽無意碰了delete不是費事？

(14/07/07更新：我把刪除無需確認的選項打開了，發現刪到回收站不需確認，但清空回收站還需要確認。但是……現在刪U盤上的東西也不需確認了啊！！！U盤沒回收站啊！！！尼瑪！！！)

換用mac前我只知道要把文件拖廢紙簍刪除並打開清空，我覺得很費事，不高效。
但會了快捷鍵之後，真的是兩重天。
command+delete可以保證不會因為誤按而錯刪，而且丟廢紙簍不需要額外確認，「咔噠」的提示音聽起來也特別爽。
雖然沒有win下的shift+delete直接強刪，但是有了全局的清空回收站快捷鍵。在一陣咔噠聲中丟了一堆文件，然後直接command+shift+delete清空。啊——真爽。熟悉後效率不次於win下的shift+delete，而且發現刪錯了還多了一步後悔葯。

win對比mac的其他就不提了，就討論關於刪除方式的優劣而已。

對了，還有多少人和我一樣自從會用shift+delete後就把回收站束之高閣了？

就不能都有嗎？

一般情況下，不同的用戶群，不同的使用場景，不同的條件，不同的業務邏輯，都需要不同的設計，所以沒有更好的設計，只有更合適的設計。

需要確認的情況：

刪除後，對外界/他人產生重大影響的情況下，撤銷是不能完全彌補的，所以，刪除前需要確認，防止誤操作等。比如，網站後台，系統管理中的刪除。
非常嚴肅的刪除，撤銷會影響嚴肅性，需要刪除前確認。比如賬號刪除。

適合撤銷刪除的情況：

私人的東西，刪除後沒啥太大影響，刪除前確認提高了決策給用戶帶來的壓力
大量頻繁刪除，刪除前確認會很影響效率。

當然，也會有情況，既需要刪除前確認，也需要撤銷刪除。

後者。
最大程度減輕了用戶思考這個東西刪不刪的難度。
隨便刪，反正可以恢復。

得看是什麼項目吧，具體問題具體分析
沒聽說過沖了點卡後悔了退錢的

簡單來說
1. 避免用戶的誤操作完成不可逆的損失。
2. 對可逆操作降低用戶的操作成本。
2.1 恢復較麻煩的(比如批量刪除)，事前確認。
2.2 無數據損失風險又容易恢復的允許事後撤銷。

出於保護整體數據完整性的考慮，一般設計功能的時候我是不提供物理刪除的，只提供邏輯刪除，這時刪除操作是可逆的，提供撤銷操作按鈕即可，內容的話可以放回收站，有撤銷多步需求時可以提供操作日誌。

有時我們很多不可逆的操作，比如格式化硬碟和更改數據，如果數據本身不很重要，讓用戶確認下即可；如果數據極為重要，我會強制用戶輸入大寫的OK(或者隨便啥)來確認操作。

win8除了對雙屏的支持比較好，唯一的優點就是刪除進回收站時不需要確認了。(大誤)

分別應用在兩種不同的場景，分別是刪除可逆和不可逆。這個度衡量地很微妙，比如用戶人信息、簡訊可放入回收站，而文件則直接刪除。具體情況，具體分析吧。

win8現在就是兩種方式並存，合適的方法用在合適的時候啊。
普通的較大的我清楚完全沒用了的就直接shift+Del了，彈出個提示也不用考慮直接順便敲個回車。
而刪除普通的文件就直接Del了，不提示放入回收箱我也不用管，過段時間清理一下就好啦。
沒有更合適的方法，只有更便捷的使用

我認為是前者。
可能有點跑題。

刪除前確認，很像註銷前確認，確認後賬號無法恢復，比如豆瓣。
刪除後允許撤銷，很像註銷後還可以恢復賬號，比如人人網。

對於人人網，我有很多次很隨意地就註銷了，因為隨時可以恢復，我知道那些照片啊，狀態啊不會丟，只要恢復賬號就還能看到。
對於豆瓣，很長一段時間都特別想註銷，因為成天上浪費時間，但是就是不敢，因為註銷了裡面的東西就再也找不到了。

對網站來說，「刪除前確認」可以幫他們留下更多的用戶和內容。
對用戶來說，
「刪除前確認」，在確認前的那一秒，他們就會知道自己是不是真的想刪除。

因為怕失去，所以才更加珍惜。

在下傾向於
文件：「刪除後允許撤銷」

理由：
假設某天小明看到自己的相冊里有一張暴露黑歷史的照片，看到之後務必尷尬渾身難受
於是他決定刪之而後快
果斷點擊了「刪除」
本以為大功告成的他發現面前多了一個彈窗：
【你真的要刪除嘛？】
設身處地想想小明的心情……

如果是一鍵刪除之後，彈出提示
【刪除成功，你可以在回收站找回誤刪的文件】
就會友善而高效很多吧

「生米煮成熟飯前確認」和「讓煮熟的鴨子飛」哪個更厲害一些呢？

對於經過深思熟慮思考地操作採用前者，比如刪除好友。
而其他可能存在誤操作地刪除，比如郵件，文檔採用後者。

破鏡難圓，覆水難收。
也許選項二在工作中給你提供了方便，提供了退路，包容了你在煩躁時、疏忽時的一時衝動和不假思索，卻也縱容了你那一點點的恣意疏狂和不負責任。在工作中你面對著屏幕敲打著鍵盤你有選項二，可是在生活里，你徘徊在喧鬧的霓虹街頭，迷醉在激光燈下的慾望嘶吼，你腦海里回放著她那讓你捨不得放不下的嬌媚容顏，又或者是他那讓你看不慣忍不了的醜惡嘴臉，於是你第一次在車流熙攘的江橋上聽潮聲，第一次站在24層的公寓樓上看夜景，第一次閱讀安眠藥的用法用量，第一次在意水果刀用的是不是不鏽鋼...可是你忘了一個問題，生活中沒有一個可恢復的回收站。
所以，也許去掉選項二，我們的工作會平添諸多羅亂，但也許假以時日，我們的生活會還你一片清明

後者。因為這樣能真正看到刪除之後的結果再做決定。