申明：本文及以后一系列有关都将《User Interface Design for Programmers》持续转载自tobybateer 的博客：http://tobybateer.blog.163.com/

感谢tobybateer的辛勤付出，给我带来了如此优秀的学习文档。

第二章：描绘出用户想要的

概述

许多年前，当我还在上大学的时候，我的一个朋友在楼下熬了通宵，因为第二天有一份非常重要的期末报告要交。当他熬到早上6点的时候，重重地敲了一下苹果机，然后，睡眼惺忪地关掉了电脑，想在上交报告之前再睡几个小时的回笼觉。

是的。

他关掉了电脑。

注意到我并没有说他保存了工作然后关掉了电脑。早上6点，他忘记了这件小事情。

大概早上7:45，他绝望地敲开了我的宿舍门。“恩…你懂电脑的哈？”，他几乎都哭出来了，“我难道不能找回我的报告么？”

我问：“你压根儿就没有保存？”

“没有！”

“没有？难道整晚你连一次‘保存’都没有点？”

“没有。文档仍然叫‘未命名’。但是它一直都存在的，难道不是么？”

苹果机最引以为豪的就是“所见即所得”，它的应用程序如此传神地模仿在纸上写字，以至于误导了我的朋友，使他以为他的论文的的确确真实存在。当你在纸上写字的时候，确实是这样！这就够了！写了就写了！压根儿就没有保存这一说。

坐在电脑前使用程序的新用户，其实并不是像白纸一样什么都不懂。他们心里对程序的工作方式是有一种期望的。这就是所谓的用户模式（User Model），关于程序应该如何响应，这仅仅存在于意识层面。

如果他们从未使用过电脑，而且电脑展示给他们的界面就像一张纸一样，让他们在上面写写画画，那么他们会理所当然地认为无需“保存”所做的一切。

有经验的用户同样有模式，如果他们以前用过类似的软件，那么他们会期望另一款类似的软件也像这样工作。如果你使用过WordPerfect，但没有使用过Word，当你使用Word时，你肯定认为需要保存。

程序也有一个模式，不过这个模式被转换成了二进制的位（bit），将被CPU执行。这称为程序模式，这是定律。除了电磁风暴或者宇宙射线之外，没有任何东西能让CPU违背程序模式。

现在，你还记得第一章提到的不变真理？现在你应该记住了吧：

如果程序能精确地按照用户的期望执行，那么UI设计就是成功的。

换句话说：

当程序模式与用户模式相一致时，UI设计就是成功的。

就是这样。几乎所有优秀的UI设计都保持程序模式与用户模式相一致。如果苹果的UI能够自动保存你“未保存”的工作，那么将会更加成功（对我那可怜的朋友来说尤其如此）。当然，在1985年，当时速度很慢的软盘几乎不可能这样做。但到了1988年，人人都有了硬盘的时候，这就有点儿说不通了。直到如今，大部分流行的软件仍不会自动保存你的工作。

让我们看另一个例子。在微软的Word（以及许多其它文字处理软件）里，你向文档插入图片时，图片会被嵌入到文档本身。你可以创建图片，将它拖放到文档里，然后删除原始图片，但是图片仍然会保存在文档里。

如今，HTML却不这样做。HTML文档必须将图片分开存储。如果某个习惯于文字处理软件的用户对HTML一无所知，那么当他使用类似微软FrontPage这种所见即所得的HTML编辑器时，他肯定会认为图片将被存储到HTML文档中。如果你愿意的话，可以将其称为惯性用户模式（User Model Inertia）。

到现在，我们对于用户模式的冲突（到底该把图片嵌入文档还是分开存储）有点点不高兴，而且UI设计肯定会带来麻烦。

如果你正在设计一款类似FrontPage的程序，刚才所说的就将是你碰到的第一个UI问题。你无法改变HTML，毕竟这已经是国际标准。你必须做点儿什么，使程序模式与用户模式相一致。

你有许多选择。你可以试着改变用户模式，事实上这非常困难。你可以在用户手册中予以解释说明，但是地球人都知道，用户从来不读用户手册，而且他们可能根本不需要读。或者，你可以使用弹出窗来解释图片并不会被嵌入到文档里，但是这会带来两个问题：它会惹恼有经验的用户，同时用户压根儿不会读弹出窗。我们将会在第九章详细谈谈这个问题。

所以，困难不会自己消失，而是需要你去解决。你最好的选择始终是试着改变程序模式而不是用户模式。也许，当用户插入图片时，程序应该在文档所在目录新建一个子目录，然后保存图片的备份。这至少与用户的想法相一致——图片被复制了，原始图片可以删除。

我怎样才能知道用户模式呢？

相对来说这个比较容易。问问一些用户就行！从你的同事、朋友或者家人里边，随便挑一些人，告诉他们关于程序的总体印象（例如这是一个制作网页的程序），然后描述解决方案：“你有一个正在制作的网页，和一张图片Picture.jpg。你想将图片插入到网页中。”然后问问他们一些问题，试图猜测他们的用户模式。“图片哪儿去了？如果你删除Picture.jpg的话，网页还能够显示图片么？”

我的一个朋友在写一个相册软件。当你插入照片之后，应用程序会显示一系列缩略图（相对原始图片而言只占用很少的空间）。现在的问题是，生成这么多的缩略图需要很长时间，特别是你有许多图片的时候，所以他想将这些缩略图存储在硬盘的某个地方，这样就只用生成一次。他有许多方法来实现这一点。它们可以存储在一个称之为“缩略图”的大文件中，然后默认放置在C盘根目录下；它们可以被单独存储，然后放置在一个叫做“缩略图”的子目录下边。它们可能会被标记为系统隐藏文件，这样用户就不会知道他们到底在哪儿。我的朋友选择了一种他认为最好的方式，他将每个缩略图单独存储，例如对picture.jpg而言，就生成一个叫picture_t.jpg的缩略图，与其保存在同一目录下。如果你生成了一个有三十张照片的相册，那么当你完成之后，事实上连同缩略图一起，目录下边会有六十个文件。

你可以花好几周的时间来讨论各种不同的图片存储方式之间的优劣，但事实上，有更加科学的方式。仅仅只需要问一问用户他们关于缩略图存储方式的想法。当然，许多用户并不知道或者并不关心，或者他们压根儿没想过这个问题。但是你问了许多人之后，你会逐渐看到某种一致的意见。事实上，并没有太多用户希望单独存储一个picture_t.jpg这样的文件，所以他修改了程序，将所有缩略图存储在一个叫“缩略图”的子目录里边。

下一步是测试你的理论。给你的UI构造一个模式，或者一个原型，然后拿给一些人去做测试。模型可以非常简单，有时候仅仅只需要在纸上草草绘出UI即可，然后拿着它在办公室多走几圈，问问人们关于你绘制的这个程序都有什么看法和期望。

当你进行这项任务时，问问他们所期望发生的事情。你的目标是找出他们的期望值。如果目标是“插入图片”，而且看到他们试图将图片拖放到你的程序中，那么你可能会意识到，需要更好地支持拖放操作。如果他们插入了菜单，你可能意识到，最好能够在“插入”菜单中新增加一项“图片”。如果他们将字体工具栏中的“Times New Roman”字体替换为“Insert Picture”，你会发现有些人似乎还没有适应GUI，而是希望仍然有命令行。

你究竟需要为界面测试找多少用户？科学的方式似乎是“越多越好”。如果找5个人测试的结果就比较不错的话，找20个人测试肯定会更好。

但那样是错的。几乎所有做过可用性测试的人都会认为五到六个人就足够了。在那之后，你就会不断地看到重复的意见，增加新的测试用户只能是浪费时间。原因就在于，你并不关心精确的统计数字。你只是想发现“大多数用户”到底是怎么想的。

你不需要正规的可用性测试实验室，你只用简单的用抛硬币来决定是否让你见到的下一个人参与测试。确保你并不涉及任何实现层面的东西，只需要告诉他们事情的工作方式就行了。让他们发散思维，使用开放式的问题来发现他们的精神模式。

如果你的程序模式很不平常，那么很可能用户模式也是如此

当我六岁的时候，我的爸爸拿回家了一台世界上最快的便携式计算器——HP-35，他试着说服我，说里边有一台计算机。我认为那不可能。所有星际迷航（指的是全部设定在同一个虚构宇宙中的六代电视科幻电视系列剧、十一部电影、上百部小说、电视游戏以及其他虚构作品，该宇宙是由吉恩·罗登贝瑞于1960年代初期到中期所创造。——译者注）中的计算机都有房子那么大，而且都有磁带机。我试着说服爸爸，说计算器仅仅只是有一些按键和LED显示器罢了，出现的结果只是碰巧是对的。（嘿，我当时只有六岁）。

一条重要的规则：用户模式并不复杂。当人们猜测一个程序如何工作时，他们倾向于简单而不是复杂。

坐在苹果机前，打开两个Excel表单和一个Word文档，就像图2-1所示。

图2-1 猜猜当你点击表单1的时候，会发生什么？

几乎任何新手都会猜测，这些窗口是互相独立的。他们看起来就是独立的。

用户模式认为，点击表单1，将会把相应的窗口置于前排。而事实上，表单2放置到了最前面，如图2-2所示，对任何人来说都大吃一惊。

图2-2 错！微软Excel的程序模式包含了一个奇怪的、不大现实的概念——隐形表单（Invisible Sheet），其他所有表单都附着在这个隐形表单之上。

结果是，微软Excel的程序模式认为，“这里存在有隐形表单，就像玻璃纸一样，每个程序都有。窗体就被“粘”在这些隐形表单纸上。当你将Excel至于前端时，你其实点击的是这层玻璃纸，因此所有其它跟Excel相关的窗口会整体移动而不改变相对顺序。”

对~~~！隐形表单。用户模式包含隐形表单这个概念的可能性有多大？几乎为零。用户模式更为简单，“窗口就像桌子上的一些纸”，就是这样。所以新用户会对Excel的行为大吃一惊。

另一个关于微软Windows概念的例子是Alt + Tab的组合键，它能弹出“下一个”窗口。大多数用户可能会认为，它简单地在所有可见的窗体之间循环切换。如果你有三个窗口，A、B和C，那么当A激活的时候，Alt + Tab应该激活B。再按一次Alt + Tab应该切换到C。但事实上，当你按下Alt + Tab的时候，会切换回A。想要激活C的唯一方式，是按住Alt不放，然后按两次Tab键。这是在两个应用程序间切换的一种好方法，但是几乎没人会这么想，因为这种模式比在所有可见的窗体之间切换要更加复杂。

用户会认为最简单的模式是最有可能的。

当模式很简单的时候，要保持程序模式和用户模式的一致就已经很困难了，更别说当模式变得复杂的时候。所以，挑最简单的模式吧。