确认页的设计 - UCD大社区

令人费解的形形色色的确认对话框

novanewlife — 2009-03-05 08:19:38

在各式各样的对话框中，最常遇到的是那些要求用户对软件将要执行的某个操作进行确认的对话框。例如，当Google浏览器崩溃时，它会弹出如下的对话框要求用户确认：

在这个例子中，将要确认的操作比较简单明了，其描述语句也很简单，因此用户能够很容易地知道是选择“确定”还是“取消”。然而在很多时候，点击这两个按钮的含义需要在仔细阅读对话框中的描述后才能知道，这导致用户必须仔细阅读描述信息。例如，在使用Hotmail发送邮件时，如果首先选择了一个要作为附件发送的文件，当在文件上载还没有完成时就点击发送邮件按钮时，Hotmail会弹出如下的确认对话框：

这里的“OK”和“Cancel”按钮的含义就没有那么清楚了。实际上，正如描述信息中所述：点击“Cancel” 实际上是表示等待文件上载完成后在发送，而点击“OK”则表示立刻发送邮件，但是邮件中不会有附件。所以在这里，表面上是肯定含义的“OK”所引发的动作却不一定是肯定的。从发送邮件的角度来看，这个操作是肯定的，但从发送附件的角度来看则是否定的。

从这个例子中可以看出困难产生的原因了，表面上含义是肯定的那些按钮文字，例如“是”，“确定”所表示的实际含义却不一定是肯定的，它们只是表示对于对话框中所提的问题的答案是肯定还是否定。例如，假如问题是：“你要去上班，是吗”，如果答案是“是”，则表示要去上班。但如果问题是“你不去上班，是吗”，那么当回答是“是”时，则表示不去上班。（在英语中恰好相反）

所以如果所有的确认对话框的按钮文字只是表示对于问题的答案是肯定还是否定时，则用户就需要仔细阅读对话框中的问题后才能决定按哪个按钮。

下面就是一些有这种问题的例子：

实际上，对于这类问题的解决方案也很简单，那就是在按钮上多写几个字，简要地表明“是“，”确定“ ，”否“，等字眼的真正含义。下面就是一些好的设计的例子：

更进一步思考，为什么会产生哪些令人费解的确认对话框呢，我认为有两个可能的原因：

1. 用于显示这类对话框的最底层Windows API函数是 MessageBox, 其原型如下

MessageBox(

__in_opt HWND hWnd,

__in_opt LPCSTR lpText,

__in_opt LPCSTR lpCaption,

__in UINT uType);

其中 lpText 是显示在窗口体中的描述性文字， lpCaption 是窗口的标题文字，uType则用来指定会有哪些按钮显示：

MB_ABORTRETRYIGNORE

MB_CANCELTRYCONTINUE

MB_HELP

MB_OK

MB_OKCANCEL

MB_RETRYCANCEL

MB_YESNO

MB_YESNOCANCEL

例如MB_OK表示会有一个显示“OK”文字的按钮。显然，从这个API的调用中，程序员没有办法设置按钮的字，只能屈就于那些固定的几种词语。类似地，其他语言的用来显示对话框的API由于在最底层都是调用这个Win32 API，所以也不可避免地有这个问题。

2. 缺乏对于产品可用性的关注。

产品的设计是从里向外进行，而不是从外向里进行。换句话说，不是事先设计好界面应当显示何种信息及如何显示，然后考虑如何按照这个用户所能感觉到的设计去做内部实现时的设计，而是在完成内部的实现后，界面长成什么样子也不再关心了，要求用户去适应界面，不论有多难用。

确认页的设计 (一)

Heidi — 2009-05-03 21:28:31

以上的那个图，就是本文的主角：二次确认页，她的英文名是confirmation alert。

此文的背景：当时为什么想做这个二次确认页的研究，也是由于当时做的一个项目。当时那个项目出现了很多个二次确认页。

有很多人的意见：

“啥？删除地址也要二次确认？不用吧”

“这里为什么不确认一下呀？直接就提交了？填错了怎么办？”

“删除前，怎么不加个确认呀？”

“……”

确认页越来越多了，在最后大家看demo的时候，又一致觉得我们太罗嗦了。

究竟有没有一些原则和规范可以指导二次确认页的用法的？所以一边做项目，就一边进行一些分析了。最近在研究《windows vista UX Guide》，发现它里面的很多内容非常有营养，也对我之前纯原创内容进行了一些补充。于是分享分享吧，将原来的ppt做了一些摘选如下。

内容：

1. 什么是二次确认页（定义以及特征）

2. 什么时候用？

3. 形式的抉择？

4. 一些注意事项。

一，什么是二次确认页？

二次确认页其实就是Confirmation Alert，属于Alert家族中重要的一员。

英文定义：A confirmation is a modal dialog box that asks if the user wants to proceed with an action.

翻译成汉语大概就是：一个确认页是一种询问用户是否想继续执行某个动作的对话框。

二次确认页面的特点：

直接出现在用户刚刚发起的某个操作之后。
询问并确认用户是否想要继续之前的操作。
一般会包含一个简单的问题和两到三个操作。

二.什么时候用到二次确认？

二次确认的好处是：

减少误点击
避免动作中断时的损失（保存确认）
使操作更加慎重
安全性（有的二次确认还需要用户输入密码）

缺点是：

干扰了正常的操作流程，不恰当的多余的二次确认面还会让客户心生厌烦。
在一些鼓励的流程中，二次确认页还会形成巨大的漏斗效应，直接造成客户流失。

因此，白话大原则：

能不用就不用；——什么时候不能用？下文。
必要时才用；——什么是必要的时候？下文分解。
用了就让人明白。——怎么做？别离开，我们一起讨论一下。

什么时候用呢？

1. 保存确认（Save Confirmation）

例：填写表单中途离开，邮件写了一半关闭浏览器，文档未保存状态下点关闭。
确认的目的：避免误操作或损失。

2. 删除确认（delete confirmation）

例：开心网账户的删除（不能恢复），删除好友或文件等。

注意：并不是所有的删除都需要确认，例外情况有如：频繁的操作（如删除邮件），不重要的删除或者恢复成本较低。

3. 其他重要且后果不可逆的操作

例：淘宝的确认收货并同意放款，百度有啊的撤销退款协议。

确认的目的：告知后果使操作谨慎，避免误操作。

4. 重要且不推荐的操作

确认的目的：通过确认让用户更改选择。

最典型的例子莫过于淘宝的“评价确认”：

二次确认页的特征既然是存在两个以上的操作选择，所以当只存在一种选择的时候，无论页面长得再怎么像确认页，也不是。

例如以下的页面：

【系列文章】——待续：
确认页的设计（confirmation alert）（二）——二次确认页都有哪些形式，如何抉择？
确认页的设计（confirmation alert）（三）——一些使用中的注意事项

相关话题：确认页的设计源地址：http://heidixie.blog.sohu.com/115576055.html

确认页的设计 (二) - 形式的抉择

Heidi — 2009-05-12 23:13:01

你会看到很多种二次确认的形式。

本文或许不会涵盖到所有，只有最常见的（欢迎你随时提供案例哦）。

接下来的内容会按照以下目录组织：

1. 二次确认页有哪些形式（两个划分维度：设计角度与内容和功能维度）

2. 二次确认页的替代方案有哪些？

3. 如何选择不同的形式？

二次确认页的形式：

从设计角度划分：

1. 系统弹出框

2. lightbox（浮出层）

解释：Lightbox的效果类似于WinXP操作系统的注销/关机对话框，除去屏幕中心位置的对话框，其他的区域都以淡出的效果逐渐变为银灰色以增加对比度，此时除了对话框内的表单控件，没有其他区域可以点击。

3. 邮箱验证及手机验证码等替代形式

比如，偶要删除开心网帐号时，开心网给我发了一封邮件，让我点击邮箱里的链接来确认一定要删除。这种形式适用于比较重要的不可恢复的场合。

手机验证码确认的形式一般和资金相关，也用于比较重要的操作。

从内容和功能角度划分

这段资料来自于《windows vista UX guide》，为避免偶英文翻译有误，保留原文名称：

1.Routine confirmations(常规确认)

Confirm that the user wants to proceed with a routine, low risk action.

确认用户想要继续一个常规的，低风险的操作。

如图：

2.Risky action confirmations(风险操作确认)

Confirm that the user wants to proceed with an action that has some risk and can’t be easily undone.

确认用户想要继续一个有风险并且不容易撤销的操作。

图：

3.Unintended consequence confirmations（未预期的确认）

Confirm that the user wants to proceed with an action that has unexpected or unintended
consequences.

确认用户想要继续一个可能会导致意料外的结果的动作。

很多时候，确认页是建立在用户有明确的操作意向的时候，这种情况下，也许用户对后果是有预期判断的：删除就意味着后果就是删除。而若删除命令同时会导致别的意料之外的结果产生，那就是unintended consequence confirmation。

典型的例子：在多标签浏览器环境中，关闭浏览器，一般就会弹出一个确认框。

图：

4.Clarifications(澄清式确认、探询式确认)
Clarify how the user wants to proceed with an action that has potentially ambiguous or unexpected
consequences.
搞清楚用户想如何继续一个行为，而这个行为可能会导致预期外结果。

就好像在岔路口，导游说：好，我们继续走吧。你可能想反问一下：怎么走呢？向左还是向右？因为你担心右边可能会有打劫的埋伏。

UX guide建议除非确实认为这个行为可能会出现的多种结果中，不然就不需要这种澄清式的确认。

5. Security confirmations(安全确认)

Confirm that the user wants to proceed with an action with security consequences.

确认用户想继续执行一个会出现安全问题的动作。

这个大家很常见了吧：

6. Ulterior motive confirmations(别有用心的确认——汗，翻译成这样好像不太好吧)

我们需要记住如此多的形式吗？对我们的实际设计有什么指导意义？

其实这些形式也说明了一些使用场合，接下来会有一些注意事项，也是和这些形式紧密关联的。

二次确认页的替代方案：

我不喜欢二次确认页？有别的方法可以取代吗？

1. 防止出错——设置任务，用户在进行破坏性的操作前有前置任务需要完成。

比如，在我们最近的一个项目中，用户在点击某个button时，那个命令是需要被确认的，否则一旦误点击会造成不可恢复的后果。但是在点击下这个 button后，用户是需要填写一个表单的。在提交表单时，我们就发现没有必要再用一个二次确认。因为用户在填写表单的过程中是可以思考和反悔的，他既然愿意花时间和精力去填写表单，证明他确实想明白了。

2. 提供撤销操作（Undo）——gmail的undo

图：

3. 提供反馈，让不期望的结果显著化。

图：在支付宝的直接付款页面，点击radio button后已经使用提示告知了后果，因此点击下一步就不需要再次确认了。

4. 消除选择——往往需要被确认的是因为有两个或多个response（后续动作），可以认真想一下，是否一定有多个选择，如果仅仅剩下唯一一个了，那么就不需要询问了。

如果需要被confirm的选项不是很重要，干脆拿掉它。我特讨厌有些网站给你一个长长的表单，下面有两个button，一个提交一个清空。往往会不小心点击了清空，结果刚才忙活了半天的东西都没有了。要避免这种情况，当然你可以在我点击清空时给我一个确认，不过我更加期望把这个button拿掉。

设计形式的选择：

写这种文章真累。所以我想赶快结束掉这种苦差事，这里仅仅谈一下如何选择使用系统弹出框还是浮出层吧。

我发现自从有了浮出层，越来越多的web 2.0的网站抛弃了系统弹出框。开始使用lightbox（浮出层），当然，他们各有优劣，不能一概而论。

比如以下这种情况：

系统弹出层可以允许我挪开确认窗口以阅读“需要被确认的内容”。

而如果使用浮出层，会出现这样的效果：

挪都挪不开，怎么确认嘛？当然你可以把需要被确认的内容放到浮出层上，前提是有足够的信息承受量。

做了一张两者的优劣点表，供参考（直接截ppt的图了……）：

相关话题：确认页的设计源地址：http://heidixie.blog.sohu.com/115770463.html

确认页的设计 (三) - 一些注意事项

Heidi — 2009-05-12 23:14:13

白话大原则：

让我立马注意到——否则就没必要确认。
必须得与当前页面区分，凸显出来。所以一般二次确认页面弹出时，当前页面应该屏蔽使用。

让我不反感——除非想赶走客户。
视事件本身的严重程度采用适合的图标（信息、错误、问号）、措辞，视觉变化不至于太过突然。

让我一看就知道如何选择——稀里糊涂，词不达意的二次确认是最要命的
已经干扰了正常流程，再让用户在一个弹出页面上思考不知所措？
短句子，不兜圈，信达雅的文案，与文案相符的操作。

这些大原则有效的前提是：确实是必要的时机。——你的二次确认页真的是必要的吗？

注：以上大原则，heidi原创，不可照搬，谨防出错。

注意事项：

时机——确认是必要的时机（我怎么这么罗嗦呀）
形式——是不是采取了合适的形式（有哪些形式？），注意不要用二次确认页鱼目混珠，我看到很多网站把成功页面做成像二次确认页一样，居然还有个感叹号来警示用户“操作已经成功”……
文案——这个太重要了，呆会单独说。
icon——这个太重要了，呆会单独说。
出错控制——heidi在这里定义的出错控制是：二次确认页应该给出建议性的下一步操作，默认的动作。
结构——这个页面不需要太多创新，最保险的方式就是照顾用户已有的习惯，用主流的结构去呈现。

文案太重要了：

1. button的文案——需要让用户思考。

很多时候我们发现一个页面很莫名其妙，很不容易理解，仔细看看，原来是文案没有传达清楚。

如果二次确认页面也出现含糊不清，模棱两可的文案，那是最糟糕的事情。

大家看得明白下面三个二次确认页的区别吗？——资料来自《windows vista UX guide》

三者的区别在于button引导文案，先使用官方资料：

第一个二次确认页面：windows认为是不合理的二次确认页，因为它起不到该起的作用，因为用户本身就是通过点击“uninstall”操作看到这个页面，当他看到button上的文案还是“uninstall”的时候，他几乎不会去阅读二次确认的问题和描述，直接就会点击“uninstall”。而windows认为二次确认页至少是需要用户思考一下再做操作的（不然还真的没必要）。——Do make me think。

第二个二次确认页面：windows认为是合适的，使用yes和no作为button的文案，用户在点击前，至少会思考一下yes和no分别对应的后果，因此他会去看描述。

第三个二次确认页面：windows认为也是靠谱的。一个简单的anyway作用很大……体会一下。

Yes/No和OK/Cancel的button文案搭配大家似乎在英文站点上司空见惯了。好像是可以相互替代的是吗？

这是一个被我YY出来的案例，但是实际上确实存在着。现实生活中，某个人负责写二次确认页面文案，但是button上显示的文案有时却得走"规范"，统一使用YES或者OK(比如)，至于点击了button到什么页面是由设计师和工程师决定的。就会导致以上矛盾的情况：button和文案牛头不对马嘴，点击后却又是另外的情况……

2. 页面的文案——足够的信息讲明白后果。

你会经常被这种页面搞得很苦恼，你确定吗？你真的确定吗？你考验我的智力还是判断力还是耐力？

ICON可不能乱用呀：

icon很美观，似乎很多设计师总是想用一个icon点缀一下二次确认页。

但是我有时不明白，为何经常会出现一些不合时宜的icon倒了我的胃口。

即使不是二次确认页（向左侧的这个可怜的成功页面，却被用了警示的icon，实在匪夷所思）

所以，翻翻《windows vista UX guide》发现还是有一些有用的总结的：

《待续》

相关话题：确认页的设计源地址：http://heidixie.blog.sohu.com/116244919.html