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
1700423294
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422471]
1700423295
用户体验要素：以用户为中心的产品设计（原书第2版） 第4章 范围层 功能规格和内容需求
1700423296
1700423297
带着“我们想要什么”、“我们的用户想要什么”的明确认识，我们才能弄清楚如何去满足这些战略的目标。当你把用户需求和产品目标转变成产品应该提供给用户什么样的内容和功能时，战略就变成了范围。
1700423298
1700423299
1700423300
1700423301
1700423302
1700423303
1700423304
1700423305
1700423306
1700423307
1700423308
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422472]
1700423309
用户体验要素：以用户为中心的产品设计（原书第2版） 范围层定义
1700423310
1700423311
我们做的某些事是因为其过程具有价值，就像慢跑或练习钢琴一样。而我们做的另一些事情是因为其产品具有价值，就像做一块蛋糕或修理一辆汽车。定义项目范围则同时在做这两件事：这是一个有价值的过程，同时能产生有价值的产品。
1700423312
1700423313
过程（process）的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点。我们能确定现在能解决哪些事情，而哪些必须要再迟一点才能解决。
1700423314
1700423315
产品（product）的价值在于，被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的的全部工作，它也提供了一门用于讨论这件事情的共同的语言。定义好你的要求能保证在设计过程中不会出现模棱两可的情况。
1700423316
1700423317
我曾经设计过一个似乎永远是Beta版的Web应用系统：差不多，但还是没准备好向真正的用户推出。用我们的方法去做的许多事情都是不对的—技术不稳定、我们好像根本不了解用户、同时我是整个企业中唯一一个在Web开发方面有一些经验的人。
1700423318
1700423319
但是这些都不是导致我们不能推出这个产品的真正原因。这个项目最大的绊脚石是没有一个人愿意去定义需求。毕竟，当我们所有的人都在同一个办公室里工作时，记下每一件事是很麻烦的。除此以外，产品经理也需要把他的精力集中在新功能的思考上。
1700423320
1700423321
这样做的结果，就产生了一个不断变化的、混合了完整产品的各个阶段功能的产品。只要有人读到的一篇新文章或一个新的想法，都会启发这个产品负责人的灵感，然后考虑增加另一个功能特性。我们倒是有一个固定的工作流程（working flow），但是没有日程安排（schedule），没有里程碑（milestones），项目也看不到尽头。因为根本就没有人知道这个项目的范围，又怎么能知道它应该在什么时候结束呢？
1700423322
1700423323
用文档来定义产品需求，这件事很麻烦，但是你必须要做。这是由以下两个主要原因：