当你把用户需求和产品目标转变成产品应该提供给用户什么样的内容和功能时，战略就变成了范围。这章我们要面对的问题是：“我们要开发的是什么？”

范围层的定义

定义范围层是一件过程和结果都有价值的事情：
在过程中：能迫使我们去考虑潜在的冲突和产品中粗略的点，确定了现在能解决什么，以后能解决什么。
在结果中：产品被定义了，明确了这个项目中要完成的全部工作。也提供了用于讨论这件事情的共同的语言。

在定义范围层的工作中，我们需要工作流程（working flow）、日程安排（schedule）、里程碑（milestones），因此我们需要用文档来定义产品需求。

这样的好处主要有两点:

1. 这样我们才知道正在建设什么？
详细记录下正在建设的内容，使得最终产品不再是只停留在产品经理或少数人脑中不定型的图像，而是每一个参与者都能明确知道这个项目的目标是什么，什么时候将达到这个目标。
拥有一系列明确的要求，能让我们把责任分配得更清晰，这可以大大提高协作的效率，方便我们看到各个相对独立要求之间的内在联系。

2. 这样我们才知道不需要建设什么？
当我们在定义产品的过程中，会有各种奇思妙想，但是它们对于我们的战略目标未必是必需的，或者不是需要立马去做的，或者换一个方式去做的。
如果有一个文档来记录，可以为我们提供一个评估这些想法的架构，帮助我们了解这些想法能否满足或实现战略层决定的事情。

因此，我们应该有意识地运用文档管理我们的工作，避免范围蠕变（scope creep），让不必要的需求滚雪球增加导致项目失控。

当我们当前的资源难以满足完成某个需求，我们可以先让这个版本成为启动的基础，在下一个版本进行完善，形成一个不断循环的开发过程。

功能规格和内容需求

在产品中，我们考虑的“功能规范（functional specification）”，是哪些应该被当成软件产品的“功能”以及相应的组合。我们考虑的“内容需求（content requirement）”，主要属于编辑和营销推广的传统领域。

· 功能规格（功能需求）

在软件开发中，范围层确定的是全部的功能需求或功能规格。在大部分时候，这两个术语是可以互换的，本书作者用“特性（feature）”来同时表示软件的功能和所提供的内容，用“功能规格说明书”来描述包括以上两者内容的文档本身，用“需求”来描述文档的内容。

也有一些企业将二者分开，在项目初期表示需求，描述系统应该做什么；在项目末期，这个词表示功能规格说明，描述系统真正完成了什么。而这种定义中，“功能规格”在“功能需求”确定之后才开始撰写，同时将加入具体的实施细节。

功能需求或任何一种技术类产品常常伴随着内容的需求。比如产品中的提示语句，使用说明语句等，也需要专门的人来撰写。能大大提高产品的形象和用户体验好感度。

· 内容需求

内容需求也常常伴随着功能的需求，真正的内容常常是通过一个内容管理系统（content management system，CMS）来进行管理。一个内容管理系统可以实现自动化流程，能展示和交付内容给用户，其功能取决于你将要管理的内容的性质。我们工作中接触最多的就是后台运营管理系统，在电商产品中基本上由运营部对商品商家、专题、类别等内容的上新、更替等。

定义需求

需求有适用于整个产品的，也有只适用于特殊的特性。大部分的时候，当人们说到某种需求时，他们想的是产品必须拥有的、某种特性的一句简短描述。

需求的详略程度常常取决于该项目的具体范围。即使是一个很小的项目，但是系统复杂，也需要一个非常详细明确的需求。相反的，即使是一个大型项目，需求的内容也许只是相似或相同性质的东西。

需求的来源可能是人们讲述的、他们想要的东西，可能是在使用过程中用户遇到某些困难提出的解决办法（当然这个办法未必是有效的、长久的），也可能是在讨论其他问题时突然想到的，还有可能是从竞争对手那里获得的灵感。

在工作中，我们经常会遇到一个困境。就是参与创建和设计产品最深的人，对产品新方向的想象力反而少了。因为随着工作进展和迭代，我们会忘记目前所做出的决定哪些是当时的技术限制，哪些是为了按时上线做出的妥协，哪些是为了简化产品提升体验做出的决定。久而久之，会被之前种种限制把自己的思维越圈越小，形成瓶颈。

因此，为了预防进入这个思维怪圈，从自身来说，我们应该经常告诉自己跳出目前的状态去思考，同时养成进行工作记录总结的习惯。本人一个月总结整理一次，能思考工作中自己的不足，也能回顾自己的成长。认识一位UI好友，她每天都会记录自己的工作内容以及跟产品撕x后的决定等等，因此每次被甩锅的时候都有理有据为自己代言，为了不再被坑不背锅而坚持着，最后变成了习惯。好像扯远了，总之我还是很佩服她的，这对自己、对团队、对产品都是很有益处的。

从公司角度，我们可以汇集公司各个部门的成员或用户代表进行头脑风暴，从不同的专业角度提供不一样的思路，这些思路都将会确立或限制产品功能的可能性。通过这种方式讨论出来的功能需求通常是得到如何去除某些障碍的方法。

在战略层中，我们使用人物角色（personas）来了解用户的需求，在范围层中，我们通过将人物角色放入场景（scenarios）中来决定功能需求。

场景（scenarios）：将我们创建的虚拟人物放到一个简短的故事之中。一个场景是一个简短的故事，简单描述了一个人物角色会如何完成这些用户需求。通过“想象我们的用户将会经历什么样的过程”，我们就可以找到能帮助他顺利完成这个过程的潜在需求。

· 功能规格（功能需求）
书中用了大段篇幅强调了，我们要写“真正起作用的功能规格说明书”，“真正起作用的功能规格说明书”是非常重要的。“真正起作用的功能规格说明书”是快速简便的、是清楚准确的、可验证的，它只需要“包含在设计或开发过程中出现有可能混淆的功能定义”，而不是产品的每一个细节；只需要“记录在创建这个产品时已经确定下来的决议”，而不需要对产品未来的展望。

<br />
接下来，就是实用手册了，几条适用于撰写任何类型的功能规格说明的规则：

乐观（be positive）

描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。

错误：这个系统不允许用户购买没有风筝线的风筝。
正确：如果用户想买一个没有线的风筝，这个系统应该引导用户到风筝线的页面。

具体（be specific）

尽可能详细地解释清楚情况，这是我们能决定一个功能是否被实现的最佳途径。

错误：最受欢迎 的视频要 重点标注。
正确：上一周被播放次数最多的视频要显示在列表的最前端。

避免主观的语气（avoid subjective language）

另一种是需要“保持明确”和“避免歧义”的途径因而也避免了误解的可能性。

错误：这个网站的风格应该是时尚、闪耀的。
凑合：这个网站应该符合快递员小黄所期望的时尚。
最好：网站的外观应该符合企业的品牌指南文档。

我们还可以通过量化定义一些功能，通过这样的手段来避免主观性。正如成功的标准能使战略目标得以量化一样，用量化的标准来定义功能也能有助于我们了解是否满足了需求。

· 内容需求

很多时候我们说到的内容指的是文本，随着产品的丰富，图像、音频、视频的位置慢慢凸显出来。这些不同的类型可以结合在一起，相互协作去满足某一个需求。

不要混淆某段内容的格式和它的目的。不同的内容需求可以满足同样的目的，当关注点在格式上时，目的本身就可能会被遗忘。

内容特性想要达到的规模，将对你所做出的用户体验决策产生极大的影响。内容需求应该提供每一个特性规模的大致预估，如文本的字数、图片的像素大小、下载的文件字节、PDF或音频文件等相对独立元素的大小等。我们只收集最紧要的关键资料，用于设计适当的工具来管理内容。

接下来就是尽可能地确定某个人或某个团队来负责每一个内容元素。这是很重要的，也是容易被忽视的，在之前的直播项目我们就吃了这样的苦头，在“收集主播和优质直播的资源”这部分工作与运营部的传达不到位，导致产品功能架构上线了，没有足够的内容填充。在产品发展过程中，我们可以慢慢培养一批主播，但是也需要在前期找到一些合作的资源快速为上线准备好内容。

此外，内容需求还应该定义每一个内容特性的“更新频率”。这个更新频率与产品的战略目标息息相关，并且我们应该在用户期望值和有效资源之间取一个合理的中间值。

以上这些内容，我们都会记录在内容清单（content inventory）中，它通常采用一种简单的格式，比如excel，整理它是枯燥且重要的，这样团队内的参与者才能确切知道他们设计用户体验需要做哪些工作。

确定需求优先级

如果你曾经遭遇过“所有大大小小功能的优先级都标P1”的“产品经理”，你就知道确定优先级的必要和重要性了。

对于确定优先级，我们首先应该评估这些需求是否能满足我们的战略目标，其次确定这些需求的可行性有多大（包括技术上的、时间上的、资源上的、资金上的各种限制）。

很少有功能是独立存在的，甚至产品的内容也必须要依赖其他特性的支持，并告诉用户怎样最好地利用产品所提供的内容。有些特性要和其他特性一起权衡，才能得到一个连贯的、统一的产品。这完全取决于我们的战略目标。

在确定需求的过程中，任何不符合当前项目的战略目标的特性建议，都要通过范围定义将其排除出去。还有一些不在项目范围，并且可行的方案，就需要我们重点审视某些战略目标。总之，如果我们在进入范围层后还在反复审视战略目标，说明我们极有可能是太早进入需求定义阶段。如果我们制定了一个优先级别顺序清晰的战略计划，我们就有了指导纲领，这份文档是决定我们是否采纳相关特性的首要因素。

文中最后还附上了如何与管理层沟通的技巧，在开需求会的时候我们的讨论的话题容易从战略目标转移到实现手段。这时候，我们需要carry话题走向，先向管理者保证所关注的特性可以用另一种方式来满足，将关注点再次转移到战略目标相关的特性上。“对决策者的需求表示认同，是解决特性冲突的关键。”这句话我给五分好评，实践出真知，大家可以自行体会。

<br /><br />

小结

本章的主要内容是功能规格（功能需求）与内容需求，作者用“特性（feature）”一词来涵盖，而产品部、UED部的工作重点在功能规格上，需要在这个阶段输出准确可验证的文档。该文档是战略层思想的落地，是项目开始启动的纲领。而这个文档输出物是由产品经理或项目负责人来负责，但是交互设计师在这个时候就应该参与其中了，一方面是更深刻地领会战略意图，另一方面可以和产品经理一起讨论确定出本期需求及功能，方便下一个阶段的拓展，较早地进入开发周期。

《用户体验要素》阅读笔记

一、初识用户体验
二、网站的用户体验
三、用户体验五要素
四、战略层：产品目标和用户需求
五、范围层：功能规格和内容需求
六、结构层：交互设计与信息架构
七、框架层：界面设计、导航设计和信息设计
九、表现层：感知设计
十、用户体验的应用