《About Face》精彩节选

第一章 目标导向设计
产品成功的关键是目标，而不是特性
程序员和工程师——对技术感兴趣的一类人——有着从功能和特性的角度考虑产品的强烈倾向。这很自然—
—因为这正是程序员创建软件的方式：一个功能接着一个功能。问题在于这不是用户想使用产品的方式。
确定某个功能是否应该包括在产品中不应该取决于它的实现技术。背后的决定因素永远不能只是我们拥有完
成这项功能的技术能力。决定性因素应该是这一功能是否直接或者间接地帮助实现用户目标，与此同时仍然满足
商业的需要。
即使在产品开发周期中的压力和混乱下，成功的交互设计师也应该对用户的目标高度敏感。虽然我们在本书
中讨论了其他很多技术和工具，但我们始终回到用户目标。它是交互设计实践的基础。
目标导向的过程，还有它在设计决策时清晰的理论基础，能更容易地说服工程师，能让市场和管理部门参与
进来，能确保正在考虑的设计不是凭空猜测，或者仅仅是团队成员个人偏好的反映。
公理   交互设计不是凭空猜测。
目标导向设计也是回答在定义和设计数字产品过程中出现的最重要问题的强有力工具：
  如何发现用户？
  如何知道哪些是用户试图完成的事？
  产品应该如何工作？
  产品应该采取什么形式？
  用户将如何与产品交互？
  如何能最有效地组织产品的功能？
  产品以何种方式面向首次使用的用户？
  产品如何体现在技术上容易理解和容易控制？

  产品如何处理用户问题？
  产品如何帮助比较生疏的用户变得更熟练？
  产品如何为专家级用户提供足够的深度？
在这本书的余下部分，我们将帮助您回答这些问题。您会得到您所需要的工具来识别产品的关键用户，理解
他们及他们的目标，以及通过使用目标导向设计将这些理解转变为成功的设计方案。

 

 

第 2 章 实现模型和心智模型
计算机工业界经常使用计算机文化（computer literacy）这个术语。权威人士经常谈论一些人具备这种文化，
而一些人则没有；具有这种文化的人又如何会在信息经济中取得成功，而缺乏计算机文化的人则不可避免地落入
社会经济学的断层里。然而所谓的计算机文化只不过是一种委婉的说法（euphemism）——让用户极力去理解计算
机奇怪的逻辑，而不是让基于软件实现的产品灵活地适应用户的思考方式。
在本章中，我们将讨论缺乏对用户和他们对待数字产品方式的了解如何加速了计算机文化鸿沟(divide)的产
生，而符合用户思考和工作方式的软件又将如何帮助解决这些问题。
实现模型（Implementation Model）
任何机器都有它达成目标的机制。例如，电影放映机使用复杂的移动图片序列来创建这种动态的感觉。它在
一个瞬间让明亮的光线透过半透明的微缩图象，然后在它移向另外一副微缩图像的瞬间挡住光线，接着在下一个
一瞬间再次投射光线。电影放映机每秒二十四次放映新的图像，重复这个过程。基于软件实现的产品并没有这样
的机制，取而代之，它们使用算法和相互通信的代码模块。这种有关机器和程序如何实际工作的表达被 Dnald
Norman（1989）和其他人称为系统模型（System model） 。作者更愿意使用实现模型（implementation model）这个
术语，因为它描述了程序在代码中实现的细节。
用户心智模型（user mental model）
从电影观众的角度来说，在观看一部引人如胜的电影时，很容易忘记影片齿孔间的细微差别和瞬间的光线打
断。很多看电影的人，实际上根本不知道放映机如何工作，或是它工作的方式与电视有什么不同。在观众的想像
里，放映机只不过是发射出在大屏幕上移动的图片而已。这就称为用户的心智模型，或者概念模型。

人们并不需要知道复杂产品的实际工作细节来掌握它的使用方法，为了便于使用，人们在认知上创建了一种
简洁的解释方式，这种方式对他们与产品的交互来说已经足够了，但并不一定能够反映产品实际的内部工作机制
比如，很多人想像，当他们将真空吸尘器和搅拌机接到墙上的电源插座时，电流会像水一样通过黑色的小电线管
从墙里流向电器。这种心智模型很适合于家用电器。但实际上家用电器的实现模型并不涉及什么液体类的东西在
电线中流动，而是电压每秒钟反转 120 次。尽管电力公司需要知道这些细节，但这些细节与用户无关。
然而，在数字世界里，用户的心智模型和实现模型通常差别很大。我们经常忽略像“手机的工作方式和固定
电话不同”这样的细节。相反，它实际上是一个在两分钟的通话过程中，要在半打不同的基站天线中交换连接的
无线电接收器。了解这些细节并不会有助于我们对它的使用。
对于软件应用来说，实现模型和心智模型之间的差异非常彻底。在这种情况下，复杂的实现使得用户不可能
看到用户行为和程序反应之间存在的机械关系。当用户使用计算机编辑数字声音或者创造视频特效，如变形时，
无法在机械世界中找到类似的例子，所以我们的心智模型有必要和实现模型不同。即使这种关系有可能是可见的
但它们可能对大多数人来说还是无法理解。
表现模型
软件显示给外界的行为外表是由程序员或者设计师创造的。这种表达并不一定精确地描述了软件实际上在计
算机里如何工作，虽然很不幸的是它经常如此。与其他媒介相比，这种独立于计算机的真实行为来表达其功能的
能力，在软件世界里更加明显——它允许聪明的设计师隐藏软件如何真正完成工作的细节。在数字化世界里， “实
现了什么”和“提供了什么”之间缺乏的联系带来了数字化世界里的第三种模型，设计师的表达模型——设计师
选择如何将程序的功能展现给用户的方式。Donald Norman（1989）简单地称之为设计师模型（designer's model）
在软件世界里，程序的表现模型可以（也常常应该）与程序的工作结构迥然不同。例如，操作系统能够使网
络文件服务器看起来像本地磁盘一样。这种模型并没有表现出物理磁盘可能在数里之遥的事实。在机械世界里，
表现模型的概念并不存在类似事物。这三个模型的关系见图 2-1。

 

图2-1  工程师开发软件的方式通常是给定的， 并且常常受制于技术和商业约束。 有关软件实际上如何工作的模型称为实现模型
用户与软件交互的心智模型是用户理解他们所需要进行的工作，和程序如何帮助他们完成工作的过程。这种模型基于他们自己如何
完成任务，还有计算机如何工作的想法。设计师选择如何将软件工作机制表现给用户的方式称为表现模型。表现模型和其他两个模
型不同，它是设计师能够极强地对软件进行控制的体现。设计师一个很重要的目标是使表现模型和用户的心智模型尽可能彼此匹配
因此设计师能否详细地理解目标用户所想到的软件使用方式非常关键。
表现模型离用户心智模型越近，用户就会发现程序越容易使用和理解。一般来说，假如（通常也如此）用户
有关任务的心智模型不同于软件的实现模型，向用户提供过分接近实现模型的表现模型会严重地降低用户学习和
使用程序的能力。
我们倾向于形成比现实更简单的心智模型。如果创造了比实际实现模型更简单的表现模型，我们就能帮助用
户更好地理解。踩下汽车的刹车踏板，可能让你想到按下控制杆，摩擦车轮来降低车速。而实际的机制包括水压
柱，管道和金属垫板挤压一个穿孔的圆板。为了简化事实，我们创造了更有效但不精确的心智模型。对于软件来
说，我们想象：当点击滚动条时，电子表单软件将新的单元格显现在视图里。实际上没有单元表格，只不过存在
一个紧凑的数据结构，以及它们之间的指针，在这个基础上程序实时合成一个新的图像来显示而已。
理解软件如何实际工作常常有助于人们使用它，但这种理解需要很大的代价。表现模型允许软件创造者通过
简化软件透明的工作方式来解决问题。这种成本完全是内部的，用户永远不必知道。抛弃了实现模型而更接近用
户心智模型的用户界面更好。
公理   用户界面应该避免实现模型，而支持用户心智模型。

 

第三章 新手，专家和中间用户
永久的中间用户
大多数用户既不是新手，也不是专家，相反，他们是中间用户。
进行某种活动的不同经验层次人数分布，就像大多数人口分布一样，遵循着经典的统计正态分布曲线。对于
几乎所有需要知识和技巧的活动来说，如果我们针对不同的熟练程度画出人数曲线，位于曲线左边的新手和位于
曲线右边的专家人数相对而言都是较少的，大多数都是位于曲线中间的中间用户。
然而，统计数据并不能说明所有问题。正态分布曲线只不过是瞬间时间上的快照，虽然大多数中间用户倾向
于保留在这一类型中，而新手不会永远是新手。要维持高水平的技术程度很困难，因此专家们也在快速变化。新
手和专家随着时间变化都会倾向于变成中间用户。
虽然每个人都会在一段时间内以新手的形式存在，但没有人会长期停留在这个状态。人们不喜欢显得不称职。
而就定义来说，新手意味着不称职。相反，学习和提高是令人高兴的，所以新手努力尽快成为中间用户——或者，
他们干脆放弃。例如，所有的滑雪的人，都会在新手层次停留一段时间，但那些不能很快取得进步，也就是摔跤
多过滑雪的人会很快放弃这种运动。剩下的人则会从初学者变为普通的运动者。只有少数人会成为滑双黑钻雪道
的高手。
公理：没有人愿意停留在新手级别。
第五章 用户建模：人物角色和目标
人物角色
要创建一个能满足广大用户群的产品时，逻辑告诉你，要使产品的功能尽可能广泛来适应最多的用户。然而，
这种逻辑是错误的。成功地适应大量不同用户的最好方式是，为具有特定需要的不同个体类型进行设计。
当任意而广泛地扩展产品的功能时，你会增加所有用户的认知负担以及导航成本（导航的含义见第 11 章） 。
能够愉悦某些用户的功能可能会影响其他用户的满意度（见图 5-1）

图5-1  一个简化的例子，来说明人物角色的用处。如果你想设计一辆汽车，希望能让所有可能的驾驶者开心，最后的结果是，
这辆汽车拥有所有的功能，但没有一个人喜欢。今天的软件设计也是如此，企图满足过多的用户，导致用户满意度下降。图 5-2 提
供了另外一种可供选择的方法。
关键在于选择为之设计的合适个体，这些个体的需要代表着很大一部分关键成员的需要（见 5-2） ，也在于了
解如何区分设计元素的优先级，解决最重要用户的需求，同时尽量不为其他用户带来明显的妨碍。作为一个强有
力的工具，人物角色能够帮助我们理解用户需要，区分不同的用户类型，并且对用户进行优先级排序，以便在功
能和行为设计中确定最重要的目标。
 
第 9 章 协调和流
引导，但不要讨论
很多开发人员认为理想的界面应该与用户进行双向交流。然而，大多数用户都不这样想。例如，他们更愿意
用和自己的车交互的方式与软件交互。打开车门，上车，然后去目的地。要继续向前时踩油门，想停下来时踩刹
车，转弯的时候打方向盘。
图 5-2   人物角色实用
性的简单示例。通过为
不同具体目标的用户设
计不同的车子，我们的
设计同时能使其他与目
标驾驶者有相似需求的
人也感到满意。对于数
字产品和软件设计来
说，这种情况也同样成
立。

这种理想的交互情形不是对话，更像是在使用工具。当木匠看到锤子时，他不想和锤子讨论钉子的问题。他
会直接用锤子钉钉子。在车里，如果司机想改变方向，他转动方向盘。司机喜欢通过合适的设备从车子和外部环
境直接获得反馈：挡风玻璃外面的视野；仪表板的读数；疾驰而过的风声；轮胎压在道路上的声音；对侧向重力
的感觉以及路面传来的的振动。木匠也希望有类似的反馈：钉子下沉的感觉，铁互相击打的声音以及举起锤子的
感觉。
司机当然不期望车子通过对话框与自己交互，木匠更不希望看锤子上显示这样的信息（如图 9-1） 。
 
图9-1  程序员习惯看到这样的消息，并不意味着其他行业的人们也希望这样。没有人希望他使用的机器责备它。如果以错误的
方式启动机器，我们期望获得错误的响应。当然，这可以防止我们犯严重的错误，但责备不同于保护。
软件常激怒用户的原因之一就是它们并不像车子或者锤子那样工作。相反，软件经常不合时宜地把我们引到
对话框，指出我们的缺点，并且要求我们做出响应。从用户的角度看，软件颠倒了自己的角色。应该是用户提要
求，而软件响应。
使用直接操作能够获得我们想要的效果。如果用户希望将对象从 A处移动到 B 处，那么用户点击它并把它拖
放到合适的位置。总的来说，更能引导流状态的界面，是那些具有丰富而完善的直接操作习惯用法的界面。
……
提问与提供选择
提问不等于提供选择，两者之间的差别就像逛商场和面试。人们通常认为，和被提问的人相比，提问的人更
优越。权威者提问，而从属者做出响应。向用户提问让他们感觉低了一等。
公理：提问不等于提供选择。

 

 

对话框（特别是确认对话框）是提问，工具条是提供选择。确认对话框停下来，要求用户回答问题，直到得
到答案才会消失。另一方面，工具条始终存在，安静而礼貌，像琳琅满目的商店一样提供商品。为你提供手指一
点就舒适地选择的机会。
与大多数软件开发者所想的不同，问题和选择并不是一定会让用户感觉强大。更普遍的是，这会让用户感到
有压力，并为此烦恼。你喜欢汤还是色拉？色拉。你喜欢甘蓝还是菠菜？菠菜。你喜欢法国、千岛群岛，还是意
大利的菠菜？法国。你喜欢本地的还是普通的？够了！快给我汤！你喜欢杂脍还是鸡肉面汤?
用户不喜欢被问。不断的提问向用户暗示着程序是：
  无知的
  健忘的
  功能不强的
  不主动的
  不能自理的
  烦躁的
  过分要求的
这些都是人类不喜欢的性格。为什么我们期望软件这样呢？程序问的不是一些智力问题，也不是期望像朋友
们在宴会上那样交流。相反，那是无知的行为，并且表现出不适当的权威。程序对我们的观点不感兴趣。它需要
信息，通常是那些一开始并不需要向我们询问的问题（如何避免这些问题的讨论见第 15 章和第 34 章） 。
比单个问题更糟的是反复提出那些不必要的问题。你想保存文件吗？你是否想现在保存文件？你真的想保存
文件吗？用户感觉那些很少提问的软件更聪明，更有礼貌。因为如果用户不知道如何回答，就会觉得自己很愚蠢。
在《The Media Equation（Cambridge University Press, 1996） 》一书中，斯坦福大学社会学家得出了引人注目的
结论：人类对待和响应计算机以及其他交互产品的方式和人类相同。我们是否应该注意产品显现出的人格特性。
胜任工作、乐于助人，或者抱怨，唠叨，强迫或者找借口。我们会在第 14 章讨论如何让软件更有礼貌和体贴人。

选择很重要。但基于表达的信息做出自由选择和被程序以模态的方式审问之间存在差异。用户更愿意像在街
道上驾驶汽车一样引导他们自己的软件。汽车向用户提供了全面的选择，而不发起一次对话框。想像一下图 9-7
描述的情况。
 
图9-7 想象一下，如果必须
点击对话框上的按钮来驾驶
汽车，这会让你感受到普通
人对对话框的感受：让人难
堪，不是吗？
 
直接操作方向盘对于汽车来说是最合适的习惯用法，它让用户感觉自己处于优越的位置，引导你的汽车去目
的地。没有用户愿意像审判席上的嫌疑犯那样被人质疑，然而这正是我们的软件通常要求我们做的。

 

第十章 消除附加工作
什么是附加工作
当我们决定开车前往办公室时，必须打开车库门，上车，启动发动机，停下来，在动身前往目的地之前关闭
车库门。所有这些动作都是为了支持汽车，而不是为了支持我们前往目的地。如果有星际迷航的传输器，我们呼
叫相应的目的地，然后立即出现在那里。不需要车门，不需要发动机，也没有红绿灯。我们的意思不是抱怨开车
复杂，而是要区分完成日常任务时需要采取的两种动作类型。
任何大的任务，诸如开车前往办公室，涉及到很多较小的任务。有些任务直接实现目标，像操纵方向盘直到
你的办公室。另外一方面，附加工作不直接实现目标，但与此同时，对于实现任务非常必要。这些任务包括打开
和关闭车门，开动引擎，在红绿灯面前停车，给车子加油以及进行周期性的维护。
附加工作是在我们努力实现目标的同时，满足工具或者外部代理需要的其他工作。这两者有时候难以区分，
因为我们习惯于附加工作成为任务的一部分。对于经常开车的人来说，区分打开车门的活动和开车前往目的地的
活动非常困难。开关车门通常是我们为车子做的，而不是我们自己。它不像油门踏板和方向盘那样将我们带向目
的地。在红灯面前停下是我们所设置的要求，并不能帮助我们实现自己真实的目标（在这种情况下，它确实能帮
助我们实现安全到达办公室的相关目标） 。

软件在目标导向的任务和附加任务之间存在相当清晰的分界线。像汽车一样，一些软件的附加任务是微乎其
微的，操作它们不需要多大困难。另外一方面，一些软件的附加任务像补车胎一样令人讨厌。安装就是这样，还
有配置网络、备份，连接在线服务等都是附加任务。
附加任务存在的问题是在消耗我们的精力，而不是直接实现我们的目标。在消除了附加任务的地方，我们能
够让用户更加有效率和更有生产率，并且能够改善软件的可用性。作为一个软件设计师，你应该对附加工作的存
在非常敏感，并且向治疗感染的医生一样有激情地采取步骤根除附加工作。
公理：  消除附加工作使得用户更加有效率。

 

第十一章 导航和调整
提供合适的控件――功能映射
映射描述了控件、它影响的事物以及预期结果之间的关系。当控件与它影响的事物之间没有视觉上或者象征
上的关系时，映射关系很不自然。不自然的映射关系影向用户的进度，用户不得不停下来思考控件和它影响的事
物之间的关系，从而打断了流状态。控件到功能的不自然映射也增加了用户的认知负担，并且可能会产生严重的
用户错误。
一个很好的例子来自煤气灶，而不是数字世界。任何做过饭的人，都会对做饭用的煤气灶旋钮没有合适地映
射到它所控制的火炉感到恼火。如图 11-8 所示，典型的煤气灶有四个火炉，每个火炉占用正方形的一角。然而，
控制火炉的旋钮却在前边的面板上成直线排列。
 
图 11-8   煤气灶表面
控件的物理映射很不
自然。最左边的旋钮控
制的是前面的火炉还
是后面的火炉？用户
必须在使用煤气灶时，
重新确定它们之间的
关系。 
 在这个例子中，问题是物理映射。使用控件的结果应该显而易见：当你旋转一个旋钮时，会点燃一个火炉。
然而，控制的目标——哪个火炉会变暖？——不清楚。旋转最左边的旋钮控制的是左边前面的火炉，还是后面的
火炉呢？用户必须通过试验或者参考旋钮下的图标来确定。这种不自然的映射，迫使用户在每次使用煤气灶时都
不得不重新确定映射关系。虽然随着时间推移，这种认知过程会慢慢变成无意识的行为，但它仍然存在。如果用
户匆匆忙忙或者注意力不集中（在人们准备膳食时，通常会这样） ，就会很容易出错。用户因为旋错了旋钮而感到
自己很愚蠢，或者在用户意识到自己的错误之前，食物还没有加热，这些都还算好的，最糟糕的是，可能会不小
心引起厨房的火灾。
解决方案是调整旋钮的物理位置，这样它们能够更好地表示所控制的火炉。旋钮不必以火炉同样的模式来布
局，但它们应该定位成每个旋钮的目标很清晰。图 11-9 中的炉子就是一个有效的控件映射例子。
 
图 11-9   清晰的空间
映射。在煤气灶上，旋
钮和火炉的映射非常
清晰，因为旋钮的空间
布局清晰地将它们与
火炉联系起来。
 
在这种布局中，很清楚，左上端的旋钮控制着左上端的火炉。每个旋钮的位置都在视觉上清晰地显示出它所
控制的火炉。Donald Norman(1989)将这种更直觉的布局称为“自然映射” 。
另一个不同类型的不自然映射例子如图 11-10 所示。在这种情况下，概念到动作的逻辑映射不清晰。
 
图11-10逻辑映射问题的例子。如果用户想首先看到最近的项目，他是选择 Ascending  还是Descending呢？这些术语和用户对
时间的理解之间没有很好的映射关系。
这个网站使用成对的下拉菜单，根据时间对搜索结果进行排序。对第一个下拉菜单的选择决定了第二个下拉
菜单提供的选择内容。在第一个菜单中，当选择 Date Placed  重新排序时，第二个下拉菜单显示 Ascending 和
Descending选项。

 

不像前面的炉子旋钮，这里控件的目标非常清晰：下拉菜单选项会影响下面显示的列表。然而，使用控件的
结果不清晰，如果用户选择上升时，会获得什么样的排列次序呢？
正是这些用来表达日期分类选项的术语，使得用户如果想在列表中先看到最近的项目时，无法确定该怎么选
择。上升和向下不能很好地映射到用户对时间的心智模型。人们不认为时间存在上升和向下之分。相反，他认为
时间和事件可以分为最近的和最老的。快速修正该问题的方法是，将选项使用的单词改为“首先显示最近的”和
“首先显示最老的” ，如图 11-11 所示。
 
图11-11清晰的逻辑映射。使用术语“最近的”和“最老的”使用户容易映射到基于时间的分类。
无论是创建家电、桌面应用还是 Web 站点，你的产品都可能存在映射问题。映射是一个关注细节就会得到回
报的领域：即使没有多少时间来做出改变，你仍然可以通过寻找和解决映射问题来让产品得到明显的改善。如果
说结果，那就是产品会更加容易理解，并且使用起来更愉悦。