1700423244
另一个用户测试的方法是让用户测试原型。原型可以是各种形式，从纸上的草图，到低保真度的、用脚本实现的模拟界面，以及看上去像是一个已完成的产品和“可点击”的高保真原型。大型项目在不同的阶段使用不同的原型来搜集用户意见，这将贯穿到整个开发过程中。
1700423245
1700423246
有些用户测试根本不需要用产品或原型。可以招募用户来参加各种不同的活动，只要这些活动可以让你洞察用户如何看待并使用你的产品的。对于由信息驱动的产品，卡片排序法（card sorting）用于探索用户如何分类或组织各种信息元素。给用户一沓索引卡片，每一张卡片附有信息元素的名字、描述，一张图像或内容的类型。然后用户根据小组或类别，依照自己感到最自然的方式将卡片排列出来。分析几位用户的卡片排列结果，就可以帮助我们了解用户对产品信息的看法。
1700423247
1700423248
1700423249
1700423250
1700423251
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422469]
1700423252
用户体验要素：以用户为中心的产品设计（原书第2版） 创建人物角色
1700423253
1700423254
收集各种各样的用户数据将是非常有价值的，但有时候你会忽略统计数字背后所代表的真正人物。因此，通过创建人物角色（personas）—有时也叫做用户模型或用户简介—你可以让你的用户变得更加真实。人物角色是能代表整个真实用户需求的虚构人物。通过赋予一张人物的面孔和名字，你将用户调查及用户细分过程中得到的分散资料重新关联起来，人物角色可以帮助你确保在整个设计过程期间把用户始终放在心里。
1700423255
1700423256
让我们来看一个例子。假设我们的网站是一个为刚开始创业的人提供信息的网站。从研究中得知，我们的大部分用户将是30～45岁的人。总体来说，我们的用户普通倾向于对互联网与高科技有相当高的适应程度。有些用户甚至在商业领域有很多经验；而另一些，则是第一次自己经营这样的商务活动。
1700423257
1700423258
在这种情况下，或许应该创建两个人物角色。我们把第一个人物角色称为Janet。她42岁，已婚并有两个孩子。她过去几年在一家大型会计师事务所担任副总裁。她不满于为他人工作，现在她想要建立自己的公司。
1700423259
1700423260
第二个角色是Frank。他37岁，已婚，有一个孩子。木材加工是Frank多年的周末爱好。他的一些朋友非常喜欢他制作的家具，因此他认为他可以尝试出售他的家具作品。为了开拓他的新生意，他正在犹豫是不是要因此放弃目前校车司机的工作。
1700423261
1700423262
这些信息来自哪里呢？很大程度上是我们编造的。我们希望人物角色与我们从用户研究中了解的内容保持一致，但是为了使人物角色更加栩栩如生，他们的一些具体细节可以是虚构的。
1700423263
1700423264
当我们决定产品用户体验的设计时，我们必须要紧记Janet和Frank所代表的不同用户群的需求。为了帮助我们记住他们和他们的需求，我们要找出一些合适的照片来让Janet和Frank的形象更加鲜明，然后将他们的相关信息与这些照片合并到一起。这些人物角色档案可以印出来并且张贴在办公室周围，这样当我们要做决定时候，可以问自己：“那会对Janet有用吗？Frank会有什么反应呢？”人物角色能帮助我们在前进的每一步都时时记着用户。
1700423265
1700423266
1700423267
1700423268
1700423269
在用户体验设计的过程中，人物角色是从用户研究中提取出的、可成为样例的虚构人物。
1700423270
1700423271
1700423272
1700423273
1700423274
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422470]
1700423275
用户体验要素：以用户为中心的产品设计（原书第2版） 团队角色和流程
1700423276
1700423277
战略问题影响参与用户体验设计过程的每一个人。但是，尽管事实是这样（或许就因为它），明确这些目标的责任人常常是受到争议的。咨询公司有时会找一个战略专家（strategists）帮助客户处理项目中的这些问题—但由于聘请这类稀缺的专家通常非常昂贵，同时战略专家并不直接负责建设网站的任何一部分，这项支出就常常成为第一个被裁减的项目预算。
1700423278
1700423279
战略专家会与企业内部的许多人谈话，尽可能全面地收集大家对于产品目标与用户需求问题的不同看法。决策层（stake holder）是一群资深的决策者，他们管理那些会影响产品决策的部门。例如，该产品是为了提供给顾客进入在线产品支持信息而设计的，决策层可能就会包括市场销售部门的代表、客服部门还有产品经理。它取决于企业在做决策制定时的正式流程（以及那些难以言喻的政治现状）。
1700423280
1700423281
在拟定决策时有一群人经常被忽略，那就是普通员工—这些人负责让企业每天正常运作。这些人通常比他们的经理更知道“什么行得通”和“什么不可行”—特别是在用户需求方面。没有人比那些每天跟客户交谈的人更明白客户遇到的困难是什么的了。我经常很惊讶地发现，用户的反馈很少能传递到需要这些信息的产品开发团队中去。
1700423282
1700423283
产品目标和用户需求经常被定义在一个正式的战略文档（strategy document）或愿景文档（vision document）中。这些文档不仅仅是列出目标清单—它提供不同目标之间的关系分析，并且说明这些目标要如何融入更大的企业环境中去。这些目标和对它们的分析经常由决策者、普通员工，和用户自己的直接意见来支持。这些意见生动地说明了项目中的战略制定问题。用户需求有时被记录在一个独立的用户调研报告中（将所有信息集中在一个地方有某些好处）。
1700423284
1700423285
撰写战略文档时，文档并不是越多越好。你没有必要把每一个数据来源和相关的意见都写出来以表达你的观点，让文档简洁明了并切中要点。请记得，许多将要阅读此文档的人不会有时间或兴趣翻阅上百页的参考资料，与其让他们惊讶于你交付的文档的重量，还不如让他们直截了当地理解这些战略来得更重要。一个有效的战略文档不仅可以在用户体验开发团队中起到试金石作用；它还可以成为企业其他部门的项目支持文档。
1700423286
1700423287
不让你的团队阅读战略文档是很糟糕的。战略文档并不是创建出来被藏到某个地方，或只与少数几个资深员工分享的—如果这些努力想要得到回报的话，在项目进行期间，此文档就必须被频繁地使用。所有参与者（设计师、程序员、信息架构师、项目经理）需要这份战略文档，以帮助他们在工作中做出正确的决定。战略文档通常包含敏感的资料，但仅仅因为这个就不告知应该理解战略目标的团队，只会破坏他们理解这些事情的能力。
1700423288
1700423289
战略应该是设计用户体验的流程中的起点，但那不意味在项目开始之前你的战略需要完全确定下来。虽然设法击中一个移动的目标可能会浪费很多时间和资源（更不用说极大的内心挫折感），但是战略也应该是可以演变和改进的。当战略被系统地修改与校正时，这些工作就能成为贯穿整个过程的、持续的灵感源泉。
1700423290
1700423291
1700423292
1700423293