用户体验要素以用户为中心的产品设计原书第2版.docx
《用户体验要素以用户为中心的产品设计原书第2版.docx》由会员分享，可在线阅读，更多相关《用户体验要素以用户为中心的产品设计原书第2版.docx（28页珍藏版）》请在冰点文库上搜索。
用户体验要素以用户为中心的产品设计原书第2版
用户体验要素：
以用户为中心的产品设计（原书第2版）
目录
用户体验要素：
以用户为中心的产品设计（原书第2版）1
第1章用户体验为什么如此重要4
日常生活中的遭遇4
什么是用户体验4
从产品设计到用户体验设计4
为体验而设计：
使用第一5
用户体验和网站5
用户体验就是商机5
在乎你的用户6
第2章认识这些要素6
五个层面6
自下而上地建设7
基本的双重性7
用户体验的要素8
应用这些要素9
第3章战略层用户目标和用户需求9
战略层定义9
产品目标9
用户需求11
团队角色和流程12
第4章范围层功能规格和内容需求13
范围层定义13
定义需求14
功能规格说明14
内容需求15
确定需求优先级15
第5章结构层交互设计与信息架构16
结构层定义16
交互设计16
概念模型16
信息架构17
团队角色和流程19
第6章框架层界面设计、导航设计和信息设计20
框架层定义20
习惯和比喻20
界面设计21
导航设计21
信息设计22
线框图22
第7章表现层感知设计22
表现层定义22
合理设计感知22
忠于眼睛23
对比和一致性23
内部和外部的一致性23
配色方案和排版23
设计合成品和风格指南23
第8章要素的应用24
提出正确的问题24
马拉松和短跑24
第1章用户体验为什么如此重要
日常生活中的遭遇
什么是用户体验
在开发过程中，人们更多地关注产品将用来做什么。
用户体验是经常被忽略的另一个因素—即产品如何工作—而这一因素恰恰是决定产品成败的关键因素。
用户体验并不是指一件产品本身是如何工作的，用户体验是指“产品如何与外界发生联系并发挥作用”，也就是人们如何“接触”和“使用”它。
当人们询问你某个产品或服务时，他们问的是使用的体验。
它用起来难不难？
是不是很容易学会？
使用起来感觉如何？
从产品设计到用户体验设计
大部分时候，当提到“产品设计”时，人们往往会想到的是产品在感官方面的表现：
精心设计的产品，看起来赏心悦目，而且给用户很好的触感。
另外一种常见的、评价产品的角度，则是与“功能”有关的：
精心设计的产品必须要具有它应该具有的功能，而烂产品却往往不是这样：
刀刃很锋利的剪刀不能剪东西，打印机总是卡纸，等等。
以上两种观点都不能算是真正的“设计”，有些产品可能很好看且功能正常，但将“设计一个用户体验良好的产品”作为明确的目标，意味着不仅仅是功能或外观那么简单。
“外形服从于功能”的观点对于产品的内部运作（那些用户不可见的部分）是完全使用的。
但是，对于产品直接面对用户的那些部分—按钮、布局、文字，也包括外观，正确的产品形态绝对不是由“功能”所决定的，而是应该由“用户自身的心理感受和行为”来决定的。
用户体验设计同城要解决的是应用环境的综合问题。
为体验而设计：
使用第一
产品越复杂，确定如何向用户提供良好的使用体验就越困难。
在使用产品的过程中，每一个新增的特性、功能或步骤，都增加了导致用户体验失败的机会。
用户体验和网站
不管用户访问的是什么类型的网站，它都是一个“自助式”的产品。
没有事先可以阅读的说明书、没有任何操作培训或讨论会、没有客户服务代表来帮助用户了解这个网站。
用户所能依靠的只有自己的智慧和经验，来独自面对这个网站。
在大多数网站发展的过程中，仅仅是“去理解人们所想和所需”这样一件简单的事，都从来没有得到过重视。
用户体验就是商机
如果你的网站主要是有网站专家们称为“内容”的网站类型组成—也就是说，信息—那么这个网站的主要目的之一，就是尽可能有效地传达那些信息。
仅仅把它们放在那儿是远远不够的。
它必须用一种能帮助人们理解和接受的方式呈现出来。
否则，用户永远不会发现你所提供的服务或产品正是他们在寻找的。
即使它们能找到这些信息，用户也很可能得出一个结论：
如果你的网站很难使用，恐怕你也一样。
即使你的网站包括了一些交互的小工具，用来帮助人们完成某个任务（比如购买机票或管理银行账户），高效的沟通仍然是决定你的产品是否成功的关键因素。
如果用户弄不明白它是怎样工作的，你所提供的“世界上最强大的功能”将摇摇欲坠，并以失败而告终。
一个最常用的投资收益的度量标准是转化率（conversionrate）。
任何时候，你都想鼓励你的客户在和你建立某种关系的时候采取更进一步的行动—不管是像“用户定制个人偏好网站”一样复杂的行动、还是像“登录并接受Email简讯”一样简单的行动—你总是可以用转化率来衡量这个结果。
通过跟踪有百分之多少的用户被你“转化”到了下一个步骤，就能衡量你的网站在达到“商业目的”方面的效率有多高。
转化率是一种常用的方式，来衡量用户体验的效果。
3个注册并订阅邮件的用户/36个访问者=8.33%的转化率
任何在用户体验上所做的努力，目的都是为了提高效率。
这基本上是以两种主要形式体现出来的：
“帮助人们工作的更快”和“减少他们犯错的几率”。
效率所影响的不仅仅是最终的结果。
当工作中用到的工具合乎规则、容易使用、不令人沮丧和没有不必要的复杂性的时候，人们会更喜欢自己的工作。
在乎你的用户
创建吸引人的、高效的用户体验的方法称为“以用户为中心的设计（user-centereddesign）”。
以用户为中心的设计思想非常简单：
在开发产品的每一个步骤中，都要把用户列入考虑范围。
对于那些来网站造访的用户，你必须为他们规划一个有粘性的、直观明了的、甚至还让人愉快的体验—一次“每件事都按照正确的方式在工作”的体验。
第2章认识这些要素
用户体验的整个开发流程，都是为了确保用户在你的产品上的所有体验不会发生在你“明确的、有意识的意图”之外。
这就是说，要考虑到用户有可能采取的每一个行动的每一种可能性，并且去理解在这个过程的每一个步骤中用户的期望值。
五个层面
表现层
在表现层（surface），你看到的是一系列的网页，由图片和文字组成。
一些图片是可以点击的，从而执行某种功能，例如把你带到购物车里去的购物车图标。
一些图片就只是图片，比如一个促销产品的照片或网站自己的标志。
框架层
在表现层之下是网站的框架层（skeleton）：
按钮、控件、照片和文本区域的位置。
框架层用于优化设计布局，以达到这些元素的最大效果和效率—使你在需要的时候，能记得标识并找到购物车的按钮。
结构层
与框架层相比更抽象的是结构层（structure），框架是结构的具体表达方式。
框架层确定了在结账页面上交互元素的位置；而结构层用来设计用户如何到达某个页面，并且在他们做完事情之后能去什么地方。
框架层定义了导航条上各要素的排列方式，允许用户可以浏览不同的商品分类；结构层则确定哪些类别应该出现在那里。
范围层
结构层确定网站各种特性和功能最适合的组合方式，而这些特性和功能就构成了网站的范围层（scope）。
比如，有些电子商务网站提供了一个功能，使用户可以保存之前的邮寄地址，这样他们可以再次使用它。
这个功能（或任何一个功能）是否应该成为网站的功能之一，就属于范围层要解决的问题。
战略层
网站的范围基本上是由网站战略层（strategy）所决定的。
这些战略不仅仅包括了经营者想从网站得到什么，还包括了用户想从网站得到什么。
就网上商店的例子而言，一些战略目标是显而易见的：
用户想要买到商品，我们想要卖出它们。
另一些目标（如促销信息，或者用户填写的内容在商务模型中扮演的角色）可能并不是那么容易说清楚的。
自下而上地建设
每一个层面都是根据它下面的那个层面来决定的。
但是，这不是是说每一个“较低层面”上的决策都必须在设计“较高层面”之前做出。
事物都有两个方面，在“较高层面”中的决定有时会促成对“较低层面”决策的一次重新评估（甚至是第一次评估）。
在每一个层面，我们都根据竞争对手所做的事情、业界最佳的实践成果来做决定，这是最简单不过的老常识。
这些决策可能产生的连锁效应应该是双方向的。
基本的双重性
网站具有功能性和信息性。
功能型的平台类产品，信息型的媒介类产品。
在功能型产品这边，我们主要关注的是任务—所有的操作都被纳入一个过程，去思考人们如何完成这个过程。
在这里，我们把网站看成用户用于完成一个或多个任务的一组工具。
相应地，在信息型产品这边，我们的关注点是信息—网站应该提供哪些信息，这些信息对用户的意义是什么。
创建一个富信息（information-rich）的用户体验，就是提供给用户一个可以寻找、理解，且有意义的信息组合。
用户体验的要素
战略层
无论是在功能型产品还是信息型产品，战略层所关注的内容都是一样的。
来自企业外部的用户需求（userneed）是网站的目标—尤其是那些将要使用我们网站的用户。
我们必须要了解这些观众想从我们这儿得到什么，还要知道他们想达到的这些目标将怎样满足他们所期待的其他目标。
与用户需求相对应的，是我们自己对网站的期望目标。
这些产品目标（productobjective）可以是商业目的（通过网站达到今年100万美元的销售收入）或者是其他类型的目标（让选民了解下一届候选人的情况）。
在第3章，我们将了解更多这些要素的细节。
范围层
从战略层进入范围层以后，在功能型产品一侧它就转变成创建功能规格（functionalspecification）：
对产品的“功能组合”的详细描述。
而在信息型产品一侧，范围则是以内容需求（contentrequirement）的形式出现：
对各种内容元素的要求的详细描述。
结构层
在功能型产品一侧，结构层将从范围转变成交互设计（interactiondesign），在这里我们可以定义系统如何响应用户的请求。
在信息型产品一侧，结构层则是信息架构（informationarchitecture）：
合理安排内容元素以促进人类理解信息。
框架层
框架层被分成了三个部分。
不管是功能型产品还是信息型产品，我们必须要完成信息设计（informationdesign）：
一种促进理解的信息表达方式。
对于功能型产品，框架层还包括了界面设计（interfacedesign），或者也可以说安排好能让用户与系统的功能产生互动的界面元素。
对于信息型产品，这种界面就是导航设计（navigationdesign）：
屏幕上的一些元素的组合，允许用户在信息架构中穿行。
表现层
不管是功能型产品还是信息型产品，在这里，我们的关注点是一样的：
为最终产品创建感知体验（sensoryexperience）。
应用这些要素
还有两个额外的因素，它们将会对最终的用户体验产生影响。
首先就是内容（content），用户不会仅仅为了体验导航的乐趣而访问网站。
其次，技术（technology）也像内容一样，对于建立一个成功的用户体验很重要。
技术总在变化，用户体验的领域必须要适应这些变化。
第3章战略层用户目标和用户需求
成功的用户体验，其基础是一个被明确表达的“战略”。
知道企业与用户双方对产品的期许和目标，有助于促进用户体验各方面战略的确立和制定。
战略层定义
导致网站失败最常见的原因不是技术，也不是用户体验。
而是在开始写第一行程序、描第一个像素，或配置第一个服务器之前，没有人试图回答下面两个非常基本的问题：
●我们要通过这个产品得到什么？
●我们的用户要通过这个产品得到什么？
回答了第一个问题，我们才能据此描述出企业的产品目标（productobjectives）。
第二个问题则提出了关于用户需求（userneeds）的问题，这是来自企业外部的目标。
结合内外两者，“产品目标”和“用户需求”就组成了战略层，也就成为我们在设计用户体验过程中做出每一个决定的基础。
此处的关键词是明确（explicit）。
当我们能越清楚地表达我们想要什么，以及确切地知道其他人想要从我们这里得到什么时，我们就能越精确地满足双方的需求。
产品目标
当产品目标无法用口头表达出来时，对于应该如何完成产品，不同的人就经常会有不同的想法。
商业目标
多数人一开始是用很宽泛的词汇来描述产品目标的。
基本上，企业网站的存在是为了满足两种意图中的一个：
替公司赚钱或替公司省钱。
有时它同时满足这两个。
但为了这两个目标，网站到底应该做些什么并不总是很清楚。
相反地，太具体的目标也无法充分地描述出在战略制定过程中可能发生的困难。
例如，写明你的目标是“为用户提供一个实时的文本通信工具”，并不能解释这个工具要如何支持企业目标，或是它如何满足用户需求。
品牌识别
对于任何一个网站，它需要明确描述的基础目标之一就是品牌识别（brandidentify）。
品牌识别—可以是概念系统，也可以是情绪反应—它之所以重要是因为它无法不被用户注意。
在用户与产品交互的同时，企业的品牌形象就不可避免的在用户的脑海中形成了。
你必须要决定品牌形象是无意之中形成，还是经过产品设计者有意精心安排的结果。
将品牌形象具体且明确地写进目标，将会提高呈现出积极的品牌形象的机会。
成功标准
理解你的目标，有一个最重要的部分，就是理解你要怎样才能知道“什么时候到达了终点”。
这就是成功标准（successmetrics）：
即一些课追踪的指标，在产品上线以后用来显示它是否满足了我们自己的目标和用户的需求。
有时这些成功标准与网站本身和用户如何使用该网站有一定的关系。
用户在每一次访问网站时的平均停留时间是多少？
如果你想要鼓励用户随意轻松地发掘网站提供的服务，那么你一定希望看到单次访问的时间有所增加。
相反地，如果你想要提供快捷简便的信息或功能服务，那么你或许希望单次访问的时间减少。
不是所有的成功标准必须直接由网站获得。
也可以衡量对网站的间接影响。
用户需求
确认用户需求是复杂的，因为用户群体之间存在着很大的差异性。
要对这些用户需求寻根究底，必须要定义谁是我们的用户。
一旦我们知道哪些人群是我们想要了解的，就可以对他们进行调研—换句话说，询问他们问题，观察他们的行为。
用户细分
我们可以把大量的用户需求划分成几个可管理的部分，这将通过用户细分（usersegmentation）来完成。
我们将用户分成更小的群组（或细分用户群），每一群用户都是由具有某些共同关键特征的用户所组成。
人口统计学
消费心态档案
创建网站或任何一个技术型产品时，有另一组非常重要的属性也需要考虑：
用户对技术和网页本身的想法。
由于对技术有恐惧心理的用户和高级用户在使用网站的方式上非常不同，因此我们的设计必须要能容纳不同类型的用户群。
除了了解用户对于技术的熟悉程度和适应程度，我们还需要知道他们对于网站相关内容的知识有多少。
卖厨具给一般人与卖给专业厨师的处理方式必须非常不同。
这些在经验或专业程度上的不同就形成了我们细分用户群的基本维度。
人们使用信息的方式经常取决于他们的社会或专业角色。
例如学生家长和那些报考大学的学生对于信息的需求就不尽相同。
因而定义产品使用者的不同角色可以帮助你区别并分析他们的各种需求。
创建细分用户群只是一种用于“揭示用户最终需求的手段”。
你真正只需要得到的是和你发现的“用户需求数目”一样多的细分用户群。
创建细分用户群还有其他重要的原因。
不仅仅是因为不同的用户群有不同的需求，还因为有时候这些需求是彼此矛盾的。
如适合炒股新手的软件不一定适合炒股专家。
很明显，我们无法提供一种方案可以同时满足这两种用户的需求。
此时，我们要么选择针对单一用户群设计而排除其他用户群，要么为执行相同任务的不同用户群提供不同的方式。
不论我们选择哪一种，这个决策将会影响日后与用户体验相关的每一个选择。
可用性和用户研究
问卷调查、用户访谈、焦点小组、现场调查、任务分析、用户测试
任务分析的概念是任务每一个用户与产品的交互行为都发生在执行某一任务的环境中。
有时任务非常具体（譬如买电影票），而有时任务比较宽泛（譬如学习国际商务章程）。
任务分析是一种仔细地分解用户完成任务的精确步骤的方法。
这种任务分解可以通过用户访谈来完成，让用户讲述自己的故事，说出他们的经验；也可以通过现场调查来完成，在用户的“日常生活环境”中直接研究他们的行为。
用户测试（usertesting）是另一种常见的用户调研方法。
是请用户来帮忙测试你的产品。
对于由信息驱动的产品，卡片排序法（cardsorting）用于探索用户如何分类或组织各种信息元素。
创建人物角色
通过创建人物角色（personas）—有时也叫作用户模型或用户简介—你可以让你的用户变得更加真实。
人物角色是能代表整个真实用户需求的虚构人物。
通过赋予一张人物的面孔和名字，你将用户调查及用户细分过程中得到的分散资料重新关联起来，人物角色可以帮助你确保在整个设计过程期间把用户始终放在心里。
团队角色和流程
决策层（stakeholder）是一群资深的决策者，他们管理那些会影响产品决策的部门。
普通员工的需求在考虑用户需求时不可忽略。
产品目标和用户需求经常被定义在一个正式的战略文档（strategydocument）或愿景文档（visiondocument）中。
这些文档不仅仅是列出目标清单—它提供不同目标之间的关系分析，并且说明这些目标要如何融入更大的企业环境中去。
这些目标和对它们的分析经常由决策者、普通员工，和用户自己的直接意见来支持。
这些意见生动地说明了项目中的战略制定问题。
用户需求有时被记录在一个独立的用户调研报告中。
第4章范围层功能规格和内容需求
带着“我们想要什么”、“我们的用户想要什么”的明确认识，我们才能弄清楚如何去满足这些战略的目标。
当你把用户需求和产品目标转变成产品应该提供给用户什么样的内容和功能时，战略就变成了范围。
范围层定义
过程的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点。
我们能确定现在能解决哪些事情，而哪些必须要再迟一点才能解决。
产品的价值在于，被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的全部工作，它也提供了一门用于讨论这件事情的共同的语言。
定义好你的要求能保证在设计过程中不会出现模棱两可的情况。
用文档来定义产品需求，是由于以下两个主要原因：
原因#1：
这样你才知道你正在建设什么
原因#2：
这样你才知道你不需要建设什么
所有在项目开始如火如荼地进行时，关于功能的、各种各样的可能性都会浮现出来。
当这些想法出现的时候，用一个文档来记录它们，可以为你提供一个评估这些想法的架构，帮助你了解他们是如何（或是否）满足你当初所承诺要做的那些事。
了解你“不需要做什么”也就意味着知道哪些是你“不需要马上去做”的东西。
把这些杰出的想法收集起来，找到一种适宜的方式，让它们符合你的长期规划，这才是真正的价值所在。
确定具体、系统的发展要求，并将任何不符合这些要求的想法作为潜在的未来功能囤积起来，只有通过这种更慎重的途径，你才能真正管理整个设计过程。
功能和内容
我们要开发的是什么？
在功能型产品方面，我们考虑的是功能需求规格（functionalspecifications）—哪些应该被当成软件产品的“功能”以及相应地组合。
在本章中，将使用一个词“特性（feature）”来同时表示软件的功能和所提供的内容。
在软件开发中，范围层确定的是全部的功能需求或功能规格（functionalspecifications）。
有些企业用这些术语来表示两种不同的文档：
在项目初期，这个词表示需求，描述系统应该做什么；在项目末期，这个词表示功能规格说明，描述系统真正完成了什么。
在这种定义中，“功能规格”在“功能需求”确定之后才开始撰写，同时将加入具体的实施细节。
功能需求或任何一种技术类产品也常常伴随着内容的需求。
如，在“个人喜好设置”的页面中需要有使用说明吗？
定义需求
最用之不竭的需求源泉总是来自用户本身。
但更多地时候，你的需求将来自于项目利益相关的同事—那些在企业中总想影响你的产品的人。
不管是哪种情况，去了解“人们在想什么”的最佳途径就是直接询问他们。
需求的三个主要类别：
首先，最显而易见的是人们讲述的、他们想要的东西。
这中间有一部分是非常清晰的好想法，会通过各种途径体现在最终产品上。
有时候人们口中说出来的、所期望的特性其实并不是他们想要的，当人们在某个过程或者某个产品中遭遇到一些困难时，想象有某种解决办法可以缓解这一困难，对任何人来讲都是很正常的反应。
有时这个解决办法是行不通的，或者治标不治本的办法。
通过与用户探讨这些建议，有时候可以得出真正的、完全不同的需求。
第三种类型的需求是人们不知道他们是否需要的特性。
这需要让不同的人一起谈论同一个产品，开阔思路。
在决定功能需求的时候，可以将虚拟的人物角色放到一个简短的故事之中，我们称之为“场景”。
一个场景是一个简短的故事，简单描述了一个人物角色会如何完成这些用户需求。
通过“想象我们的用户将会经历什么样的过程”，我们就可以找到能帮助他审理完成这个过程的潜在需求。
我们也期望从竞争对手处得到一些启示。
功能规格说明
文档不能解决问题，但定义可以。
我们需要的不是文档有多厚或多详细，而是要足够清楚和准确。
功能规格说明文档不需要包含产品的每一个细节—只需要包含在设计或开发过程中出现有可能混淆的功能定义。
同时规格说明也不需要展望产品未来的理想化状态—只需要记录在创建这个产品时已经确定下来的决议。
记下来
撰写功能规格说明的规则：
乐观（bepositive）。
描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。
具体（bespecific）。
尽可能详细地解释清楚状况，这是我们决定一个功能是否被实现的最佳途径。
避免主管的语气（avoidsubjectivelanguage）。
这是另外一种使需求“保持明确”和“避免歧义”的途径—因而也避免了误解的可能性。
功能规格必须可验证—就是说，它必须要能证明“这个需求没有被满足”。
如：
这个网站的风格应该是时尚、闪耀的。
这个网站应该符合邮递员Wayne所期望的时尚。
网站的外观应该符合企业的品牌指南文档。
内容需求
内容特性想要达到的规模，将对你所做出的用户体验决策产生极大的影响。
尽可能早地确定某个人来负责每一个内容元素也是非常重要的。
定义每一个内容特性的“更新频率”。
关于内容的信息记录在内容清单（contentinventory）中。
确定需求优先级
战略目标和需求之间，几乎看不到一对一的简单关联。
有时一个需求可以满足多个战略目标。
同样，一个战略目标也常常关系到不同的需求。
由于项目范围是建立在战略层的基础上的，因此我们应该去评估这些需求是否能满足我们的战略目标（无论是网站目标还是用户需求）。
此外，我们还要额外确定第三种范围：
实现这些需求的可行性有多大？
可能是技术局限或资源局限，也可能是时间局限。
如果是时间局限，可以把这个特性放到下一个版本或项目里程中。
由于管理层常常分不清楚特性和战略，某些特性总是会占据上风。
因此需求的定义过程就变成了与这些管理层进行谈判的过程。
控制谈判的过程会非常困难。
解决管理层之间的争论的最好办法是要求“制定战略”。
关注战略目标，而不是各种实现手段。
当你面对的是一个总是把注意力放在某个战略目标特征上的高层决策者，如果你能向他保证他所关注的这个特征可以用另一个方式来满足的话，他就不会感觉自己的意见被忽略了。
对决策者的需求表示认同，是解决特性冲突的关键。
第5章结构层交互设计与信息架构
结构层定义
在传统的软件开发行业，涉及“为用户设计结构化体验”的方法被称为交互设计（interactiondesign）。
在内容建设方面，主要是通过信息架构（infor
升级会员 