备忘录|深度解析：删除操作设计( 三 )_

1. 确认弹框这是最常见也最广泛的一个步骤，用于确认当前的操作。事实并非所有的操作均需要确认。

文章插图
根据删除对象的重要程度，我认为第一重要区的对象一般需要确认，第二重要区的对象可不确认，第三重要区的对象无需确认。
以上也并非绝对，例如第一重要区的，用户拍摄的图片，由于其更新频率高且有回收站的情况下，可减少操作不必确认。
例如，菜鸟裹裹为例，左滑列表显示删除，点击删除弹出确认菜单，点击删除后即完成删除操作。

文章插图
其删除的内容属于第三重要区，通过左滑显示删除的方式，再次弹框提示，过于繁琐。
2. 删除后提供撤销撤销Toast形式适合于误删或删除后立刻后悔时，可在几秒内选择撤销。这种在安卓原生系统中比较常见。
文件类的应用提供回收站等撤销服务。这两种方案均未得到广泛应用，认知成本和开发成本较高，且并非解决根本问题。
机器永远是做机器即可，不必牵强附会。可以给用户容错的机会，容错是个无底洞，即使容错99次，总有用户犯第100次。因此撤销并不是一个优质需求。
其中在创作类和编辑类软件中，撤销仍是一个关键的功能，这并不冲突，反而是客观辩证的看待问题。
3. 已删除提示当删除完毕，经常看到会有一些Toast提示“已删除”。“已XXX”这是汇报性性文字。Toast的形式对用户操作的打断相对弹框较弱一些，但是对于用户的高效生活来讲，仍会有一定干扰。
若删除操作和对象均在本界面可见范围内，删除内容界面会进行更新，则无需Toast汇报。
若某些操作和对象在本界面操作，却在其他部分产生影响，则需要Toast汇报。
例如，在微信中下载一张图片，保存的位置会通过Toast显示，这种情况，是将图片存在其他界面的某个文件夹中，告知详情有必要。
六、结语【备忘录|深度解析：删除操作设计】产品与交互区别之一在于，产品定义功能，交互完善体验。一个功能设计看似简单，实则不然。我希望当别人问我们为什么这样设计时，能有理有据。接下来我会把普通的功能，通过深度分析系列，逐一剖析展现，在体验路上能一步一个脚印前行。
本文由 @张宁宁原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议