APP产品设计关于删除操作的处理

 

我们设计一款APP应用，无论是前端还是后台，都可能会用到删除操作。今天我们就来讨论一下这个设计上的小细节的处理。

通常情况，我们在删除某项内容的时候，都会提示用户是否确认删除。如果觉得弹出提示会影响用户操作，可以在删除后增加撤销删除的功能。这两种做法各有什么不同呢。

首先，讨论这个问题的前提条件是，第一种情况中的系统是可以支持用户删除后撤销的功能的。如果系统本身或者由于其他原因不能让用户撤销删除的话，这里的讨论就没有意义了。比如，电子邮箱里，删除在已删除邮件里的邮件这个操作，只要执行那么邮件就彻底从数据里消失，用户是无法寻回的，你能做的只能是在删除前，让用户确认一遍。
所以这里讨论的删除并不是从数据库中把数据完全移除，而是指是把数据存放在一个“不可用”的空间里。因此这里讨论的删除在很多开发人员眼中，不过是个“假删除”。

什么时候使用删除前需要确认?
1.预防误操作
删除这个操作，部分的使用场景下，对用户来讲是一个影响比较大的操作，也就是我们常说的“重度操作”。那么，为了防止不是使用者本意的操作高频率的发生，就很自然的增加一个确认步骤。
2.用户需要知晓操作的后果
一些业务规则下，用户并不清楚进行删除操作后，会发生什么事情，即使你提供了撤销删除的功能。所以有必要给出一个对话窗口，告知其后果并确认其操作。也许他们并不看，但总比你不说强。
3.撤销删除成本高，或者没有对用户开放
淘宝的订单里有一个订单回收站的功能，不知道大家有没有概念。反正今天我是为了回答这个问题，才仔细的去看了看才知道，并且入口并不是很明显。另外一些网站系统中，用户删除的数据是有留存的，但是一般就不会再呈现给用户看了。

什么时候使用删除后可以撤销的方式?
如果一个删除操作满足以下的条件，我认为可以考虑采用删除后可以撤销的方式。
1.删除这个操作对用户来讲影响不大，是个“弱操作”。
2.删除这个行为需要经常发生。
3.用户有预期可以撤销删除，并且知晓该如何操作。
4.撤销删除的操作的成本。
比如邮箱中的删除邮件操作。在用户已知晓怎么找回邮件的前提下，删除操作是一个“弱操作”，并且清空一下收件箱对一些强迫症用户来讲，是一件很爽的事情。所以一般删除邮件时是没有确认的。