读书：用户体验要素（以用户为中心的产品设计）

图片发自简书App

用户、商业、技术，用户体验要素：5个层面，10个要素模型如何提出正确的问题关注点+概念模型+设计原则－应用于所有的产品和服务打磨和提炼。 ISO 9241-210标准将用户体验定义为 “人们对于针对使用或期望使用的产品、系统或者服务的认知印象和回应”。 ISO定义的补充用户体验说明，用户在使用一个产品或系统前、使用中和使用后的全部感受，包括情感、信仰、喜好、认知印象、生理和心理反应、行为和成就等各个方面。该说明还列出三个影响用户体验的因素：系统，用户和使用环境。

第一章用户体验为什么如此重要

在产品开发过程中，人们更多地关注产品将用来做什么。设计师经常忽略的另一个因素是产品如何工作，而这一因素恰恰是决定产品成败的关键因素。用户体验并不是指一件产品本身是如何工作的，用户体验指“产品如何与外界发生联系并发挥作用”，也就说人们如何“接触”和“使用”它。当人们询问某个产品或服务时，他们问的是使用的体验。它用起来难不难？是不是很容易学会？使用起来感觉如何？不管什么产品，用户体验总是体现在细微之处，但却非常重要。

提到产品设计，人们往往会想到的是产品在感官方面的表现：精心设计的产品，看起来赏心悦目，而且给用户很好的触感（听觉应该注意，嗅觉和味觉在大部分产品设计中比重很小），另一种常见评价产品的角度，则是与“功能”有关的：精心设计的产品必须具备它应该具有的真正功能。但有些产品可能很好看且功能正常，但将“设计一个用户体验良好的产品”作为明确的目标，意味着不仅仅是功能或外观那么简单。

有些产品经理可能根本不会想到“设计”这个词，他们创建产品的过程更像是开发：逐步建立和完善产品的特性和功能，直到它们所组成的那个东西在市场上是可行的。外形服务于功能（产品设计由功能决定），但用户直接面对用户的部分—按钮/布局/文字/外观等，其产品形态应该由“用户自身的心理感受和行为”决定。

用户体验设计通常要解决应用环境的综合问题。视觉设计选择合适的按钮形状和材质，要保证它在咖啡机能引起用户注意、功能设计保证在设备上触发特定功能、用户体验设计兼顾视觉和功能，同时解决产生所面临的其他问题（同时还要保证当用户尝试去完成其他某个任务时，按钮在这种情形下能更好地工作－并发工作）

为体验而设计：使用第一。对复杂产品来说，创建良好的用户体验和产品自身的定义之间的关系相对而言是独立的。产品越复杂，确定如何向用户提供良好的使用体验就越困难。在使用产品过程中，每个新增特性、功能或步骤，都增加了导致用户体验失败的机会。

不管用户访问什么类型的网站，它都是一个自助式产品。没有可以事先阅读的说明书、没有任何操作培训或讨论会、没有客户服务代表来帮助用户了解这个网站。用户所依靠的只有自己的智慧和经验，来独自面对这个网站－企业却没有重视“去理解人们所想所需”，增加内容和功能特性，只能保持短时间内的优势。面对大量的选择，用户只能自己想办法，去决定哪一个网站功能会符合他的需求。大多数情况下，企业只能把拥有网站看成是一个杰出的成就；至于它是否真正能为人们所用，充其量是后来才想到的一件事情。无论如何，拥有更多的“产品特性”，被证明只能保持短时间的竞争优势。随着功能不断膨胀，网站变得越来越复杂、越来越笨重、越来越难以使用，最后就失去了对初次访问者应有的吸引力。同时，企业很少去关心用户真正喜欢什么，很少去发现有价值、或真正可以使用的东西。

用户体验是一个重要的可持续的竞争优势—形成企业整体印象，界定企业和竞争对手的差异，决定用户是否光顾。信息必须用一种能帮助人们理解和接受的方式呈现出来。如果用户弄不明白它是怎样工作的，你所提供的“世界上最强大的功能”将摇摇欲坠，并以失败而告终。特性和功能总是重要的，但是用户体验对客户的忠诚度有着更大的影响—所有的尖端技术和品牌营销邮件都无法让这些客户再访问第二次。

客户忠诚度、ROI（投资回报率）、转化率（跟踪多少用户成功地掏腰包）—为企业创造价值而非变成资源消耗噩梦的项目。为企业创造价值vs资源消耗噩梦的项目。任何在用户体验上所做的努力，目的都是为了提高效率，基本上以两种形式体现出来：帮助人们工作得更快和减少他们犯错的几率。人们所使用工具效率的改进，会直接提高企业的整体生产力。效率所影响的不仅仅是最终的结果，当工作中用到的工具合乎规则、容易使用、不令人沮丧和没有必要的复杂性时，人们会更喜欢自己的工作。提高生产力，增加工作自豪感。

创建吸引人的、高效的用户体验方法称为“以用户为中心的设计”，其设计思想：在开发产品的每个步骤中，都要把用户列入考虑范围。连妥协都不是随机决定，用户体验的每一件事你都是应该经过慎重考虑和论证以后的决定。考虑用户的体验、把它分解成各种组成要素、从不同角度来了解它－只有这样，你才能确保你控制决策造成的全部结果。对于造访的用户来说，为他们规划一个有黏性的、直观明了、甚至还让人愉快的体验－一次“每件事都按照正确的方式在工作”的体验。不管他们这一天的其他时间是如何工作的。

第二章认识这些要素

用户体验的整个开发过程，都是为了确保在你的产品上的所有体验不会发生在你“明确的、有意识的意图”之外，要考虑用户有可能采取的每个行动的每种可能性，并且理解用户的期望值。清晰有条不紊地体验，事实上是由一系列完整的决策组成：网站看起来是什么样、它如何运转、它能让你做什么。这些决策彼此依赖，告知并影响用户体验的各个方面。

图片发自简书App

五个层面（表现－框架－结构－范围－战略）：

表现层：你看到的是一系列的网页，由图片和文字组成。一些图片可以点击从而执行某种功能。一些图片就只是图片。
框架层：表现层之下（按钮、控件、照片和文本区域的位置），用于优化设计布局，以达到这些元素的最大效果和效率－容易找到购物车按钮。
结构层：框架是结构的具体表达方式。框架层确定了在结账页面上交互元素的位置；而结构层则用来设计用户如何到达某个页面，并且在他们做完事情之后能去什么地方。框架层定义了导航条上各要素的排列方式，允许用户可以浏览不同的商品分类；结构层则确定哪些类别应该出现在那里。
范围层：结构层确定网站各种特性和功能最合适的组合方式，而这些特性和功能就构成了网站的范围层。任何功能是否应该成为网站的功能之一。
战略层：网站的范围基本上是由网站战略层所决定的。不仅仅包括经营者想从网站得到什么，还包括用户想从网站得到什么。一些战略目标显而易见，另一些目标（比如促销）可能并不是那么容易说清楚的。

自下而上地建设：在每个层面中，我们要处理的那些问题有的抽象，而有的则更具体，每一个层面都是根据它下面的那个层面来决定。最底层，我们完全不用考虑网站、产品或服务最终的外观－我们只关心网站如何满足我们的战略（同时满足用户的需求）。在最顶层，我们只关心产品锁呈现的最具体的细节。随着层面的上升，我们要做的决策就一点一点地变得具体，并涉及越来越细的细节。当我们做出的决定没有和上下层面保持一致的时候，项目常常会偏离正常轨道，完成日期延迟－开发团队试图把各种不匹配要素勉强凑在一起，费用也开始飞速上涨。在战略层上的决定将具有某种自下而上的“连锁效应”，每个层面的可用选择，都受到其下层面中所确定议题的约束，在每一个层面的决定都会影响到它之上层面的可用选项。这次你不意味着每个较低层面上的决策都必须在设计“较高层面”之前做出，事物的两面性－“较高层面”中的决定有时会促成对“较低层面”决策的一次重新评估（甚至是第一次评估）。每个层面都根据竞争对手所做的事情、业界最佳实践成果来做决定，这些决策可能产生的连锁效应应该是双向的。

应该计划好你的项目，让任何一个层面中的工作都不能在其下层面的工作完成之前结束。这里最重要的一条是，在我们知道基本形状之前，不能为其房屋加上屋顶。

当大家不能在基本的专用名词强达成一致的时候，事情很少能顺利进展。功能型产品（主要关注任务－所有的操作都被纳入一个过程，去思考人们如何完成这个过程，用于用户完成任务）+信息型产品（主要关注信息－网站应该提供哪些信息，这些信息对用户的意义什么）。

战略层：来自企业外部的用户需求是网站的目标+产品目标（功能型/信息型）
范围层：功能规格（功能型）+内容需求（信息型）
结构层：交互设计（功能型：定义系统如何响应用户的请求）+信息架构（信息型：合理安排内容元素以促进人类理解信息）
框架层：信息设计（功能型/信息型：促进理解的信息表达方式）+界面设计（功能型）+导航设计（信息型）
表现层：感知体验（功能型/信息型）

在某个层面中，不考虑其他要素影响，单独评估你在某个要素上所做的改进产生的效果是很困难的。你的团队里，不一定非要一个了解各个领域的专家；你只需要保证至少有一个人花一部分时间来考虑每一个议题就行了。

两个额外因素将会对最终用户体验产生影响：内容至上－用户认为有价值的内容+技术－技术总是变化，用户体验的领域必须要适应这些变化。

第三章战略层：产品目标和用户需求

成功的用户体验，其基础是一个被明确表达的战略。知道企业与用户双方对产品的期许和目标，有助于促进用户体验各方面战略的确定和制定。

导致网站失败最常见的原因不是技术，也不是用户体验，而是一开始没人试图回答两个非常基本的问题：我们要通过这个产品得到什么？（企业的产品目标）我们的用户要通过这个产品得到什么？（用户需求，企业外部目标）－设计用户体验每个决定的基础。此处的关键词是“明确”－当我们越清楚地表达我们想要什么，以及确切地知道其他人想要从我们这里得到什么时，我们就能越精确地满足对方需求。

产品目标：为明确地理解战略，第一步就是检查我们自己的产品或服务的目标。产品目标经常以“只可意会不可言传”的状态存在于一小群创建产品的人当中。当产品目标无法用口头表达出来时，对于应该如何完成产品，不同的人就经常会有不同的想法。人们常使用“商业目标”或“商业驱动因素”这样的词汇来描述内部的战略目标。通常一开始，宽泛目标，企业网站存在满足二选一的意图：替公司賺钱或替公司省钱，太具体目标无法充分描述其在战略制定过程中可能发生的困难。要想在太具体和太宽泛之间取得一个平衡，我们就应该避免在尚未充分了解问题前就试图得出结论（保证不随便决策，每个决定都应该建立在我们确切地了解它的影响力的基础之上）。明确定义“成功的条件”－而不是定义“通向成功的路径”－才能保证我们不会在这个阶段跑得太快。

品牌识别：任何一个网站需要明确描述，包括商标、色调和字体设计等视觉组成。但超越视觉表现－品牌识别可以是概念系统，也可以是情绪反应，无法不被用户注意。你必须要决定品牌形象是无意之中形成的，还是经过产品设计者有意精心安排的结果－大多数企业选择对品牌施加一些控制，品牌识别通常是产品目标的原因。靠用户体验来创造品牌形象。

成功标准：比赛都有终点。理解你的目标，有一个最重要的部分，就是理解你要怎样才能知道“什么时候到达了终点”。成功标准success metrics，可追踪的支持，产品上线后用来显示是否满足了我们自己的目标和用户需求。好的成功标准不仅影响项目各阶段的决策，也为衡量用户体验工作价值提供了具体的依据。平均停留时间，埋点，用户入线数，重复访问率（测量回访数据），注册用户每个月的访问次数，印象数～每个广告每天被展示数量等（也可以衡量对网站的间接影响：客户服务专线的电话数量应该相应减少，可以提供工具与资源的简便途径）。任何断章取义的标准都可能造成误导；请务必后退一步，看看网站外发生了什么事，以确定你了解到事情的全貌。

用户需求：理想化的用户就是“某些与我们完全一样的人”，我们并不是为自己设计，而是为其他人设计。如果想要“其他人”喜欢并使用我们创建的东西，就必须要了解“他们是谁”以及“他们的需求是什么”—只有投入时间去研究这些需求，我们才能抛弃自己立场的局限，真正从用户的角度来重新审视网站。确认用户需求时复杂的，因为用户群体之间存在着很大的差异性。要对这些用户需求寻根究底，必须要定义谁是我们的用户—对用户进行调研，询问他们问题，观察他们的行为。这些研究能帮助我们了解当用户使用我们的产品时，他们想要什么，同时也能帮助我们确定这些需求的优先级别。

用户细分：大量用户的用户需求分成几个可管理的部分，将用户分成更小的群组（或细分用户群）有共同需求的小组，每群用户都是由具有某些共同关键特征的用户所组成。市场营销人员通常依据人口统计学标准划分用户：性别、年龄、教育水平、婚姻情况、收入等。消费心态方案，用户对技术和网页本身的想法，经验或专业程度的不同，我们的设计必须要能容纳不同类型的用户群。【用户每周花费多少时间？计算机是生活的一部分？喜欢跟技术型产品打交道？使用最好硬件，不得不升级？】创建细分用户群只是一种用于“揭示用户最终需求的手段”，你真正只需要得到的是和你发现的“用户需求数目”一样多的细分用户群。

可用性和用户研究：想弄明白用户需要什么，我们首先必须知道他们是谁。用户研究的领域致力于收集必要的信息来达成共识。一些研究工具（问卷调查、用户访谈，或焦点小组）收集用户的普遍观点与感知、其他研究工具（用户测试或现场调查）则更适用于理解具体的用户行为以及用户在和产品交互时的表现。你想要的信息，被描述得越清楚，就能越具体、越有效地公式化你的问题，而只有这样才能确保你获得正确的答案。

现场调查是指一套完整、有效而全面的方法，用于了解在日常生活情境中的用户行为。它通常应用于一个较小的范围，并且执行方法都是一样的。现场调查的唯一缺点是它有时候会非常费时而且昂贵。如果你的资源充足，想期望对用户有更加深刻的理解，并且本次调查要求对用户有更加深刻的理解，一个全面的现场调查可以揭示一些无法通过其他方法获知的、极其细微的用户行为。

任务分析：每个用户与产品交互行为都发生在执行某一任务的环境，是一种仔细地分解用户完成任务的精确步骤的方法。有时任务比较具体，有时任务比较宽泛－任务分析是一种仔细地分解用户完成任务的精确步骤的方法。这种任务分解可以通过用户访谈完成，让用户讲述自己的故事，说出他们的经验；也可以通过现场调查来完成，在用户的“日常生活环境”中直接研究他们的行为。

用户测试：用户测试并不是测试你的用户；相反地，它是请用户来帮忙测试你的产品。有时用户测试用于测试一个已完成的网站，也可以用于测试改版的效果，或者用于在网站发布之前发现可用性的问题。另外，用户还可以测试一个正在建造中的网站，甚至是一个粗略的低保真原型。调查问卷与焦点小组要求在与对方面对面前，最好对你想要了解的问题有一个清楚的概念。这并不意味着用户测试必须严格地局限在“分析用户如何成功的完成某一项特定的任务”这类具体问题，了解一些广泛的、非具体的问题+让用户测试原型，大型项目在不同阶段使用不同的原型来搜集用户意见，这将贯穿到整个开发过程中。信息驱动的产品，卡片排序用于探索用户如何分类或组织各种信息元素。给用户一沓索引卡片，每张卡片附有信息元素的名字、描述，一张图像或内容的类型；然后用户根据小组或类别，依照自己感到最自然的方式将卡片排列出来。

可用性：有人认为它是一种测试方法，主要针对具有代表性的用户来设计测试方案；有人表示非常具体的开发方法。所谓可用性的最终目标，都是寻找令产品更容易使用的途径。可用性都有一个共同的核心概念：用户需求可用的产品，这的确是所有用户最普遍的需求。

创建人物角色：代表整个真实用户需求的虚构人物。通过赋予一张人物的面孔和名字，你将用户调查及用户细分过程中得到的分散资料重新关联起来，人物角色可以帮助你确保在整个设计过程期间把用户始终放在心里。

团队角色和流程：咨询公司有时会找到一个战略专家帮助客户处理项目中的这些问题。战略专家会与企业内部的许多人谈话，尽可能是全面地收集大家对产品目标与目标需求问题的不同看法。决策层是一群资深的决策者，他们管理那些会影响产品决策的部门。拟订决策底层员工经常被忽略，什么可行和不可行－特别是在用户需求方面，没有人比那些每天跟客户交谈的人更明白客户遇到的困难是什么的了。用户的反馈很少能传递到需要这些信息的产品开发团队中去。

产品目标和用户需求经常被定义在一个正式的战略文档或愿景文档中。这些文档不仅仅是列出目标清单—它提供不同目标之间的关系分析，并且说明这些目标要如何融入更大的企业环境中去。这些目标和对他们的分析经常由决策者、普通员工，和用户自己的直接意见来支持。这些意见生动地说明了项目中的战略制定问题，用户需求有时被记录在一个独立的用户调研报告中。撰写战略文档时，文档并不是越多越好－没有必要把每一个数据来源和相关的意见都写出来以表达你的观点，让文档简洁明了并切中要点。一个有效的战略文档不仅可以在用户体验开发团队起到试金石作用：它还可以成为企业其他部门的项目支持文档。

不让你的团队阅读战略文档是很糟糕的。战略文档并不是创建出来被藏到某个地方，或只与少数几个资深员工分享的—如果这些努力想要得到回报的话，在项目进行期间，此文档就必须被频繁地使用。所有参与者（设计师、程序员、信息架构师、项目经理）需要这份战略文档，以帮助他们在工作中做出正确的决定。战略文档通常包含敏感的资料，但仅仅因为这个就不告知应该理解战略目标的团队，只会破坏他们理解这些事情的能力。

战略应该是设计用户体验的流程中的起点，但不意味在项目开始之前的战略需要完全确定下来。但战略应该是可以演变和改进的。当战略被系统地修改与校正时，这些工作就能成为贯穿整个过程的、持续的灵感源泉。

第四章范围层：功能规格和内容需求

带着“我们想要什么”、“我们的用户想要什么”的明确认识，我们才能弄清楚如何去满足这些战略的目标。当你把用户需求和产品目标变成产品应该提供用户什么样的内容和功能时，战略就变成了范围。我们做的某些事是因为其过程具有价值，另一些事情是因为其产品具有价值。定义项目范围则同时在做这两件事：这是一个有价值的过程，同时能产生有价值的产品。过程的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略点。我们能确定现在能解决哪些事情，而哪些必须要再迟一点才能解决。产品的价值在于，被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的全部工作，它也提供了一门用于讨论这件事情的共同语言。定义好你的要求能保证在设计过程中不会出现模棱两可的情况。工作流程+日程安排+里程碑，项目得有尽头。

用文档来定义产品，这件事很麻烦，但是你必须要做。原因：#1、这样你才知道你真正建设什么（如果详细地记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候将达到这个目标），最终产品不再是一个只停留在产品经理头脑里的不定型图像，它变成了一个在企业内部每一个级别的每个人都触手可及的东西，从高层管理人员到入门级工程师，人人都能参与进来。口口相传容易出现信息误解或丢失。每个人都认为别人肩负着设计和开发产品关键环节的责任，但事实这个人并不存在。拥有一系列明确的要求，能让你把责任分配得更清晰，这样可以大大提高协作的效率。#2、这样你才知道你不需要建设什么。许多功能听上去都相当地诱人，但是它们对于项目的战略目标并不是必需的。项目进行时，关于功能的、各种各样的可能性都会浮现出来－想法出来用一个文档来记录它们，可以为你提供一个评估这些想法的架构，帮助你了解他们是如何（或是否）满足你当初所承诺要做的那些事。了解“不需要做什么”也就意味着知道哪些是你“不需要马上去做”的东西。把这些杰出的想法收集起来，找到一种适宜的方式，让它们符合你的长期规划，这才是真正的价值所在。有意识地管理你的要求，当前难以满足的需求，可以为启动下一个版本的基础。

范围层讨论战略层面的抽象问题－“我们为什么要开发这个产品？”转而面对一个新的问题：“我们要开发的是什么？”【功能型产品：功能规格－哪些应该被当成软件产品的功能以及相应的组合、信息型产品：内容－编辑和营销推广的传统领域】，使用feature特性来同时表示软件的功能和所提供的内容。范围层确定的是全部的功能需求或功能规格。一个内容管理系统可以实现自动化流程，能展示和交付内容用户【作者－内容编辑－管理层－文字编辑－律师－用户】，包括使用说明和错误提示等。

定义需求：一些需求适用于整个产品，品牌需求时最常见的一种；某些技术需求是另一种。大部分时候，当人们说到某种需求的时候，他们想的是产品必须拥有的、某种特性的一句简短描述。需求的详略程度常常取决于该项目的具体范围。如果该项目的目标是完成一个复杂的子系统，那么就需要有一个非常详细明确的需求，即使这个项目的范围相对于整个网站来讲非常小。如果大型项目的内容是相似或相同性质的东西，内容只需要一般化就可以了。最用之不竭的需求源泉总是来自用户本身。但更多时候，你的需求将来自与项目有关的同事－那些在企业中总想影响你产品的人。

不管哪种情况，去了解“人们在想什么”的最佳途径就是直接询问他们。得到需求将分成三个主要类别：最显而易见的是人们讲述的、他们想要的东西－清晰的好想法；口中说出、所期望的特性其实并不是他们的想要的，探讨解决办法和建议，有时候能真正解决问题的、完成不同的需求；第三种类型需求是人们不知道他们是否需要的特性。当你让人们讨论新的需求和战略目标时，他们有时会突然想起某个伟大的构思，而根本忘记了那个正在维护中的产品－这些通常会在头脑风暴讨论的时候出现，那正是与会者有机会参与和探讨项目的可能性的时候。具有讽刺意味的是，那些很少去想象产品新方向的人，恰恰是参与创建和设计产品最深入的人。当你把所有的时间都投入到维持现有产品时，你经常会忘掉哪些是真正的限制条件，而哪些是为了简化产品而曾经做过的选择。汇集企业各个部门的成员或不同类型的用户代表来进行头脑风暴会议，是一种打开设计者思路、让他们考虑以前从未想到的可能性的、非常有效的工具（听取从自己不熟悉的角度出发来考虑的、对产品的观点，并给予反馈，可以鼓励人们从多角度全方位地思考开发中的产品遇到的问题及解决办法）。

人物角色（personas）通过创建虚拟人物来帮助我们更好地理解用户需求。我们决定功能需求的时候，可以再次使用这些人物角色，虚拟人物放入故事，场景化－一个场景是一个简短的故事，简单描述一个人物角色会如何完成这些用户需求。通过“想象我们的用户将会经历什么样的过程”，帮助他顺利完成这个过程的潜在需求。或研究竞争对手……

功能规格说明：文档不能解决问题，但定义可以。我们需要的不是文档有多厚或有多详细，而是要足够清楚和准确。功能规格说明不需要包含每一个细节－只需要包含在设计或开发过程中出现有可能混淆的功能定义。同时功能规格说明也不需要展望产品未来的理想化状态－只需要记录在创建这个产品时已经确定下来的决议。

记下来：无论这个项目有多么庞大或者多么复杂，有几条规则适用于撰写任何类型的功能规格说明。

乐观be positive。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。比如［这个系统不允许用户购买没有风筝线的风筝］，替换成［如果用户想买一个没有线的风筝的话，这个系统应该引导用户到风筝线页面］。
具体be specific。尽可能详细地解释清楚情况，这是我们能决定一个功能是否被实现的最佳途径。最受欢迎的视频要重点关注 vs 上一周被播放最多的视频要显示在列表的最前端
避免主观的语气avoid subjective language。保持明确和避免歧义，功能规格必须可验证－它必须要能证明“这个需求没有被满足”。比较主观［这个网站的风格应该是时尚、闪耀的］－客观［网站的外观应该符合企业的品牌指南文档］。可以量化地定义一些功能，通过这样的手段来避免主观性。

内容需求：文本+图像+音频+视频，不要混淆某段内容的格式和它的目的。FAQ（常见问题）一系列简短的问题和回答，这个词仅仅指的是内容的格式。一个FAQ的真正价值，在于它可以随时提供用户普遍需要的信息。内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素大小、下载的文件字节、PDF或音频文件等相对独立元素的大小。

尽可能早地取得某个人来负责每一个内容元素也是非常重要的。内容不仅需要初次上线，还需要日常维护工作（更新频率，在用户期望值和有效资源之间的一个合理的中间值），可能还需要为不同用户呈现不同内容。对于大量内容的项目来说，内容信息都记录在内容清单。虽然繁琐但必要：团队中每个人才能确切知道他们设计用户体验需要做哪些工作，熟悉要做哪些事情。

确定需求优先级：收集潜在需求或想法不是很困难。最棘手的是排列哪些功能包含进现有项目，有时一个战略目标将产生多个需求；另一个方面一个需求也可以实现多个战略目标。需求和战略目标可能多对多，项目范围建立在战略基础上，满足网站目标或用户需求，加上实现这些需求的可行性有多大。有些特性因为技术局限无法实现，有些特性需要很多资源去做，有些特性需要快速上线－很少有功能独立存在，特性冲突不可避免，需要一起权衡得到连贯统一的产品。留意那些看上去有可能需要改变战略的特性建议，它们在制定愿景文档期间并不明显。任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除。有特性不在项目范围，超越限制条件，听起来非常不错，重点审视某些战略目标。解决管理层之间的争论的最好办法是要求制定战略—关注目标，而不是实现手段。对决策者表示认同，是解决特性冲突的关键。战略目标之间的重要程度也可能不同。

第五章结构层：交互设计与信息架构

在定义好用户需求并排列好优先级后，我们对于最终产品将会包括什么特性已经有了清楚的图像。然而，这些需求并没有说明如何将这些分散的片段组成了一个整体。这就是范围层上面一层：为网站创建一个概念结构。将我们的关注点从抽象的决策与范围问题，转移到更能影响最后的用户体验的具体因素。然而，在抽象和具体之间的分隔线有时会变得模糊不清—虽然我们在此时做出的决定对最终产品将会产生显而易见、真实可触的影响，但是这里所做的决策本身仍然包括大部分的概念性内容。

交互设计为用户设计结构化体验，功能型产品+内容建设主要是通过信息架构来构建用户体验，信息型产品【考虑组织管理、分类、顺序排列、图书管理、新闻学、技术通信等学科】，理解用户的工作方式、行为和思考方式。交互设计和信息架构都强调一个重点：确定各个将要呈现给用户的元素的模式（pattern）和顺序（sequence），交互设计关注于将影响用户执行和完成任务的元素、信息架构则关注如何将信息表达用户的元素。

交互设计关注于描述“可能的用户行为”，同时定义“系统如何配合与响应”这些用户行为。成功的舞蹈是要求每一个参与者能够预测对方的移动，传统的程序员最关注的两个方面：它做什么和它怎么做（关注细节，技术效率更高）。与其针对机器的最佳工作方式来设计系统，不如说按用户的行为方式来设计系统。

概念模型：用户对于“交互组件讲怎样工作”的观点，可以反映系统的一个组件或是整个系统。软件是否把某个特性处理成用户所熟悉的某个概念？规划好概念模型能帮助你做出一致的设计决定。内容元素是一个位置还是对象并不重要：重要的是网站能够将这些内容元素从头到尾一致地表现出来，而不是有时候将元素当成位置，有时候又当成的对象。零售商品和产品目录的概念模型似乎都可以完美地让用户从网上发出订单，一个令人不太熟悉的概念模型只有在用户能正确理解并诠释它的时候才能起到作用－打破传统也没有错，只要有一个好理由说明“为什么这样做”。我们不必将概念模型明确地告诉我们的用户，理想情况下我们不需要告诉用户，用户使用网站靠直觉，网站交互行为与他们隐含的期望完全相符。

错误处理（交互设计会处理每个级别的错误，以确保更高比例的用户能有积极的体验－预防、改正、恢复）：第一个同时是最好的防止错误的方法，是将系统设计成不可能犯错的那种（让大部分用户错误都不要发生，可并不简单）、第二个避免错误的方法是使错误难以发生，系统应该帮助用户找出错误并且改正它们，某些情况下甚至可以系统自动纠错－有效的错误信息和容易自我解释的界面可以在错误发生后帮助用户纠正、第三是错误恢复，撤销功能，对于那些不可能恢复的错误，提供大量的警告就是系统唯一可提供的预防方法，但这种错误只有在用户实际注意到它时才能产生作用。

信息架构：研究的是人们如何认知信息的过程，对产品而言，信息架构关注的就是呈现给用户的信息是否合理并且具有意义。

结构化内容，设计组织分类和导航的结构，让用户可以高效率、有效地浏览网站的内容。信息架构与信息检索密切相关，设计出让用户容易找到信息的系统。许多情况下，网站的结构还必须教育、通知或说服用户。信息架构要求创建分类体系【从上到下－将从战略层所考虑的内容，即根据产品目标与用户需求直接进行结构设计，先从最广泛、有可能满足决策目标的内容与功能开始进行分类，然后再根据逻辑细分出次级分类；从下到上－已有资料放进去最低级别的分类，然后归属到较高级别，逐步构建出能反应我们的产品目标和用户需求的结构】，从上到下易忽略重要细节，从下到上可能导致架构不能容纳未来内容的变动或增加。不一定非要给某个级别或部分结构加上一个特定数目限制，结构质量是最重要的标准，多少步并不严格，而是每个步骤必须是合理的，当前的步骤是否自然延续了上一个步骤的任务。清晰定义的过程而非令人困惑的过程。一个高效结构的优点就是具备“容纳成长和适应变动”的能力－新内容的积累最终将会使你再次审视网站的组织分类原则。一个完整的用户体验，包括网站结构，都是建立在对网站目标和用户需求的理解之上的。
结构方法，信息架构的基本单位是节点，节点可以对应任意的信息片段或组合－小到数字，大到图书馆。我们要处理的是节点，而不是页面、文档或组件，使用一种共同语言和共同结构的概念来对付各种不同的问题。节点的抽象性使得我们能明确地设定我们的关注点的详略程度。层级结构－父子级节点，树形结构或中心辐射结构；矩阵结构－允许用户在节点与节点间沿着多纬度移动；自然结构－不会遵循任何一致的模式，节点逐一被连接起来，没有太强烈的分类概念。自然结构对于探索一系列关系不明确或一直在演变的主题很合适。但没有给用户提供一个清晰的指示；线性结构：连贯的语言流程。
组织原则：节点在信息架构中是依据组织原则来安置的。决定哪些节点要编成一组，哪些节点要保持独立标准。不同组织原则将被应用在不同的区域和网站不同的层面。一般来说，你在产品最高层级使用的组织原则应该紧密地与“网站目标”和“用户需求”相关，而较低层级，内容与功能需求将对你所采取的组织原则产生重大影响。我们的困难不是创建一个结构，而是创建一个能与“我们的目标”和“用户需求”相对应的、正确的结构。战略告诉我们用户的需求是什么，范围则告诉我们什么样的信息将满足那些用户需求。在创建结构时，我们就要具体地识别出用户心目中至关重要的那些信息。成功的用户体验，就是能事先预知用户的期望并将其纳入设计之中。截面（属性）
语言和元数据：使用用户的语言并且保持一致性是非常重要的，强调一致性的工具称为受控词典（网站使用的一套标准语言），包括了解你的命名原则：描述、标签，和网站使用的其它术语。受控词典是网站使用的一套标准语言，与用户谈话并了解他们的沟通方式，是开发出一个让用户感到自然的命名原则系统的最有效方式，防止企业内部的专用术语侵入网站的最佳方法。类词词典－提供常见的、未纳入该网站标准用语的词汇以供选择。

元数据：关于信息的信息，即以一种结构化的方式来描述内容的信息。将搜索引擎与类词词典连接起来，再加上元数据，就能让搜索引擎变得更聪明。

团队角色和流程：文档一定要描述清楚网站的结构－从命名原则和元数据的具体细节，到信息架构和交互设计的整体概况－根据项目复杂度不同，可以走很大的不同。信息架构或交互设计主要文档是示意图，视觉化地呈现结构，表述“分支、群组、组件之间的联系”－互联网早期这种示意图叫做网站地图，现在用架构图。这种架构图并不一定要写明网站每一页的每个链接，太细只会造成混淆并且屏蔽了团队真正需要的信息。架构图最重要的是记录概念关系：哪些类别需要放在一起，而哪些需要保持独立？在交互过程中那些步骤要怎样互相配合？作者提出“视觉辞典”，一个提供从非常简单（上图）到非常复杂（下图）的示意结构系统。“到底谁在负责信息架构”，用户体验设计师－你是否有一位专家来解决结构问题并不重要，重要的是这些问题能由某个人来负责。不论你是不是做过这方面的规划，你的网站都会有一个结构。一个建立在明确规划的网站，会减少频繁检查维护的工作量，也能为网站的所有者带来可见的结果，同时还能满足他们的用户的需求。

第六章框架层（界面设计、导航设计和信息设计）

结构层界定了我们的产品将用什么方式来运作，框架层则用于确定用什么样的功能和形式来实现。除了解决具体的这些议题，框架层还要处理更精确的细节问题。在结构层，我们看到了一个较大的架构和交互的设计；在框架层，我们的关注点几乎全部在独立的组件以及它们之间的关系上。

对于功能型产品，通过界面设计来确定框架－“按钮、输入框和其他界面控件”的领域；对于信息型产品，要解决导航设计，专门用于呈现信息的一种界面形式。最后，信息设计是功能和信息两方面都必须要做的，它用于呈现有效的信息沟通。即使这些边界有时会变得模棱两可，但是把它们定义成独立的领域仍然能帮助我们更明确地评估是否已经找到了合适的解决方案。“好的导航设计”不能纠正“不好的信息设计”－如果涉及提供给用户做某些事的能力，则属于界面设计（界面的意思是通过它用户能真正接触到那些“在结构层的交互设计中”确定的“具体功能”）；如果是提供给用户去某个地方的能力，属于导航设计（信息架构把一个结构应用到我们设定好的“内容需求列表”之中），导航设计则是一个用户能看到那个结构的镜头，这就表示通过它，用户可以“在结构中自由穿行”；如果是传达想法给用户的话，这就是“信息设计”，这个层面中范围最广的一个要素（跨越了“以任务为导向”的功能型产品和“以信息为导向”的信息型产品的边界）

习惯和比喻：习惯使我们可以把反射作用应用到不同环境中。建立一个成功的用户体验，要求你在做每一个决定的时候都有充分的、明确的理由。三秒钟也可能有挫折感：下意识就能完成的事情变成难以忍受的缓慢。让你的界面与用户早已养成的那些习惯保持一致很重要，给用户一个统一的处理方式，从系统其他部分学习。网站特性的概念模型有助于你保持内部一致性。不应该过于强调交互设计背后的概念模型，应该抑制在产品四周建立起比喻的冲动。网站内容应该提供一定程度的上下文，从而帮助用户更好地猜测你所采用的比喻试图代表什么样的特性。提供内容和功能越多，猜测就变得越不可靠，更好的做法就是完全去除猜测的成分。有效地使用比喻，就是要减少用户在“理解和使用你的产品功能”时对猜测的要求。

界面设计：要做的全部事情就是选择正确的界面元素。这些界面元素要能帮助用户完成他们的任务，还要通过适当的方式让它们容易被理解和使用。一个任务通常都会跨过多个界面来完成，每个界面都包含一组不同的界面元素，这些正是用户要与之战斗的对象。哪个功能要在哪个界面上完成，是我们在结构层的交互设计中已经决定的；而这些功能在界面上如何被用户认知到，则属于界面设计的范畴。成功的界面设计是那些能让用户一眼就看到“最重要的东西”的界面设计；不重要的东西不应该被注意到－有时候因为它根本就没有出现在那儿。设计复杂系统的界面所面临的最大挑战之一，是弄清楚用户不需要知道哪些东西，并减少它们的可发现性。好的程序员总是要考虑到很少发生的场景，边缘情况－经验丰富的程序员总是平等地对待每一种可能性（界面设计行不通，让少数用户满意的设计不良的界面不好）。一个设计良好的界面是要组织好用户最常采用的行为，同时让这些界面元素用最容易的方式获取和使用。

界面第一次呈现给用户的时候，仔细考虑每一个选项的默认值。自动记住用户最后一次选择状态的系统－技术工具和体系自身的局限使得我们可选择的界面选项受到限制。复选框、单选框、文本框、下拉菜单、多选菜单、按钮－视觉和界面空间

导航设计：必须满足三个目标（首先必须提供给用户一种在网站间跳转的方法，把每个页面和别的都链接起来是不现实的，导航元素必须选择那些能促进用户行为的－这些链接必须是真实有效的；导航设计必须传达出这些元素和他们所包含内容之间的关系。仅仅提供一个链接的列表是不够的。这些链接互相之间有什么关系？是否其中一些比别的更重要？它们之间相关的差异在哪？这些传达出来的信息对于用户理解“哪些选择对他们是有效的”是非常重要的；导航设计必须传达出它的内容和用户当前浏览页这个页面有什么影响？这些传达出来的信息帮助用户去理解“哪个有效的选择会最好地支持他们的任务或他们想要达到的目标”）－网站中需要清晰地告诉用户“他们在哪儿”以及“他们能去哪儿”非常重要的原因。

导航系统：全局导航（提供了覆盖整个网站的通路，它提供的是用户最有可能需要从网站的最终页面到其他什么地方的一组关键点。在导航栏放上能到网站所有主要栏目的链接。不管你想去哪儿，你都能从全局导航中最终到达那儿）、局部导航（提供给用在这个架构中附近地点的通路，只提供父级、兄弟级和子级通路）、辅助导航（提供了全局导航或局部导航不能快速达到的相关内容的快捷途径）、上下文导航（嵌入页面自身内容的一种导航，需要回到战略层才能设计得越高效）、友好导航（提供给用户他们通常不会需要的链接，他们作为一种便利的途径来使用。比如零食商店、联系信息、反馈表单和法律声明等。远程导航）、网站地图（给用户一个简明的、单页的网站整体结构的快捷浏览方式，网站的一个分级概要出现，通常不会显示超过两个层级的导航－这之后更详细的内容往往超出用户的需求）、索引表（按字母顺序、链接到相关页面的列表，网站试图相对独立地服务于拥有不同信息需求的不同用户）。

信息设计：充当一把各种设计元素聚合到一起的粘合剂。信息设计变成决定如何呈现这些信息，使人们能很容易使用或理解它们。饼图？柱状图？望远镜？放大镜？涉及“分组”或“整理”散乱的信息，把这方面的设计看成是理所当然。最关键的是用一种能“反映用户的思路”和“支持他们的任务和目标”的方式来分类和排列这些元素信息。在这些元素之间的概念关系是真正属于微观信息架构的；当我们必须要在页面上传达结构的时候，信息设计就呈现它的作用了。界面＝收集信息+呈现信息，错误提示+使用手册。不管什么时候，系统都应该给用户提供能正确使用系统的信息，这些都是信息设计的工作范畴。

指示标识：信息设计+导航设计结合，帮助用户理解“它们在哪”以及“他们能去哪”的系统，甚至“哪条路离目标更近”。指示标识的概念来自于物理世界中公共空间的设计。在网站中，指示标识通常会涉及导航设计和信息设计。一个网站的导航系统不仅仅是要提供到网站不同区域的通路，还必须要清晰地传达出这些选项。图标、标签系统和排版

线框图：页面布局是将信息设计、界面设计和导航设计放置到一起，形成一个统一的、有内在凝聚力的架构。页面布局必须结合所有类型的导航系统，每一个旨在传达不同结构中的视图设计；也必须结合任何一个在这个页面的功能所需要的所有界面元素；还包括支持以上这些内容的信息设计，当然也包括在这个页面上内容的信息设计本身。页面布局被纳入一个详细的文档，并称为页面示意图或线框图（对一个页面所有的组成部分以及它们如何结合到一起的、最直观的描述）－捕获所有在框架层做出的决定，并用一个文档来显示他们。

这些简单的线条绘制的图一般要着重注明、建议读者在必要的时候参考结构图表或其他交互设计文档、内容需求或功能规格说明，或者其他类型的详细文档。结构层的结构图示，它是这个项目的一个宏伟远景；而在框架层，线框图正是展示那些远景如何完成的详细文档。线框图有时也需要导航规格的支持，以便能更详细、准确地描述各种导航元素的每一个组成成分。不需要为网站的每个界面都准备一个线框图。线框图在正式建立网站的视觉设计流程中，是必要的第一步，但是几乎每一个参与这个开发过程的人都会在其他任务点中使用它。负责战略层、范围层和结构层的设计者可以借助线框图来保证产品能满足他们的期望。真正负责建设这个网站的人，则使用线框图来回答关于网站应该如何运作的问题。

作为信息架构和视觉设计汇集的地方，线框图变成了争论和纠纷的中心。共同协作画出细节，站在对方角度看待一件事，及早揭示出问题而不是到后来，撰写正确的文档。轻量级即时贴还是正式文档，取决于规则。线框图是整合在框架层的全部三种要素的方法：通过安排和选择界面元素来整合界面设计；通过识别和定义核心导航系统来整合导航设计；通过放置和排列信息组成部分的优先级来整合信息设计。把这三者放到一个文档中，线框图就可以确定一个建立在基本概念结构的架构，同时指出来表现层的设计应该前进的方向。

第七章表现层（感知设计）

内容、功能和美学汇集到一起来产生一个最终设计，完成其他四个层面的所有目标，并同时满足用户的感官感受。在框架层，我们主要解决放置的事情，界面设计考虑可交互元素的布局，导航设计考虑在产品中引导用户移动的元素的安排，而信息设计考虑传达给用户的信息要素排布。表现层这里解决并弥补“产品框架层的逻辑排布”的感知呈现问题。用户体验的最后一站：视觉、听觉、触觉、嗅觉和味觉。

嗅觉和味觉通常取决于那个产品所选用的材料，而非用户体验设计师所能决定的
触觉，工业设计领域，主要关注的是用户和产品之间的物理接触。手机和手持游戏设备都可以通过振动来与用户互动。
听觉，通知用户，可以使产品变得有个性
视觉，每个人的美感见解不同，但不意味着设计决策必须建立在所有参与者都认为酷的方案，应该把注意力集中在它们的“运作是否良好”上。

忠于眼睛：你的视线首先落在什么地方？哪个设计要素在第一时间吸引了你的注意力？他们对于战略目标来讲很重要吗？用户第一时间注意到到的东西与他们的目标背道而驰吗？眼球追踪仪器确定被测人到底正在看什么，以及他们的视线如何在这个屏幕上移动的。用户在页面上的视线移动并不是随机的。如果你的设计是成功的，用户眼睛的移动轨迹的模式应该有以下两个重要的特点：首先它们遵循的是一条流畅的路径。如果人们评论一个设计是“忙碌”或“拥挤”时，这表示这个设计确实没能顺利地引导他们在页面上移动。他们的眼睛在各种各样的元素之间跳来跳去，所有的元素都在试图引起他们的注意；其次，在不需要用太多细节来吓倒用户的前提下，它为用户提供有效选择的、某种“可能”的引导。这些引导应该支持用户试图在此刻通过与产品交互去完成的某个目标和任务。也许更重要的是，这些引导不应该分散用户对那些“能完成目标的信息或功能”的注意力。

对比和一致性：把用户的注意力吸引到界面中的关键部分，过度的对比导致了混乱的视觉。对比能帮助用户理解页面导航元素之间的关系。当一个元素在设计中显得与众不同时，用户就会注意到，这是他们不能控制的－利用这个本能的行为，来使用户注意到那些“真正需要从这个页面的其他元素中突出的东西”。在页面界面上的错误提示通常会被融进页面的其他元素中：通过给文本一些不同的颜色或用一个醒目的图形将它们凸现出来，就能让整个界面完全不同了。

不管怎样，这些工作的整体策略是，让差异必须足够清晰，用户要足够分辨出某个设计选择是特意要传达一些信息的。当两个设计元素的处理相似又不太一样的时候，用户就会感到困惑。“为什么这些会不一样？它们本来是一样吗？也许只是弄错了，还是我应该在这里注意到什么东西吗？”而事实是，我们希望这两者都能抓住用户的目光，而且是有意而为之。

设计中保持一致性，能使你的设计有效地传达信息，而不会导致用户迷惑或焦虑。“一致性”在视觉设计的许多不同方面都会起到作用。视觉元素保持大小一致的尺寸。

基于栅格线的布局是来自平面设计的一种技术，是一种对网页也同样有效的技术。这个方法通过使用母版来确保设计的一致性，各种布局都是根据这个模板来创建的。不是每个布局都要使用栅格的每一个部分，但是每一个元素在网格上的位置应该是统一和一致的。但屏幕交互式产品不会像平面设计一样简单－不教条。不管什么原因，你要能认识到什么时候应该重新考虑设计系统的基础是什么。栅格系统：但栅格应用到屏幕交互式产品上不会像平面设计一样简单。

内部和外部的不一致：内部不一致就是产品的两个不同地方反映了不同的设计方法－建立对网站框架的深刻理解，其中关键在于确定有可能在产品各种各样的界面、导航和信息设计等不同环境中反复出现的设计元素，设计前将每个设计元素独立出来可以更清楚地看到困扰我们的小规模，一次设计，到处使用－但需要考虑不同场景的使用情况，最好的办法是设计出每一个独立的元素，试着在不同的环境中应用它们，然后在需要的时候进行调整；外部不一致就是这个产品没有在同一企业的其他产品中，反映出被使用的、相同的设计方法。即使大多数的设计元素被相对独立地设计出来，它们最终还是要放到一起的。一个成功的设计不仅仅是收集小巧的、精心设计的东西；相反，这些东西应该能形成一个系统，作为一个有凝聚力、连贯的整体拉使用。用一个“统一的品牌识别形象”强化呈现在你的用户面前产品“跨媒体的一致性”，这种品牌识别的一致性应该呈现出在你的产品的每一个层级的设计中，从每个界面都会出现的导航元素到只出现一次的普通按钮。人们会对那些具有明确定义的企业产生积极向上的印象。不统一的视觉样式会破坏你的企业形象的清晰程度，并且留给访问者一个“企业还没搞清楚自身定位”的坏印象。

配色方案和排版：核心的品牌色彩通常是一个广泛的配色方案，企业所有材料应该得到的。一个企业的标准配色方案中所使用的色彩，互补不冲突。大多数情况下，更亮或更醒目的色彩可以用于设计你的前景色－那些你希望得到更多注意的元素；更暗淡的色彩最好用于不需要跳出页面的背景元素中。差异足够但保持一致。一些企业使用排版增强他们的品牌识别－用设计传达形象，任何文本，简单就好，大多数情况下不需要太多字体来满足你的沟通需求。不要使用非常相似但又不完全一样的风格，只有在你需要传达不同信息时才使用不同的风格。风格之间要有足够的“对比”才能在你需要的时候吸引到用户的注意，但是不要使用过于广泛和多样的风格。

视觉模拟或设计合成品：合成就是从已选定的组件中建立起来的、一个最终的可视化产品。独立组件如何结合在一起，必须考虑约束条件。线框图侧重于记录框架层，首先能独立地了解到框架层的问题，然后再关心到表现层的问题。视觉设计不一定要精确地按照线框图来做－只要它考虑了相关的重要级别以及线框图中各元素的组合关系。

随着时间的推移，我们的决策原因会逐渐从记忆中消失，也有人最后离开－带走了产品如何设计出来、如何在日常基础工作上建立起来的丰富知识。那些“在某种特殊环境下用来解决某个具体问题的临时决策”和那些“为了形成将来的设计工作的基础而有意识地做出的决策”会混杂在一起。承载这些设计决策的权威性文档是风格指南－汇总文档确定了视觉设计的每个方面，从最大到最小范围内的所有元素。影响到产品的每一个局部的全局标准（比如设计栅栏、配色方案、字体标准或标志应用指南）通常是风格指南中的第一部分。风格指南还要包括某一个模块或网站功能的具体标准。在某些情况下，在风格指南中所记录的标准，应该包含各个层级的标准从独立界面到统一的导航元素。风格指南的总体目标是提供足够的细节来帮助人们将来做明智的决策－因为大部分想法都已经为他们实现了。让所有的这些人遵循一套统一的标准运作，需要做大量的工作。风格指南形成一个协调一致的整体。

第八章要素的应用

不管你的产品有多复杂，用户体验要素都是一样的。但是，将这些要素背后的想法付诸实施却是一次自我挑战。这不仅仅是时间和资源的问题－它常常是一个心态的问题。战略、范围、结构、框架和表现，高度注意细节，全职专家小组来进行，专家可以专注于完整的用户体验的某一方面，他们通常对自己承担那部分工作有更加深刻的理解。几个人的小组实际上可以产生比一个大团队要好得多的结果。创建良好的用户体验最重要的工作内容是大量收集亟待解决的非常细微的问题。“成功的方法”和“注定会失败的方法”差异两点：了解你正在试着去解决的问题（按钮大小、按钮位置、按钮不是用户期望的功能）、了解这些解决办法所造成的后果（每个决定对上下层面的连锁反应，必须同时考虑五个层面的全部因素－有专人负责固然重要，更重要的是保证所有的用户体验要素都被关注）。

由现状决定的设计、由模仿决定的设计、由领导决定的设计。需要解决纠缠不清的小问题，必须在不同的做法间做出妥协并评估利弊和进行取舍，左右为难时正确的做法是，每一个决定都建立在对背后议题的理解之上。与用户体验相关的第一个问题恐怕是问自己：你为什么要这么做？对于你即将面临的问题抱有一种正确的心态是最重要的。每一个用户体验的设计过程的其他方面都有可能导致调整，以适应时间、金钱和为你工作的人员。不要以“节省项目时间或金钱”的名义对用户体验敷衍了事－在结束时附加的用户体验评估，最后你可能会发布一个明知道已经被破坏却没有机会去修复的产品。没有时间收集用户数据？可以看看自己拿到手的信息、客服日志或反馈，找到用户需求的一些感觉、负担不起租用可用性实验室费用？做一些非正式的测试。

用户“接受度”：问题不是说他们是否会喜欢或是否会使用这个产品，而不是他们是否接受它。这些测试往往发生在整个流程的最后。很多人提倡将用户测试作为确保良好用户体验的一个主要手段，但测试永远无法取代一个考虑周密的、准备充分的用户体验设计过程。询问你的用户关于产品的某个具体元素的问题，能帮助你收集来自用户的更多相关信息。没有着眼于用户体验的用户测试，很可能以提出错误的问题而告终，这相反又会导致你得到错误的答案。“不要用不相关的内容来把事情搞得更混乱”－不管创建什么样的用户体验，其最大的挑战是“比用户自己更准确地去理解他们的需求”。

马拉松和短跑：企业中永远处于紧急情况下的开发团队太多了，用户体验开发过程是一场马拉松而不是短跑－了解你所参加的比赛类型才能用适合的方式去参赛。短跑在发令枪响那一刻聚集起所有储备的能量－而且他们必须要在那几分钟碰发出所有的能量，开始到结束都要尽可能块地奔跑。成功的马拉松取决于运动员如何有效地控制自己的步伐－何时加速+何时减速，耐性。产品开发很少是短跑比赛－建立原型和想法，随着时间推移，返回来，测试你所建立起来的东西，看看各个组成部分如何结合在一起，并且为这个项目提炼出出一个综合的画面。有些任务需要重点承担速度，有些则需要一个更加深思熟虑的方法。经过深思熟虑的设计决策，可能会在短期内花费一定的时间，但它们将在一个更长时期中节省更多的时间。设计师和开发者总是在他们工作进行到某个阶段时，才后悔没有提前关注战略、范围和结构。恶性循环从底向上从网站开发的时候，始终从完整的用户体验出发，最后得到的网站是一份有价值的资产。每一件与网站的用户体验有关的事情都是有意识地、明确地决策的结果，只有这样你才能确保这个网站能同时满足你的战略目标和用户需求。