删除操作可能隻需要使用者點選一個按鈕，但往更深處看，删除操作其實還會引發連鎖反應。這篇文章裡，作者聊了聊自己關于“删除”的了解，并分享了工作中遇到的案例，不妨來看一下。
删除的操作往往隻需要使用者點選一個按鈕，但作為産品經理應當始終有一種“系統”的觀念：删除掉一個對象并不是像從書架上抽走一本書，而是在玩層層疊疊的抽積木遊戲——有些時刻，抽走的積木會導緻一連串連鎖反應，原本閉環的需求在删除一環後就不再閉環了。
前段時間我在【初級篇】扒一扒産品設計中的異常流程（1)一文中對常見的基礎異常流程進行了總結，本文可以看作它的姊妹篇，聊聊近期我對【删除】的認知。
一、【删除】的基本設計細節
作為“增删改查”四大操作之一，對删除操作的基本設計大家應該都不陌生，這裡簡單地說下兩種常見的删除互動。
1. 直接删除
直接删除即使用者點選後直接生效，在我的經驗中一般适用于删除後可還原的場景，比如在相冊中删除照片後可在資源回收筒找回。但目前在B端中我還沒有遇到過這樣的場景。
2. 使用者确認後删除
在B端中二次确認後删除是更常見的場景，如删除後有不可恢複的影響，需通過文案告知使用者。
其中批量删除時，可在文案中強調總數量或列出具體删除項清單，以供使用者進一步确認，避免出錯。
（圖檔來源：簡道雲）
二、【删除】的連鎖影響
正如在前文中說過的那樣，删除操作往往隻需要使用者點選一個按鈕，此時頁面上删掉的可能是一行記錄，一個卡片，一個圖示……但在看不見的地方，一個删除操作往往會引發連鎖反應，是以設計之時需要格外慎重。
以下舉兩個我在工作中遇到的執行個體。
1. 删除的對象是否存在和其他元素的關聯關系
在面向對象的設計思想中，類與類之間存在各種關系。以常見的關聯關系為例，當我們要删除某一對象時，首先應該充分考慮這一對象和其他元素之間是否存在關聯關系。
如果存在這種關聯關系，就應當考慮删除它時這種關聯關系要自動解除嗎？這種關系是在哪裡應用的？解除後會導緻其他影響嗎？使用者在删除時知道自己的删除操作同時也産生其他“結果”了嗎？
舉例：
1）場景：生産裝置挂在産線下，生産裝置與産線存在n對1的關系，同時産線儲存時的校驗條件之一是“至少有一個生産裝置，否則不允許儲存”。假設A産線有且隻有生産裝置A-1，使用者儲存了該産線，那麼删掉裝置A-1後很顯然就出現了一個“悖論”，按照邏輯推論此時産線A也需要被删除。
2）解決方式：從我個人的角度來看，使用者隻是删掉了一個裝置，同時也沒了一條産線，這一步子邁得稍微有點大，也就是說影響有點大，是以此時我會在文案中告知給使用者這一情況，由使用者自行去解除這一關聯關系，之後再進行删除操作，當然這也是比較常見的一種處理。
2. 删除的對象是否産生相關業務資料
對一個對象執行删除操作，當這個對象會産生相關的業務資料時，需要考慮對該對象産生的曆史資料是一并舍棄還是做保留。
舉例：
1）場景：目前存在産品B，客戶每日上報B的産量，假如現在要删除産品B，那麼對B的曆史産量資料要怎麼處理呢？
2）解決方式：從場景思考，什麼場景下使用者會需要删除某個産品呢？如果隻是對産品資訊建立有誤（如規格型号、機關等寫錯了），那麼完全可以通過【編輯】進行修改，大機率是用不着删除的。
我唯一能想到的删除的場景就是某個型号的産品停産了，這家企業未來再也不生産這一産品了，那從這一角度着手的話很顯然曆史産量資料是不受影響的，是以删除這一産品後我傾向于保留它的曆史産量資料。
以上是近期我在工作中遇到的删除場景，囿于工作經驗，權當抛磚引玉了。那麼，下一篇再見啦。
本文由 @工凡 原創釋出于人人都是産品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。