2000年04月11日 使用介面设计手冊第二章 – User Interface Design for Programmers Chapter 2

The Joel on Software Translation Project:使用介面设计手冊第二章

From The Joel on Software Translation Project

Jump to: navigation, search

程序员的使用介面设计手冊 第二章：找出使用者的期望

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

新使用者在操作一个程序时，心里绝不会一片空白。他们会先预设程序会如何运作。如果他们以前曾用过类似的软件，就会假设这个程序的动作应该与其他软件一样。如果他们以前没有用过任何软件，就会假设你的软件会遵循某些常规。他们还可能很聪明，会猜测整个使用介面的运作模式。这被称作使用者模型：也就是使用者心中对程序所做的事的认知。

程序本身也有一个「心智模型」，不过这个模型是用数位方式编码，并且由CPU确实地执行。这被称作程序模型，而且是固定不变的。我们在第一章说过，如果程序模型与使用者模型一致，就能拥有成功的使用介面。

我们来看一个例子。在Microsoft Word(及大多数文书处理器)中，如果在文件里放一张图片，图片会被储存在该文件同一个文件內。你可以建立图片并把图片拖入文件內，然后刪除原图片档，而文件內的图片依旧存在。

不过HTML却不能这样做。HTML文件一定得把图片放在分开的文件里。如果找个惯用文书处理器却完全不懂HTML的使用者来，请他用FrontPage等还不错的所见即所得HTML编辑器，他几乎一定会认为图片将会存在同一个文件里。这就叫使用者模型惯性(如果你愿意这样叫的话)。

所以使用者模型(图片会嵌入在同一个文件)与程序模型(图片必须分开存档)间就有个讨厌的冲突，这样使用介面一定会产生问题。

如果你正在设计一个类似FrontPage的程序，这就是你会发现的第一个使用介面问题。你不可能改变HTML。所以一定得做些事让程序模型符合使用者模型。

你有两个选择。你可以尝试改变使用者模型。不过这点将会非常困难。你可以在手冊里面解释清楚，不过大家都知道使用者根本不看手冊，而且他们可能也没必要看。你也可以显示一个小对话框说明图片档不会被嵌入，不过这又有两个问题：熟练的使用者会觉得很烦，另外使用者也可能根本不看对话框。(我们会在第六章深入讨论)。

所以呢，山不转路转…最好的选择通常都是改变你的程序模型而不是使用者模型。或许你可以在插入图片时产生一个图片复本，存到文件档所在处的子目录中，这样至少能符合使用者认为图片已复制(可以安全地刪除原图)的印象。

我要怎么知道使用者模型呢/span>

这件事其实很容易。只要问他们就好了！在你的办公室里随便抓五个人或是找朋友或家人，然后用普通的说法说明你的程序(这是个制作网页的程序)。接下去描述状况：「你正在编一个网页，现在有张图叫Picture.JPG。你要把图插入到网页內。」然后问几个问题来猜测他们的使用者模型。比如「图片会放在哪里，「如果你刪除Picture.JPG，这个网页还能正常显示该图片吗

我有个朋友正在做一个相簿形式的应用程序。当你把照片加进去之后，程序会显示一堆小图：也就是每张图的缩图复本。由于产生小图要花很长一段时间(如果照片很多时时间更长)，所以他想把小图存在硬盘某处，这样小图只要产生一次就好了。有很多方法可以达成这个目的。可以把所有小图存在一个叫小图的大文件中。也可以把各个小图分别存档，不过放在同一个叫小图的子目录內。小图也可以在操作系统內标示成隐藏档不让使用者发现。我的朋友选了一种自认最妥当的方法：把各张图片picture.JPG的小图另存成名为picture_t.JPG的新档，放在原图的目录中。如果你本的图片有30张，完成后该目录含小图就会有60个文件。

讨论各种图片储存机制的优缺点可以吵上几个星期，不过还是有比较科学的作法可以用。只要问问使用者对小图存档的想法就好了。当然会有很多使用者不清楚或不在意或是根本没想过，不过如果你问过很多人，就会开始看到某些一致的意见。常见的选择就是最佳的使用者模型，至于程序模型是否要和使用者模型一致就是你自己的事了。

接下来你得测试自己的理论。替你的使用介面建一个模型或原型，然后请大家用它完成某些工作。在他们完成的过程中问他们期望发生什么事。你的目标是找出他们所期望的东西。如果工作內容是「插入一张图片」，而你看到他们尝试把图片拖进你的程序里，你就知道程序最好能支持拖放功能。如果他们去点「插入」功能表，你就知道「插入」功能表下最好能有一个「图片」选项。如果他们把「字型」工具列里的「细明体」换成「插入图片」，你就知道这是个没碰过图形化使用介面，试图使用命令列介面的老古董。

那么要找多少人来测试你的介面呢的直觉可能会认为愈多愈好(对科学实验来说完全正确)。不过你的直觉错了。几乎每个靠做可使用性测试为生的人似乎都认为五个或六个人就够了。超过这个数字之后就会看到结果一直重复，所以继续做其他使用者只是浪费时间。

你并不需要一个正式的可使用性实验室，也不必真的去街上随意挑使用者来做。你可以做个「5毛钱可用性测试」，也就是叫住下一个遇到的人，请他帮忙做个快速的可使用性测试就可以了。不过要注意别说溜嘴先告诉他要怎么做。应该要他「好好想清楚」，然后再尝试用开放性的问题找出他们的心智模型。

如果你的程序模型不单纯，可能就不是使用者模型。

我6岁时爸爸买了一台世界上第一批的口袋型计算机(HP-35)回家，他努力告诉我那里头有一台电脑。我觉得不可能。星舰迷航记里所有的电脑都是整个房间大小而且都有巨大的碟带机。我认为只不过是按键的键和LED显示上各个段落有很巧妙的连接关系，才会产正正确的数学答案(嘿，我才6岁而已)。

有个很重要的经验法则，就是使用者模型不会非常复杂。当人们必须猜测程序的运作方式时，答案通常是简单的而非复杂的。

找台麦金塔坐下来用。打开两个Excel试算表档和一个Word文件档。几乎所有生手都会猜测这些视窗间没有关连。他们看起来就是没有关系：

从使用者模型来看，点Spreadsheet 1应该会把该视窗叫到最前面。可是实际发生的却是Spreadsheet 2跑到前面，几乎对所有人来说这都是个让人挫折的意外：

实际的情况如下。Microsoft Excel的程序的程序模型认为「你有一些隐藏的试算表，每个试算表都属于某个应用程序，而视窗是连到这些隐藏的试算表的。当你把Excel叫到最前面时，所有Excel的视窗也会被移到前面。」

没错。隐藏的试算表。不过使用者模型里具有隐藏试算表的机会有多少呢概可能是零吧。所以新的使用者总是会被这个行为吓到。

Microsoft Windows上有另一个例子，就是按Alt+Tab键可以切到「下一个」视窗。大部份的使用者可能都会假设这个键是在所有可用视窗间循环。如果你有A,B,C三个视窗，A视窗是在作用中。按Alt+Tab应该会切到B视窗。再按一次Alt+Tab会切到C视窗。实际上第二次的Alt+Tab会切回A视窗。要切到C视窗一定要按住Alt后再按两次Tab键。这在切换两个应用程序时还不错，不过几乎没人了解这个方法，因为比起在多个可用视窗间循环的模型来说，这个模型稍嫌复杂。

要让程序模型遵循简单的使用者模型已经够难了。当使用者模型更为复杂时简直不可能做到。所以要尽可能挑选最简单的模型。

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

来源：铁文