删除前确认or删除后可以撤销?

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

看到知乎上这个问题的讨论,就想来说说自己的看法

http://www.zhihu.com/question/24298437

我必须得说,这要看情况

首先,讨论这个问题的前提条件是,第一种情况中的系统是可以支持用户删除后撤销的功能的。如果系统本身或者由于其他原因不能让用户撤销删除的话,这里的讨论就没有意义了。比如,电子邮箱里,删除在已删除邮件里的邮件这个操作,只要执行那么邮件就彻底从数据里消失,用户是无法寻回的,你能做的只能是在删除前,让用户确认一遍。

所以这里讨论的删除并不是从数据库中把数据完全移除,而是指是把数据存放在一个“不可用”的空间里。因此这里讨论的删除在很多开发人员眼中,不过是个“假删除”。

什么时候使用删除前需要确认?

1.预防误操作

删除这个操作,部分的使用场景下,对用户来讲是一个影响比较大的操作,也就是我们常说的“重度操作”。那么,为了防止不是使用者本意的操作高频率的发生,就很自然的增加一个确认步骤。

2.用户需要知晓操作的后果

一些业务规则下,用户并不清楚进行删除操作后,会发生什么事情,即使你提供了撤销删除的功能。所以有必要给出一个对话窗口,告知其后果并确认其操作。也许他们并不看,但总比你不说强。

3.撤销删除成本高,或者没有对用户开放

淘宝的订单里有一个订单回收站的功能,不知道大家有没有概念。反正今天我是为了回答这个问题,才仔细的去看了看才知道,并且入口并不是很明显。另外一些网站系统中,用户删除的数据是有留存的,但是一般就不会再呈现给用户看了。

什么时候使用删除后可以撤销的方式?

如果一个删除操作满足以下的条件,我认为可以考虑采用删除后可以撤销的方式。

1.删除这个操作对用户来讲影响不大,是个“弱操作”。

2.删除这个行为需要经常发生。

3.用户有预期可以撤销删除,并且知晓该如何操作。

4.撤销删除的操作的成本。

比如邮箱中的删除邮件操作。在用户已知晓怎么找回邮件的前提下,删除操作是一个“弱操作”,并且清空一下收件箱对一些强迫症用户来讲,是一件很爽的事情。所以一般删除邮件时是没有确认的。

如下图,Gmail中是直接删除邮件会话,不给确认的,但是会及时给出撤销入口

在来看,qq邮箱中也是如此,对于一般的邮件删除,也是直接删除的

但是对于几乎不可逆的彻底删除,则是删除前确认

再比如,苹果的mac操作系统中,是没有删除文件的操作,取而代之的是【移到废纸篓】操作,并且此操作是没有确认对话框的。这里的操作名本身,就给予对废纸篓有些了解的用户较为明确的可撤销的预期。

实际项目中如何来判断使用哪种方式?

把你基于当前技术和业务规则条件下的,要告诉用户的事情,用嘴说或者用文字写的方式描述出来。然后采用删除前确认和删除后可以撤销的不同的方式来比较一下。侧重比较和分析用户是否对可撤销有概念。然后在后续的可用性测试中,着重访谈用户的情绪变化,比如,是否有突兀感,不自由,不安全感等。

但老实说,这里的判断我主要依靠“感觉”,我感觉依据是把你当前的设计方案,转化成为一段对话,然后尝试从一个用户的角度来看这段对话,是否把该说清楚的事情讲清楚了,是否让对方觉得你很贴心,很聪明。

我举例苹果操作系统mac和微软的windows系统中的删除操作

mac中:

我要把这个文件从我的桌面删除。

哦,这里只有【移到废纸篓】的操作,我想起来了,刚开始用mac的时候,我学习到可以把文件扔到废纸篓,并且可以找回。

好吧,我就进行【移到废纸篓】的操作。

删除操作完成。

windows中:

我要把这个文件从我的桌面删除。

哦,发现了【删除】操作,我点击了该按钮。

咦?一个对话框出来了告诉我:

(确实要把此文件放入回收站吗?

恩,我以前学习到,【删除】的意思就是把文件放到回收站中,并且可以找回。)

好吧,我确认此操作。

删除操作完成。

显然mac的操作更加流畅,但前提是用户对废纸篓有概念。pc的做法虽然繁琐一点,但是符合用户的初始认知模型。我要删除,就给删除操作,在后续弹窗中解释删除意味着什么,然后要求用户确认操作。mac很聪明,但是你同时也必须“聪明”一点。pc有点繁琐,但是确实照顾了更大范围的用户。

所以不同项目中怎么做,真得看情况。

作者:德川亮;via:简书

您的赞赏,是对我创作的最大鼓励。

评论( 1

登录后参与评论
  1. 基本上从windows有了回收站功能之后,这个交互一直是比较稳定的,
    一般用户:
    直接删除,直接删除进入回收站。
    回收站删除,确认,完全删除。
    高级用户
    按shift删除,确认,直接删除
    按Ctrl+Z 撤销回收站删除

    回复
加载中