删除后，需求就不再闭环了——异常流程总结第2弹！

删除的操作往往只需要用户点击一个按钮，但作为产品经理应当始终有一种“系统”的观念：删除掉一个对象并不是像从书架上抽走一本书，而是在玩层层叠叠的抽积木游戏——有些时刻，抽走的积木会导致一连串连锁反应，原本闭环的需求在删除一环后就不再闭环了。

前段时间我在【初级篇】扒一扒产品设计中的异常流程（1)一文中对常见的基础异常流程进行了总结，本文可以看作它的姊妹篇，聊聊近期我对【删除】的认知。

一、【删除】的基本设计细节

作为“增删改查”四大操作之一，对删除操作的基本设计大家应该都不陌生，这里简单地说下两种常见的删除交互。

1. 直接删除

直接删除即用户点击后直接生效，在我的经验中一般适用于删除后可还原的场景，比如在相册中删除照片后可在回收站找回。但目前在B端中我还没有遇到过这样的场景。

2. 用户确认后删除

在B端中二次确认后删除是更常见的场景，如删除后有不可恢复的影响，需通过文案告知用户。

其中批量删除时，可在文案中强调总数量或列出具体删除项清单，以供用户进一步确认，避免出错。

（图片来源：简道云）

二、【删除】的连锁影响

正如在前文中说过的那样，删除操作往往只需要用户点击一个按钮，此时页面上删掉的可能是一行记录，一个卡片，一个图标……但在看不见的地方，一个删除操作往往会引发连锁反应，因此设计之时需要格外慎重。

以下举两个我在工作中遇到的实例。

1. 删除的对象是否存在和其他元素的关联关系

在面向对象的设计思想中，类与类之间存在各种关系。以常见的关联关系为例，当我们要删除某一对象时，首先应该充分考虑这一对象和其他元素之间是否存在关联关系。

如果存在这种关联关系，就应当考虑删除它时这种关联关系要自动解除吗？这种关系是在哪里应用的？解除后会导致其他影响吗？用户在删除时知道自己的删除操作同时也产生其他“结果”了吗？

举例：

1）场景：生产设备挂在产线下，生产设备与产线存在n对1的关系，同时产线保存时的校验条件之一是“至少有一个生产设备，否则不允许保存”。假设A产线有且只有生产设备A-1，用户保存了该产线，那么删掉设备A-1后很显然就出现了一个“悖论”，按照逻辑推论此时产线A也需要被删除。

（图片来源：作者自制）

2）解决方式：从我个人的角度来看，用户只是删掉了一个设备，同时也没了一条产线，这一步子迈得稍微有点大，也就是说影响有点大，所以此时我会在文案中告知给用户这一情况，由用户自行去解除这一关联关系，之后再进行删除操作，当然这也是比较常见的一种处理。

（图片来源：作者自制）

2. 删除的对象是否产生相关业务数据

对一个对象执行删除操作，当这个对象会产生相关的业务数据时，需要考虑对该对象产生的历史数据是一并舍弃还是做保留。

举例：

1）场景：当前存在产品B，客户每日上报B的产量，假如现在要删除产品B，那么对B的历史产量数据要怎么处理呢？

2）解决方式：从场景思考，什么场景下用户会需要删除某个产品呢？如果只是对产品信息创建有误（如规格型号、单位等写错了），那么完全可以通过【编辑】进行修改，大概率是用不着删除的。

我唯一能想到的删除的场景就是某个型号的产品停产了，这家企业未来再也不生产这一产品了，那从这一角度着手的话很显然历史产量数据是不受影响的，因此删除这一产品后我倾向于保留它的历史产量数据。

以上是近期我在工作中遇到的删除场景，囿于工作经验，权当抛砖引玉了。那么，下一篇再见啦。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！