程式师的使用介面设计手册第六章:为节省大家的麻烦所作的设计

作者:周思博(Joel Spolsky)
译:Paul May 梅普华
Wednesday, April 26, 2000 A part of Joel on Software, http://www.joelonsoftware.com

当你在设计使用介面时,最好能记住两个原则:

1. 使用者是没用手册的,即使他们有手册也不会去读。
2. 事实上使用者是不会去读任何东西的,就算有东西可以查他们也不想去查。

严格讲起来这并非_事实_ ,不过你应该假设这是事实并照着去做,因为这样能让你的程式更容易而且更亲近使用者。设计时心存这个想法就叫做_尊重使用者_ ,意思就是不要太尊重使用者。看不懂吗?让我来解释吧。

怎么样才算是让东西_容易使用_ 呢?度量方法之一就是看看真实世界中的使用者有多少比例能在指定时间内完成工作。举例来说,假设你程式的目的是让人们把数位相机的照片转成网路相本。你可以找些一般使用者来,请他们用你的程式完成这项工作。如果你的程式愈 _好用_ ,就会有愈多的使用者能成功地建立一个网路相本。用科学的方法来说,就是假设有100个真实世界的使用者。他们不一定要熟悉电脑。他们各有所长,不过其中有些人是 _不太会_ 用电脑的。有些人在用你的程式时还会分心。电话会突然响起。喂。什么?小孩在哭。什么?猫跳上桌子追老鼠。我听不清楚啦!

虽然我没有看着这个实验进行,我有相当的把握敢说,有些使用者就是无法完成工作或者要花非常长的时间才完成。我并不是说这些使用者是_笨蛋_ 。相反的他们可能非常聪明,他们也可能是很高超的运动员,不过对_你的程式_ 而言,他们就是无法把他们的运动技巧和脑细胞用上去。你可能只抓住他们30%的注意力,所以你必须与一个显然不是全心投入的使用者打交道。

使用者不读手册。

首先使用者是真的没_有_ 手册。可能是根本没_有_ 手册。就算真有手册,使用者也可能因为各种原因拿不到:人在飞机上;正在用由网站拿下来的试用版;人在家可是手册在公司;他们的资讯部门从来不_提供_ 手册。说实在的,就算可以拿到手册,除非他们别无选择,否则就是不会去读。只有_极_ 少数的例外,才会有使用者抱着手册读一遍后再去使用软体。通常你的使用者都是想_完成_ 某项工作,而且他们认为阅读手册是浪费时间,就算不是浪费时间,至少也会让他们分心而阻碍他们完成工作。

你能读这本书,表示你是高等知识份子中的精英。没错,我当然知道能用电脑的人通常都_能_ 阅读,不过我敢保证其中很多人都会觉得读东西是很烦的。手册所用的语言可能不是他们的母语,也有可能他们还不够精通。他们也可能只是小朋友!如果真的_必要_ ,他们还是能搞懂手册内容,不过没必要的话他们是绝对不会去看的。使用者只有在绝对需要时才测试时会临时去看手册。

所以结论就是你可能没有选择,只能把软体设计得不用手册就可以上手。唯一我能想到的例外就是使用者缺乏_领域专业知识_ 时,他们根本不懂这个程式的功用,不过却知道自己最好要去学。Intuit极受欢迎的小企业会计软体QuickBooks就是个很好的例子。这套软体有很多使用者都是对会计完全没概念的小企业主。而QuickBooks的手册就假设它得教大家会计原则。这是一定要的。不过如果你已经懂会计,即使没有手册QuickBooks还是很容易用。

**事实上使用者根本不会读_任何东西_** 。

这听起来可能有点刺耳,不过你很快就会懂了,当你在进行可用性测试时,会有相当数量的使用者根本不看画面上的字。不管你在画面上显示什么样的错误讯息,他们根本都不看。这可能会让身为程式员的你惊惶失措,因为你想像自己正与使用者 对话 。嗨,使用者!你不可以开启这个档案,我们不支援这种档案格式!不过经验显示,对话框里放的字愈多,愈少人会实际去读。

使用者不读手册这个事实,让很多软体设计者认为程式应该在事情​​发生当时加以叙述以教育使用者。所以你会在程式各处都看到说明。理论上这是可以的,不过实际上由于人们讨厌阅读,所以这招还是很不通的。有经验的使用介面设计者会努力把对话框内的字数减到最少,以增加使用者看内容的机会。当我还在Juno的时候,负责使用介面的人懂这个道理所以试图写出简短清楚的文句。可惜的是公司总经理以前在长春盟名校主修英文;他没受过任何使用介面设计或软体工程的训练,却深 自己是个优秀的文字编辑。所以他否决了使用介面设计专家的文句,反而加了很多他自己的长篇大论。Juno典型的对话框如下:

Juno_Modem_Options.gif

与Windows对应的对话框比较:

Windows_Modem_Options.gif

你在直觉上会认为说明有80个字的Juno版本会比只有5个字的Windows版本更「优秀」(也就是更易使用)。不过等你对这类事情做过可用性测试后就知道正确答案了。

1. 进阶的使用者会跳过说明。他们假设自己懂得使用方法,没时间去读复杂的说明
2. 大多数生手会跳过说明。他们不喜欢看太多字而且希望预设值就能用
3. 其他认真的生手会尝试阅读说明(其中有些人只是因为在做可用性测试,觉得应该要去看),却常被恐怖的字数和概念搅乱了。所以即使使用者很有把握第一次能会用这个对话框,这些说明还是会_让他们更迷糊了_ 。

不管怎么说,Juno的老板显然都管太细了。讲明白点,如果你在哥伦比亚大学主修英文,那么你的读写能力和一般人根本是完全不同的,而且你应该要非常小心去写那些似乎很有帮助的对话框内容。尽量把文句缩短简化,把括号里的复杂子句都拿掉,并且进行可用性测试。不过千万 写得像长春藤联盟的教学备忘录一样。在对话框里甚至连加上「请」这种似乎礼貌而有用的字,都还是会把使用者拖慢:增加字数会减少阅读文字的人数,而且影响是可以测量得出来。

另一个重点是很多人都怕电脑 。这一点你大概已经知道了,对不对?不过你可能还不了解其中的暗示。我曾经看着某个朋友要跳出Juno。不知道为什么她一直遇到问题。我注意到当要跳出Juno时会出现下面的对话框:

BlahBlahBlah.gif

我的朋友会去按No ,然后就有点惊讶Juno竟然没有结束。这个对话框是在询问使用者选择,却让她马上认为自己做错事了。通常程式会要你确认某个命令,是因为你正在进行某些你可能会后悔的动作。所以我朋友就认为既然 电脑 在质疑她的决定,那么_电脑_ 一定就是对的,因为电脑毕竟是_电脑_ 而她只不过是个_人_ ,所以就按了"No”。

要求人去读11个无聊的字会不会太过头了?显然是会。首先由于离开Juno并不会产生伤害,所以Juno应该不需要提示确认,像现有的其他图形使用介面一样直接离开就好。不过即使你 深信 在结束前_必须_ 要人们先确认,也可以用两个字而非11个字:

Exit_Now.gif

少了完全不必要的"thank you"和鼓励后悔的"are you sure? “,这个对话框就不太会产生问题了。使用者一定会看这两个字,对着程式说声「嗯?」后就按「Yes」。

你会说Juno的离开确认对话框只会困扰_少数_ 人,不过有_这么_ 严重吗?每个人_到最后_ 总有法子跳出那个程式的。不过个中差异在于_可以用_ 还是_容易_ 使用。即使是经验丰富又聪明的高阶使用者,还是会感谢你为慌张无经验生手所作的简化。旅馆的浴缸都有很大的扶手。它们的用途只是要帮助残障者,不过大家都会用这些扶手离开浴缸。即使对身体健康的人来说,这些扶手也能让生活更轻松。

下面一章我要讨论一些关于滑鼠的事。就像使用者不会/不想/不能阅读一样,有些人也不擅长使用滑鼠,所以你必须配合他们。

bullet.gif 下一章:[为节省大家的麻烦所作的设计,第二部份](/wiki/The_Joel_on_Software_Translation_Project:%E4%BD%BF%E7%94%A8%E4%BB%8B%E9%9D%A2% E8%A8%AD%E8%A8%88%E6%89%8B%E5%86%8A%E7%AC%AC%E4%B8%83%E7%AB%A0 “The Joel on Software Translation Project:使用介面设计手册第七章”)

这些网页的内容为表达个人意见。
All contents Copyright 1999-2002 by Joel Spolsky。All Rights Reserved.