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

0 评论 3111 浏览 7 收藏 7 分钟

删除操作可能只需要用户点击一个按钮,但往更深处看,删除操作其实还会引发连锁反应。这篇文章里,作者聊了聊自己关于“删除”的理解,并分享了工作中遇到的案例,不妨来看一下。

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

前段时间我在【初级篇】扒一扒产品设计中的异常流程(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协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!