《用户体验要素/The Elements of User Experience》摘记
摘记
整体
我们所生产的产品是供人们在现实世界中使用的。在产品开发过程中，人们更多地关注产品将用来做什么。用户体验是经常被忽略的另一个因素——即产品如何工作——而这一因素恰恰是决定产品成败的关键因素。将“设计一个用户体验良好的产品”作为明确的目标，意味着不仅仅是功能或外观那么简单。产品越复杂，确定如何向用户提供良好的使用体验就越困难。在使用产品的过程中，每一个新增的特性、功能或步骤，都增加了导致用户体验失败的机会。
无论用户体验对网站的成功具有多么重大的战略意义，在大多数网站发展的过程中，仅仅是“去理解人们所想和所需”这样一件简单的事，都从来没有得到过重视。
任何在用户体验上所做的努力，目的都是为了提高效率。这基本上是以两种主要形式体现出来的：帮助人们工作得更快和减少他们犯错的几率。效率所影响的不仅仅是最终的结果。当工作中用到的工具合乎规则、容易使用、不令人沮丧和没有不必要的复杂性的时候，人们会更喜欢自己的工作。如果你是其中一员的话，这种工具会使你在结束一天的工作回到家时带着很大的满足感，而不是累得筋疲力尽（或者，即使你累得筋疲力尽，至少是因为有正当的理由，而不是因为你一直在和你的工具作斗争）。
创建吸引人的、高效的用户体验的方法称为以用户为中心的设计（user-centered design）。在开发产品的每一个步骤中，都要把用户列入考虑范围。用户所体验的每一件事，对你来讲都应该是经过慎重考虑和论证以后的决定。实际上，设计出一个更好的解决方案需要更多的时间和费用，你可能不得不在各个方面做出妥协。但是，一个“以用户为中心”的设计流程保证了这些妥协不是随机决定的。考虑用户的体验、把它分解成各个组成要素、从不同的角度来了解它——只有这样，你才能确保你控制了决策所造成的全部结果。
用户体验对你很重要，其中一个最大的理由是：它对你的用户很重要。如果你没有给他们一个积极的体验，他们不会使用你的产品。如果没有用户，你最后所得到的只是一台藏在某个角落里、布满了灰尘的网络服务器（或者是装满了各种各样产品的仓库），无聊地等待着去完成永远不会到来的请求。对于那些来造访的用户，你必须为他们规划一个有粘性的、直观明了、甚至还让人愉快的体验—一次每件事都按照正确的方式在工作的体验。不管他们这一天的其他时间是如何度过的。
每一个层面都是根据它下面的那个层面来决定的。这种依赖性意味着在战略层上的决定将具有某种自下而上的“连锁效应”。反过来讲，也就意味着每个层面中我们可用的选择，都受到其下层面中所确定的议题的约束。在每一个层面的决定都会影响到它之上层面的可用选项。
但是，这并不是说每一个“较低层面”上的决策都必须在设计“较高层面”之前做出。事物都有两个方面，在“较高层面”中的决定有时会促成对“较低层面”决策的一次重新评估（甚至是第一次评估）。在每一个层面，我们都根据竞争对手所做的事情、业界最佳的实践成果来做决定，这是最简单不过的老尝试。这些决策可能产生的连锁效应应该是双方向的。一个更好的方法是让每一个层面的工作在下一个层面可以结束之前完成。
战略层
成功的用户体验，其基础是一个被明确表达的“战略”。知道企业与用户双方对产品的期许和目标，有助于促进用户体验各方面战略的确立和制定。
- 来自企业外部的用户需求（user need）是网站的目标—尤其是那些将要使用我们网站的用户。我们必须要了解这些观众想从我们这儿得到什么，还要知道他们想达到的这些目标将怎样满足他们所期待的其他目标。
- 与用户需求相对应的，是我们自己对网站的期望目标。这些产品目标（product objective）可以是商业目的（通过网站达到今年100万美元的销售收入）或者是其他类型的目标（让选民了解下一届候选人的情况）。
网站失败最常见的原因，是在开始写第一行程序、描第一个像素，或配置第一个服务器之前，没有人试图回答下面两个非常基本的问题：
- 我们要通过这个产品得到什么？
- 我们的用户要通过这个产品得到什么？
回答了第一个问题，我们才能据此描述出企业的产品目标（product objectives）。第二个问题则提出了关于用户需求（user needs）的问题，这是来自企业外部的目标。结合内外两者，“产品目标”和“用户需求”就组成了战略层，也就成为我们在设计用户体验过程中做出每一个决定的基础。关键词是明确（explicit）。当我们能越清楚地表达我们想要什么，以及确切地知道其他人想要从我们这里得到什么时，我们就能越精确地满足双方的需求。
产品目标
为了明确地理解战略，第一步就是检查我们自己的产品或服务的目标。当产品目标无法用口头表达出来时，对于应该如何完成产品，不同的人就经常会有不同的想法。
多数人一开始是用很宽泛的词汇来描述产品目标的。基本上，企业网站的存在是为了满足两种意图当中的一个：替公司赚钱或替公司省钱。有时它同时满足这两个。但为了这两个目标，网站到底应该做些什么并不总是很清楚。
相反地，太具体的目标也无法充分地描述出在战略制定过程中可能发生的困难。例如，写明你的目标是“为用户提供一个实时的文本通信工具”，并不能解释这个工具要如何支持企业目标，或是它如何满足用户需求。
要想在太具体和太宽泛之间取得一个平衡，我们就应该避免在尚未充分了解问题之前就试图得出结论。为了创造成功的用户体验，我们必须保证我们的决策不是随便决定的—也就是说，每一个我们做出的决定，都应该建立在我们确切地了解了它的影响力的基础之上。明确地定义“成功的条件”—而不是定义“通向成功的路径”—才能保证我们不会在这个阶段跑得太快。
理解你的目标，有一个最重要的部份，就是理解你要怎样才能知道“什么时候到达了终点”。成功标准（success metrics）：即一些可追踪的指标，在产品上线以后用来显示它是否满足了我们自己的目标和用户的需求。好的成功标准不仅影响项目各阶段的决策，也为衡量用户体验工作价值提供了具体的依据。特别是当你正申请下一个用户体验项目的预算，却发现对方对用户体验的价值表示怀疑时。
请务必后退一步，看看除了网站之外发生了什么事，以确定你了解到事情的全貌。
用户需求
我们很容易落入这样的陷阱，即认为我们正在为理想化的用户设计产品，理想化的用户就是“某些与我们完全一样的人”。但事实上我们并不是为自己设计；而是为其他人设计，如果想要这些“其他人”喜欢并使用我们创建的东西，那么就必须要了解“他们是谁”以及“他们的需求是什么”。只有投入时间去研究这些需求，我们才能抛弃自己立场的局限，真正从用户的角度来重新审视网站。
确认用户需求是复杂的，因为用户群体之间存在着很大的差异性。即使我们设计的是一个仅供企业内部使用的网站，也仍然需要大范围地考察用户的需要。要对这些用户需求寻根究底，必须要定义谁是我们的用户。一旦我们知道哪些人群是我们想要了解的，就可以对他们进行调研—换句话说，询问他们问题，观察他们的行为。
- 用户细分（user segmentation） 将用户分成更小的群组（或细分用户群），每一群用户都是由具有某些共同关键特征的用户所组成。创建细分用户群只是一种用于“揭示用户最终需求的手段”。
- 想弄明白用户需要什么，我们首先必须知道他们是谁。用户研究（User Research） 的领域致力于收集必要的信息来达成共识。
- 像问卷调查和焦点小组这种市场调研方法（market research methods） 是获取用户的基本信息的宝贵来源。当你能明确地表达出你试图从用户身上获得什么信息时，这些方法才能产生效果。
- 现场调查（contextual inquiry） 是指一整套完整、有效且全面的方法，用于了解在日常生活情境中的用户行为（因而得来此名）。
- 任务分析（task analysis） 的概念是认为每一个用户与产品的交互行为都发生在执行某一任务的环境中。有时任务非常具体（譬如买电影票），而有时任务比较宽泛（譬如学习国际商务章程）。任务分析是一种仔细地分解用户完成任务的精确步骤的方法。这种任务分解可以通过用户访谈来完成，让用户讲述自己的故事，说出他们的经验；也可以通过现场调查来完成，在用户的“日常生活环境”中直接研究他们的行为。
- 创建人物角色。人物角色是能代表整个真实用户需求的虚构人物。当我们决定产品用户体验的设计时，我们必须要紧记Janet和Frank所代表的不同用户群的需求。
- 让用户测试原型。原型可以是各种形式，从纸上的草图，到低保真度的、用脚本实现的模拟界面，以及看上去像是一个已完成的产品和“可点击”的高保真原型。大型项目在不同的阶段使用不同的原型来搜集用户意见，这将贯穿到整个开发过程中。
所谓可用性的最终目标，都是寻找令产品更容易使用的途径。
其他
在拟定决策时有一群人经常被忽略，那就是普通员工—这些人负责让企业每天正常运作。这些人通常比他们的经理更知道“什么行得通”和“什么不可行”—特别是在用户需求方面。没有人比那些每天跟客户交谈的人更明白客户遇到的困难是什么的了。我经常很惊讶地发现，用户的反馈很少能传递到需要这些信息的产品开发团队中去。
产品目标和用户需求经常被定义在一个正式的战略文档（strategy document）或愿景文档（vision document）中。这些文档不仅仅是列出目标清单—它提供不同目标之间的关系分析，并且说明这些目标要如何融入更大的企业环境中去。这些目标和对它们的分析经常由决策者、普通员工，和用户自己的直接意见来支持。
战略应该是设计用户体验的流程中的起点，但那不意味在项目开始之前你的战略需要完全确定下来。虽然设法击中一个移动的目标可能会浪费很多时间和资源（更不用说极大的内心挫折感），但是战略也应该是可以演变和改进的。当战略被系统地修改与校正时，这些工作就能成为贯穿整个过程的、持续的灵感源泉。
范围层
当你把用户需求和产品目标转变成产品应该提供给用户什么样的功能时，就转变成创建功能规格（functional specification）：范围层确定的是全部的功能需求或功能规格（functional specifications）。
定义项目范围则同时在做这两件事：这是一个有价值的过程，同时能产生有价值的产品。过程（process）的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点。我们能确定现在能解决哪些事情，而哪些必须要再迟一点才能解决。产品（product）的价值在于，被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的的全部工作，它也提供了一门用于讨论这件事情的共同的语言。定义好你的要求能保证在设计过程中不会出现模棱两可的情况。
用文档来定义产品需求，这件事很麻烦，但是你必须要做。这是由以下两个主要原因：
- 原因#1：这样你才知道你正在建设什么
如果详细地记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候将达到这个目标。拥有一系列明确的要求，能让你把责任分配得更清晰，这可以大大提高协作的效率。在了解了一个详细策划的完整范围之后，你就可以看到各个相对独立、也不显著的要求之间的内在联系。 - 原因#2：这样你才知道你不需要建设什么
许多功能听上去都相当地诱人，但是它们对于项目的战略目标并不是必需的。确定具体、系统的发展要求，并将任何不符合这些要求的想法作为潜在的未来功能囤积起来，只有通过这种更慎重的途径，你才能真正管理整个设计过程。如果你不能有意识地管理你的要求，你将陷入可怕的“范围蠕变（scope creep）”。
定义需求
一些需求适用于整个产品，另一些需求只适用于特殊的特性。需求的详略程度常常取决于该项目的具体范围。最用之不竭的需求源泉总是来自用户本身。但更多的时候，你的需求将来自与项目利益相关的同事—那些在企业中总想影响你的产品的人。不管是哪种情况，去了解“人们在想什么”的最佳途径就是直接询问他们。
具有讽刺意味的是，那些很少去想象产品新方向的人，恰恰是参与创建和设计产品最深入的人。当你把所有的时间都投入到维持现有产品时，你经常会忘掉哪些是真正的限制条件，而哪些是为了简化产品而曾经做过的选择。
场景（scenarios）。一个场景是一个简短的故事，简单描述了一个人物角色会如何完成这些用户需求。通过“想象我们的用户将会经历什么样的过程”，我们就可以找到能帮助他顺利完成这个过程的潜在需求。
文档不能解决问题，但定义可以。我们需要的不是文档有多厚或有多详细，而是要足够清楚和准确。同时功能规格说明也不需要展望产品未来的理想化状态—只需要记录在创建这个产品时已经确定下来的决议。
- 乐观（be positive）。
- 具体（be specific）。
- 避免主观的语气（avoid subjective language）。
需求优先级
由于项目范围是建立在战略层的基础上的，因此我们应该去评估这些需求是否能满足我们的战略目标（无论是网站目标还是用户需求）。除了这两种目标，我们还要额外确定第三种范围：实现这些需求的可行性有多大？
留意那些看上去有可能需要改变战略的特性建议，它们在制定愿景文档期间并不明显。任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除出去。但是如果有那么一个特性，尽管它不在项目范围之内，也超越了任何一个的限制条件，但听起来仍然像一个不错的想法，那么此时你可能需要重要审视某些战略目标。不管怎么样，如果你发现自己正在反复审视战略目标，那么你极有可能是太早地进入了需求定义阶段。
关注战略目标，而不是各种实现这些目标的手段。
结构层
范围层（scope）确定特性和功能，结构层确定网站各种特性和功能最合适的组合方式。
结构层则用来设计用户如何到达某个页面，并且在他们做完事情之后能去什么地方。框架层定义了导航条上各要素的排列方式，允许用户可以浏览不同的商品分类；结构层则确定哪些类别应该出现在那里。
在功能型产品，结构层将从范围转变成交互设计（interaction design），在这里我们可以定义系统如何响应用户的请求。
确定各个将要呈现给用户的元素的“模式（patterns）”和“顺序（sequences）”。交互设计关注于将影响用户执行和完成任务的元素，描述“可能的用户行为”，同时定义“系统如何配合与响应”这些用户行为。
传统意义上，程序员最关注软件的两个方面：“它做什么”和“它怎么做”。程序员之所以会这样是有原因的：由于他们对于细节的热情，使得他们做好本职工作。也正是由于这样的关注，意味着程序员更容易创建出来一个在技术上效率很高，却忽略了什么才是对用户而言最好的系统。尤其是在过去，计算能力是一种稀缺资源，所以最佳的方法就是在种种系统局限下让软件正常运作。
与其针对机器的最佳工作方式来设计系统，还不如设计一个对用户而言最好的系统。
用户对于“交互组件将怎样工作”的观点称为概念模型（conceptual model）。一个概念模型可以反映系统的一个组件或是整个系统。
更重要的是，概念模型是用于在交互设计的开发过程中保持使用方式的一致性的。
- 第一个同时也是最好的防止错误的方法，是将系统设计成不可能犯错的那种。
- 第二个避免错误的方法就是使错误难以发生。但即使如此，一些错误一定会发生。
文档一定要描述清楚网站的结构—从命名原则和元数据的具体细节，到信息架构和交互设计的整体概况—根据项目复杂度的不同，可以有很大的不同。
然而信息架构或交互设计的主要文档是示意图。视觉化地呈现结构，对我们而言，这是表述“分支、群组、组件之间的联系”的一种最高效的方式。架构图（architecture diagram）成为我们内部用来描述这种网站结构工具的术语。架构图最重要的是记录概念关系：哪些类别需要放一起，而哪些需要保持独立？在交互过程中那些步骤要怎样相互配合？
框架层
框架层用于优化设计布局，以达到这些元素的最大的效果和效率—使你在需要的时候，能记得标识并找到购物车的按钮。
框架层被分成了三个部分：
- 信息设计（information design），一种促进理解的信息表达方式。
- 界面设计（interface design），让用户与系统的功能产生互动的界面元素。
- 导航设计（navigation design），屏幕上的一些元素的组合，允许用户在信息架构中穿行。
结构层界定了我们的产品将用什么方式来运作；框架层则用于确定用什么样的功能和形式来实现。除了解决具体的这些议题，框架层还要处理更精确的细节问题。在结构层，我们看到一个较大的架构和交互的设计；在框架层，我们的关注点几乎全部在独立的组件以及它们之间的相互关系上。
界面设计
界面设计要做的全部事情就是选择正确的界面元素。哪个功能要在哪个界面上完成，是我们在结构层的交互设计中已经决定的；而这些功能在界面上如何被用户认知到，则属于界面设计的范畴。成功的界面设计是那些能让用户一眼就看到“最重要的东西”的界面设计。而另一方面，不重要的东西，不应该被注意到—有时候则是因为它们根本就没有出现在那儿。设计复杂系统的界面所面临的最大挑战之一，是弄清楚用户不需要知道哪些东西，并减少它们的可发现性（或者完全把它们排除出去）。
妥善处理所有不同的界面元素，并从它们中间选择合适的那个，这不可避免地会涉及权衡问题。
信息设计
信息设计总是很难入手，它常常充当一种把各种设计元素聚合到一起的粘合剂的角色。最后，信息设计变成决定如何呈现这些信息，使人们能很容易使用或理解它们。
当然，最关键的，是用一种能“反映用户的思路”和“支持他们的任务和目标”的方式来分类和排列这些信息元素。在这些元素之间的概念的关系是真正属于微观信息架构的；当我们必须要在这个页面上传达结构的时候，信息设计就呈现它的作用了。
线框图
页面布局是将信息设计、界面设计和导航设计放置到一起，形成一个统一的、有内在凝聚力的架构的地方。页面布局必须结合所有类型的导航系统，每一个旨在传达在不同结构中的视图设计；也必须结合任何一个在这个页面上的功能所需要的所有界面元素；还包括支持以上这些内容的信息设计，当然也包括在这个页面上内容的信息设计本身。
这就是为什么页面布局被纳入一个详细的文档，并称为页面示意图或线框图（wire frame）的原因。这个线框图是对一个页面中所有的组成部分以及它们如何结合到一起的、最直观的描述（正如它的名字一样）
现在，让我们再回去看看结构层的结构图示，它是这个项目的一个宏伟远景；而在框架层，线框图是正是展示那些远景如何完成的详细文档。线框图有时也需要导航规格的支持，以便能更详细、准确地描述各种导航元素的每一个组成成分。
线框图在正式建立网站的视觉设计的流程中，是必要的第一步，但是几乎每一个参与这个开发过程的人都会在其他任务点中使用它。负责战略层、范围层和结构层的设计者可以借助线框图来保证最终产品能满足他们的期望。真正负责建设这个网站的人，则使用线框图来回答关于网站应该如何运作的问题。
线框图是整合在结构层的全部三种要素的方法：通过安排和选择界面元素来整合界面设计；通过识别和定义核心导航系统来整合导航设计；通过放置和排列信息组成部分的优先级来整合信息设计。把这三者放到一个文档中，线框图就可以确定一个建立在基本概念结构上的架构，同时指出了表现层的设计应该前进的方向。
表现层
在表现层（surface），你看到的是一系列的网页，由图片和文字组成，为最终产品创建感知体验（sensory experience）。
在框架层，我们主要解决放置的事情。界面设计考虑可交互元素的布局，导航设计考虑在产品中引导用户移动的元素的安排，而信息设计考虑传达给用户的信息要素的排布。我们要在这里解决并弥补“产品框架层的逻辑排布”的感知呈现问题。
代替用“什么具有美感”来评估一个视觉设计方案的是，你应该把注意力集中在它们的“运作是否良好”上。
如果你的设计是成功的，用户眼睛的移动轨迹的模式应该有以下两个重要的特点：
- 首先，它们遵循的是一条流畅的路径。
- 其次，在不需要用太多细节来吓倒用户的前提下，它为用户提供有效选择的、某种可能的“引导”。
对比（contrast）。不管怎样，这些工作的总体策略是，让“差异”必须足够清晰，用户要足够分辨出某个设计选择是特意要传达一些信息的。
在你的设计中保持一致性（uniformity）是另一个重要的组成部分，它能使你的设计有效地传达信息，而不会导致用户迷惑或焦虑。“一致性”在视觉设计的许多不同方面都会起到作用。
一个成功的设计不仅仅是收集小巧的、精心设计的东西；相反，这些东西应该能形成一个系统，作为一个有凝聚力、连贯的整体来使用。
在视觉设计领域中对线框图最直接的模拟是视觉模型（visual mock-up）或设计合成品（design comp）。
另一个记录你的设计系统的原因是人们最后都会离开这个工作。当他们离开时，他们带走了关于这个产品如何设计出来的、如何在日常基础工作上建立起来的丰富知识。如果没有一个保留每一次更改、符合最新的标准和惯例的风格指南，这些知识就丢失了。承载这些设计决策的权威性文档是风格指南（style guide）。
要素应用
了解你正在试着去解决的问题。了解这些解决办法所造成的后果。要记住你所做出的每一个决定对其上、其下层面都有可能会产生“连锁反应”。
必须要同时考虑五个层面的全部因素，这对于创建成功的用户体验是至关重要的。
正确的做法是，将每一个决定都建立在对其背后议题的理解之上。与用户体验有关的第一个问题恐怕是问你自己的（这也是你应该回答的第一个问题）：你为什么要这么做？
询问你的用户关于产品的某个具体元素的问题，能帮助你收集来自用户的更多相关信息。没有着眼于用户体验的用户测试，很可能以提出错误的问题而告终，这相反又会导致你得到错误的答案。
你不能简单地依赖你的用户来阐明自己的需求。不管创建什么样的用户体验，其最大的挑战是“比用户自己更准确地去理解他们的需求”。测试可以帮助你了解用户的需求，但是它只是能达到同样的目的的许多工具之一。
当我向客户描述问题的时候，我常常使用一个比喻来形容用户体验开发过程：它是一场“马拉松”而不是“短跑”。了解你所参加的比赛类型才能用适合的方式去参赛。
产品开发很少是短跑比赛。更常见的是，有时候你会向前推进，建立原型和产生想法，然后随着时间推移，你再返回来，测试你所建立起来的东西，看看各个组成部分如何结合在一起，并且为这个项目提炼出一个综合的画面。有些任务需要重点承担速度；另一些则要求一个更加深思熟虑的方法。优秀的马拉松运动员知道哪些是哪些—所以你也应该。
然而，具有讽刺意味的是，那些最难被感知的要素（产品的战略层、范围层和结构层）在决定用户体验的最终成功或失败方面扮演了一个必不可少的角色。
在大多数情况下，在上一级层面中的错误有可能会削弱更低层面的正确决策。
相似地，如果那些在上一级层面上做出的正确决定是建立在低一级层面做出的错误决策的基础上的话，那些决定就没有任何意义。在网站历史中，一些网站之所以失败，是因为它们虽然很漂亮，却完全不可用。过于关注视觉设计，而排除其他的用户体验要素使得不止一个网站宣告破产，并使其他公司完全不明白为什么总是被网站问题所困扰。
这种糟糕的结果并不是必然的。如果你在网站开发的时候，始终从完整的用户体验出发，那么最后得到的网站就是一份有价值的资产，而不是无休无止的债务。每一件与网站的用户体验有关的事情都是有意识地、明确地决策的结果，只有这样你才能确保这个网站能同时满足你的战略目标和用户需求。
应用
参考
附件
版本记录
2025-02-14，初稿；