当你把用户需求和产品目标转变成产品应该提供给给用户什么样的内容和功能时，战略就变成了范围。
一、范围层定义
项目范围在做两件事：这是一个有价值的过程，同时能产生有价值的产品。
1.过程的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点。我们能确定现在能解决哪些事情，而哪些必须要再迟一点才能解决。
2.产品的价值在于，被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的全部工作，它也提供了一门用于讨论这件事情的共同的语言。定义好你的要求能保证在设计过程中不会出现模棱两可的情况。
用文档来定义产品需求，这件事很麻烦，但是你必须要做。这是由于以下两个主要原因：
原因1:这样你才知道你正在建设什么
如果详细地记录下你正在建设的内容，每个人就会知道这个项目的目标是什么，什么时候将达到这个目标。最终产品不再是一个只停留在产品经理头脑里的不定型的图像，它变成了一个在企业内部的每一个级别的每一个人都触手可及的东西，人人都能参与进来。
原因2:这样你才知道你不需要建设什么
许多功能听上去都相当地诱人，但是它们对于项目的战略目标并不是必需的。此外，所有在项目开始如火如荼地迂进行时，关于功能的各种各样的可能性都会浮现出来。当这些想法出现的时候，用一个文档来记录它们，可以为你提供一个评估这些想法的架构，帮助你了解他们是如何（或是否）满足你当初所承诺要做的那些事。
当前难以满足的需求，可以成为启动下一个版本的基础，这样就能形成一个不断循环的开发过程。
二、功能和内容
在范围层，我们从讨论战略层面的抽象问题——“我们为什么要开发这个产品？”转而面对一个新的问题：“我们要开发的是什么？”
在软件开发中，范围层确定的是全部的功能需求或功能规格。在项目初期，这个词表示需求，描述系统应该做什么；在项目末期，这个词表示功能规格说明，描述系统真正完成了什么。
1.内容需求
内容设计者要坐下来仔细考量各种资料的来源，然后才能决定哪些信息必须纳入设计范围之内。这种定义内容需求的过程，实际上与技术专家和董事会集体商议功能需求，并回顾已有的文档记录没有本质上的区别。两者的意图和方法是一样的。
2.内容管理系统
现在，真正的内容常常是通过一个内容管理系统来进行管理的。这些系统大小不一，大的系统能根据众多不同的数据来源动态生成页面，庞大而复杂；小的可以是一个很轻巧的工具，能以最高效的方式来优化并管理各种类型的内容专题。
三、定义需求
需求的详略程度常常取决于该项目的具体范围。最用之不竭的需求源泉总是来自用户本身。但更多的时侯，你的需求将来自与项目利益相关的同事—那些在企业中总想影响你的产品的人。
获得需求的几种类型：
（1）首先，最显而易见的是人们讲述的、他们想要的东西。
（2）有时候人们口中说出来的、所期望的特性其实并不是他们想要的，遇到问题时想出的解决办法是行不通的，或者仅仅是治标不治本的办法。通过与用户探讨这些建议，你有时候可以得出能真正解决问题的、完全不同的需求。
（3）当你让人们讨论新的需求和战略目标时，他们有时会突然想起某个伟大的构思，而根本忘记了那个正在维护中的产品。这些通常会在头脑风暴讨论的时候出现，那正是与会者有机会参与和探讨项目的可能性的时候。
（4）让一个工程师、一个客服人员、一个营销人员坐到一间会议室中谈论同一个产品，这会对大家都有启发意义。听取从自己不熟悉的角度出发来考虑的、对于产品的观点，并给予反馈，可以鼓励人们多角度全方位地思考开发中的产品遇到的问题以及解决办法。
（5）不管你设计的产品在什么样的设备上使用（或者我们正在设计的就是那个设备）我们的需求序列必须要考虑到硬件需求。
（6）在决定功能需求的时候，我们可以使用用户画像，把我们的虚拟人物放到一个简短的故事之中，描述了一个人物角色会如何完成这些用户需求。通过“想象我们的用户将会经历什么样的过程”，我们就可以找到能帮助他顺利完成这个过程的潜在需求。
（7）我们也期望从竞争对手处得到一些启示。任何一个在做同件事的企业基本上在试图满足同样的用户需求，同时也在试图完成相似的产品目标。
四、功能规格说明
我们需要的不是文档有多厚或有多详细，而是要足够清楚和准确。功能规格说明不需要包含产品的每一个细节，只需要包含在设计或开发过程中出现有可能混淆的功能定义。同时功能规格说明也不需要展望产品未来的理想化状态—只需要记录在创建这个产品时已经确定下来的决议。
功能规格说明的几条规则：
1.乐观
描述这个系统将要做什么事去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。
2.具体
尽可能详细地解释清楚状况，这是我们能决定一个功能是否被实现的最佳途径。
3.避免主观的语气
这是另外一种使需求“保持明确”和“避免歧义”的途径—因而也避免了误解的可能性。
五、内容需求
1.定义和范围
很多时候我们说到的内容指的是文本。但是图像、音频和视频有时候有可能比其文字还要重要。这些不同类型的内容可以结合到一起，相互协作去满足某一个需求。
2.注意事项
（1）不要混淆某段内容的格式和的目，当关注点是格式时，目的本身就可偷可能被遗忘。多半的结果是FAQ（常见问题）忽略了这个词汇中“常见”两个字，内容设计者总是用其他一些问题的答案替代了能真正满足FAQ需求的答案。
（2）内容特性想要达到的规模，将对你所做出的用户体验决策产生极大的影响。内容需求应该提供每一个特性规模的大致预估：文本的字数、图片的像素大小、下载的文件字节、PDF或；音频文件等相对独立元素的大小等。这些大小的估计不一定要非常精确一大致相近即可。
（3）尽可能早地确定某个人负责每一个内容元素也是非常重要的。如果我们在没有确定谁将会负责这些内容需求的情况下，过早过多地投入到开发流程中去，那么最后我们得到的很可能就是一个千疮百孔的产品，因为那些在假想阶段人人都喜欢的特性，将在实际执行的时候变得非常沉重。
（4）从你的网站目标来看，你希望用户多长时间来访问一次？从你的用户需求来看，他们希望多长时间更新一次信息？无论如何，对于你的用户而言较为理想的更新频率（“我要马上了解每一件事，24小时服务！”）也许对你的企业来说不切合实际。但你必须要确定一个频率，它是介于你的用户期望值和有效资源之间的一个合理的中间值。
（5）如果你的网站是为各为各种拥有相异需求的用户服务的，搞楚哪些用户想要哪种内容，能帮助你决定用什么方式来呈现这些内容。
（6）对于那些已有大量内容的项目而言，很多关于内容的信息都记一个内容清单中。这样团队中的每个人才能确切地知道他们设计用户体验需要做哪些工作了。
六、确定需求优先级
有时一个战略目标将产生多个需求（左图）。另一方面，一个需求也可以实现多个战略目标（右图）。
由于项目范围是建立在战略层的基础上的，因此我们应该去评估这些需求是否能满足我们的战略目标（无论是网站目标还是用户需求）。除了这两种目标，我们还要额外确定第三种范围：实现这些需求的可行性有多大？
需求实现的可行性
（1）如果是因为时间有限，那你可以把这个特性放到下一个版本或项目中。如果是资源有限，则技术或企业的变化有时能减少资源的负担，从而使某个特性能得以实现。
（2）很少有功能是独立存在的，甚至产品的内容也必须要依赖其他特性的支持，并告诉用户怎样最好地利用产品所提供的内容。这不可避免地导致了特性之间的冲突。有些特性要和其他的一起权衡，才能得到一个连贯的、统一的产品。
（3）留意那些看上去有可能需要改变战略的特性建议。任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除出去 。不管怎么样，如果你发现自己正在反复审视战略目标，那么你极有可能是太早地进入了需求定义阶段。
（下一章预告：结构层——交互设计与信息架构）
