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
用文档来定义产品需求，这件事很麻烦，但是你必须要做。这是由以下两个主要原因：
1700423324
1700423325
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422473]
1700423326
原因#1：这样你才知道你正在建设什么
1700423327
1700423328
这似乎很明显，但是它对于正在开发某个产品应用程序的团队却一个惊喜。如果详细地记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候将达到这个目标。最终产品不再是一个只停留在产品经理头脑里的不定形的图像，它变成了一个在企业内部的每一个级别的每一个人都触手可及的东西，从高层管理人员到入门级的工程师，人人都能参与进来。
1700423329
1700423330
如果没有文档的要求，你的项目很可能会变成一个叫作“电话”的校园游戏—在团队中的每一个人都有各自关于产品的想法，然后通过口口相传的方式传递出去，每个人的描述都略有不同。甚至更糟的可能是，每个人都认为别人肩负着设计和开发产品关键环节的责任，但事实上这个人并不存在。
1700423331
1700423332
拥有一系列明确的要求，能让你把责任分配得更清晰，这可以大大提高协作的效率。在了解了一个详细策划的完整范围之后，你就可以看到各个相对独立、也不显著的要求之间的内在联系。举个例子来讲，在早期的讨论中，支持文档和产品规格表可能看起来像是独立的功能内容，但是把它们作为要求确定下来，会让这种有所交叠的事情更加明显，并且同一个小组的人可以把它们都负担起来。
1700423333
1700423334
1700423335
1700423336