确认框的设计

2011-07-27 21:28

确认框,顾名思义,对关键的用户行为进行确认,比如“询问是否删除”,“告知已删除”。根据网上的观察,发现有的网站对确认框的设计缺乏合理性。本文谈谈自己的思考。

类别

根据触发目的,确认框分为两类:询问和告知。

询问

转推的确认框

转推的确认框

询问,类似 Javascript 里的 confirm(),即:是否去做?

告知

Flickr 的告知

Flickr 的告知

告知,类似 Javascript 里的 alert(),即:做的状态。

必要性

任何阻碍(打断)用户行为的动作,都应该三思而后行。冷静下来,我们真的、一定、必须打断用户的动作吗?不妨思考下面三个问题,来考量“必要性”。

行为是否主动

  • 是。既然是用户自己主动做了这个决定,那么确认框有设计过度之嫌
  • 不是,但用户容易误操作。先解决“误操作‘的问题,再来谈确认框吧
  • 不是。剔除确认框

结果能否挽回

  • 不能。真的不能吗?难道不知道这对于用户来说非常重要吗
  • 真的不能。使用确认框
  • 能。剔除之

信息可否忽略

  • 不可以。真的不可以吗?流程上不能再优化了吗
  • 真的不可以。使用确认框
  • 可以。剔除之
必要性(上新浪微博,下腾讯微博)

必要性(上新浪微博,下腾讯微博)

两大微博都只能最多添加10个标签,超出限制后,它们的确认框如上。孰优孰劣?

设计

做确认框,就要保证其可用性。

可控

根据可控的程度分为:原生和弹出层两种。

Javascript 原生类型

JS 代码原生的 confirm() 确认框好处只有一个,那就是编码方便。弊端有:

  • 样式因操作系统(和浏览器)而异
  • 体验无法与全站融洽
  • 无法更改按钮文案和样式
  • 没有档次
  • 没有情感

弹出层类型

注意:这里谈的不是弹出层,而是弹出层类型的确认框。

弹出层,因为是纯手工编写,完全可控,宏观上有:

  • 遮罩。使用遮罩,因为确认框里的内容很重要。颜色则取决于网站的情感基调,与重要性无关(因为真的很重要);保持遮罩层颜色的统一
  • 位置。相对居中
  • 标题。不设置标题
  • 内容格式。左对齐,具体格式依内容而定
  • 按钮格式。居中或右对齐
  • 图片。没有,或者最多一个
  • 移动。可以移动,并保持滚动
  • 退出响应。必须点击某个按钮才能做出相应响应,因为确认框很重要。同理,不设置右上角的 “×”
  • 快捷键。可以考虑,记得照顾视觉障碍的用户

文案

不多一个字

  • 说匹配用户教育程度的语言
  • 写出文案后,逐字删除,除非造成歧义
  • 照顾用户的情感。这里多一个字,胜一万字

条理清晰

  • 格式清晰
  • 逻辑清晰

是的,有时候脑袋一热,逻辑就乱了。清晰的格式有助于理顺(自己和用户的)逻辑。

注明后果

再说一遍,真的很重要。

不使用判断词和代词

仅仅写“是”和“否”不如写“删除”和“取消”直接。

按钮

摆放

Flickr 混乱的按钮顺序

Flickr 混乱的按钮顺序

我们习惯说“是否”,我们说“Yes or No”,那么,就按照这个顺序来设置按钮的摆放顺序。(反过来也行,)务必在全站统一,不要一会左一会右,你叫用户点哪?

样式

  • 与全站按钮的样式统一。不推荐使用 HTML 内置的 <input type="button"> 按钮,毕竟已经到这一步了,再多做一点吧
  • 分清主次。鼓励用户点击的按钮使用突出 / 鲜明的颜色,反之使用常色,或者干脆使用文字链接的形式
“取消”按钮看上去就不能点

“取消”按钮看上去就不能点

  • 避免使用灰色。因为灰色看上去无法点击。白色亦不赞同

选例分析

选取了三个“拖入到黑名单(阻止该人)”的例子。

正例1

豆瓣:把某人拖黑

豆瓣:把某人拖黑

亮点:

  1. 不多一个字
  2. 逻辑清晰
  3. 注明后果
  4. 确定=确定,避免了不能改动按钮文案的硬伤

正例2

谷歌+:阻止某人(把某人拖黑)

谷歌+:阻止某人(把某人拖黑)

亮点:

  1. 囊括了豆瓣的全部亮点
  2. 体验统一
  3. 格式清晰
  4. 分清主次(更推荐使用醒目的红色)
  5. 不使用代词
  6. 可以挽回
  7. 通过照片唤起情感

反例

知乎:把某人拖黑

知乎:把某人拖黑

延伸阅读

  1. 墨茶 《“确定”与“取消”按钮:如何正确排序?》 http://ucdchina.com/snap/1078
  2. 小轰 《可用性案例分析》 http://cuikai-wh.com/blog/1543

最后更新:2011年07月28日

20 条评论 / 引用:

  1. 确认框的设计 « 太阳照常升起:

    […] View full post on 时光立方 […]

  2. SP2:

    个人觉得flickr那个并不混乱,该高亮的高亮了,左右换一下更有助于你意识到这是一个什么action。

  3. 匿名:

    信息与时俱进啊

  4. 小轰同学:

    @匿名
    哈哈,谢谢。

  5. piggy_Yu:

    一直很喜欢 绿色的 yes 红色的 no, 可以算的上是经典 色了。

  6. Krouky:

    格式清晰地提示语很给力,刚好这两天设计的时候遇到类似情况.

  7. MarshallChen:

    欣赏G+的设计

    PS:该博回复框里的确认按钮“写好了,发布出去”的风格用的是默认样式啊 没有与回复框风格统一。 小瑕疵

  8. 匿名:

    蛮人性化的说~

  9. 小轰同学:

    @MarshallChen
    说得对,我来改进下。

  10. 匿名:

    最后的正例中:产生的效果是否需要次次显示给用户?如果入户已经了解屏蔽某人的效果,如何不再显示这个信息?
    PS:正例2的按钮描述要好于正例1,因为用户在看了很长的叙述之后,有可能不知道自己该点“确定”还是“取消”,用户更容易理解和自己行为目的相似的叙述。

  11. Steven Kwok:

    说得到位。。
    PS。不能阻止我们的willian long哦,呵呵

  12. 小轰同学:

    @匿名
    需要,因为运营并不鼓励用户拖黑,而且用户将他人拖黑也不是一件频繁的事。即便用户足够了解,亦可以起到“威慑”的作用。

  13. vina:

    flickr的确认取消的位置其实并不混乱,由于鼠标右手的关系,最主要操作一般放在最右边。而且和google+的阻止联系人确认框也正好不谋而合。

  14. 南山:

    如果把确定按钮做大一点,取消做小一点
    那么点确定按钮的人就会多一些
    我猜想

  15. Allence:

    “我们习惯说“是否”,我们说“Yes or No”,那么,就按照这个顺序来设置按钮的摆放顺序。(反过来也行,)务必在全站统一,不要一会左一会右,你叫用户点哪?”

    YES在左,NO在右,是继承常用的操作系统,这没歧义。
    至于Cancel在左,Delete在右,这个我想因为他是Flickr,他是做图片站的,根据上则的用户习惯,他们宁可你多操作一步,也不愿你错删一张,他的意图很明晰,就是为了不让你习惯性的点“删除”

    符合规范设计和利于产品发展的取舍我想很容易选择,有时我们做设计,不能一开始就把规范钉死,用户可不考虑你是不是规范设计

  16. 贪睡小蚂蚁:

    微薄转发的那个例子和正例2(谷歌+)2个例子之间如何取舍?

  17. 小轰同学:

    @贪睡小蚂蚁
    推特和谷歌+都是灰色的按钮,但和新浪微博不同的是,它们灰色的按钮在悬停和按下时有明显的样式变化。
    新版的新浪微博,已经去掉了”取消“按钮 🙂

  18. 魔胖:

    推荐一本书《web表单设计:点石成金的艺术》

    掩面跑开~

  19. 小轰同学:

    @魔胖
    谢谢同学的鼓励,已经把本书纳入到清单 🙂

  20. 确认框的设计 | ued吧:

    […] http://ucdchina.com/snap/1078 小轰 《可用性案例分析》  文章来源:时光立方 转载请注明出处链接。 此条目由 admin 发表在 未分类 分类目录,并贴了 […]

评论

《对话守则》第一条:对话的目的是寻求真理。

以下选填: