本章聚焦于五个层次中的范围层，阐述了为什么需要进行范围层的设计、范围层需要完成什么设计。本篇笔记共4137字，预计需要7分钟完成阅读。

尽管作者将功能与内容型产品拆分开来进行介绍，但范围层的设计，实质都是三步骤：明确需求+说明功能+明确优先级
无论是内容需求还是功能需求，设计中的表现形式可能不同，都需要还原需求的背景，明确需求，找出真实问题，无论拿到的需求级别高或低、来源是一手还是二手。
定义需求后，我们需要进行功能说明。功能型产品通常使用功能规格说明书来具体地描述出需要实现的功能特性，内容型产品则需要给出内容特性的具体说明，包括内容的类型、组合方式、大小等 ，并且最好明确内容更新的长期负责人。
在梳理出功能后，我们还需要结合战略目标与需求的可行性，判断需求优先级。

如果说战略层聚焦于“我们为什么要开发这个产品”，那么范围层主要回答的是“我们要开发的是什么”，也就是产品应该提供给用户什么样的内容和功能。

在 决策者对产品战略方向的思考 与 产品经理对新功能的设计 中间，我们还需要一个范围的设计，从而保证项目如期交付。

对于大多数的互联网产品，完整的产品功能应当是分阶段实现的。另外，即使是瀑布流开发，我们同样需要考虑清楚哪些feature需要、哪些不需要。
缺乏范围层设计的开发过程很容易陷入“范围蠕动”，最终得到一个混合各个阶段功能、永远是beta版本的产品。

范围层是什么、我们为什么要进行范围层的设计

范围层的设计中，我们需要

• 定义并描述清楚 feature
• 确定项目的范围
  • 记录所有需要做的事情
  • 并在这个基础上设计日程安排(schedule)与里程碑(milestones)

定义范围层的过程和结果都是有价值的。定义范围层的过程中，我们可以进一步细化产品、考虑潜在冲突；定义范围层的结果可以为团队提供参考、帮助大家实现项目范围的控制。

范围层的定义，简单来说就是，“明白我们现在该做什么、不该做什么”：

1. 让团队明白，我们在建设什么产品
   1. 将项目的目标同步给整个团队
      1. 最终产品不再是一个①只停留在产品经理头脑中的、②不断变化的模糊概念
      2. 这个产品形象将具体、明确、可传达，可以被团队内的所有人认知，也支持团队内部的所有人参与
   2. 提高团队的协作效率
      1. 范围层可以明确项目中需要完成哪些工作、定义好团队内对一项工作的共同语言
      2. 明确要求后，我们可以更清晰地拆分内容、分配责任，提高协作效率、保障产品质量
2. 让团队明白，我们(现阶段)不需要做什么
   1. 避免产品的范围不断扩张，导致项目和费用预算的过度膨胀
      1. 在“可能性”浮现出来之后，我们需要进行评估；有些功能看起来很棒，但我们应该结合战略考虑，这是不是我们该做的事、是不是我们当下该做的事
   2. 收集那些“不需要马上做”的想法，作为未来的潜在功能
      1. 既保证产品的当下的进度与交付，同时也不会错过一些“很棒但是不符合现阶段”的点子

版本管理

如何进行范围层的设计

之前提到，范围层主要是①定义需求，②描述feature，③确定项目的范围。设计的过程也主要是围绕这三个目标来开展。

从范围层开始，由于功能型与信息型产品的侧重点不同，体验要素设计上会分别进行设计，正如 Chapter 2 的用户体验要素与模型中所介绍，“范围层”也划分为了功能规格和内容需求两部分。

不过，在范围层的定义中，两类产品所用的方法是相似的。

• 本质上，内容开发在范围层的设计工作与功能型软件开发是一样的——功能型软件收集需求并商议功能需求，内容涉及这也需要考量资料的来源、决定哪些信息必须纳入设计范围内
• 内容需求常伴随功能的需求，而功能需求也常常伴有内容的需求。功能与内容相辅相成，而非对立
  • 内容需要通过内容管理系统/CMS进行管理，而设计者需要根据内容的性质来设计和调整CMS系统，例如对CMS系统进行功能的增补、流程的优化
  • 功能型产品也需要对内容进行设计，例如错误提示(个人感觉，即使是功能产品也有大量需要管理的内容，典型如用户信息)

在“定义——描述——优先级排序与范围确定”三个目标中，功能规格和内容需求设计在“描述feature”环节（即后续的功能规格说明部分）的注意点会略有不同，在方法上没有太大差异。

在后续内容中，我们将使用”功能规格说明书“指代说明功能与内容的文档，并使用“特性"feature"”对功能和内容进行统一描述。

定义需求

需求是有层级的。需求既可以是整个产品级别的，例如品牌需求；需求也可以是对某个feature的一句简短描述。需求的详略程度常取决于项目的具体范围。

需求最根本的来源是用户，Chapter 3用户需求部分介绍的用户研究方法是获取用户需求的常用方法。但工作中，我们的需求来源常常是与项目利益相关的同事（业务部门的二手需求、ld需求等）。

无论我们得到的是从用户还是其他干系人获得的“需求”，我们都不能直接按照对方描述的解法来设计功能：
用户口中的“我希望有一个xx功能”，往往是针对使用中的某个困难所设想的解决办法。而这个“解决方法”①不一定可以真正解决问题，②不一定是最佳的解法，③不一定符合我们产品的战略，④不一定符合我们产品近期迭代的目标方向。
因此，正确的做法是，①和提出需求/功能的人进一步探讨，确定ta遇到的真实问题（还原场景和需求），②设计解决方案，③结合产品战略考虑要不要做，④结合近期迭代计划采取什么程度的方案。

另外，产品经理应该保持对陷入固定思维的警惕——当我们将所有时间都投入到维护现有产品中时，我们难免会被局限于产品的现状，忘记了哪些是真正的限制条件、哪些是曾经为了简化产品做出的选择。
可以采用的方法包括：

1. 对需求和曾经做出的选择进行管理，供后续查看与溯源
2. 适时进行头脑风暴会议讨论功能需求，成员可以是其他部门的干系人，或不同类型的用户代表
   1. 来自其他视角的观点可以帮助大家多角度、全方位地汇总产品问题、思考解决办法
   2. 可以从技术、市场等视角提前发现问题，并设计解决方案
3. 使用personas+scenarios的方法，想象角色在场景下完成需求所需要经历的过程，从而检查流程的完整性、发现潜在需求
4. 通过分析竞争对手的特性，倒推他们满足的用户需求或产品目标，并作为我们权衡和调整问题的参考（包括竞品是否推出特别有效的feature、竞对如何权衡两项指标等等）；另外，非竞对的其他类型产品也可能会启发我们的思考

功能规格说明

人们往往对功能规格说明书抱有负面态度——程序员不愿意阅读枯燥且冗长的说明，撰写者也不愿意浪费时间撰写“没人读的文档”。

但是，作为需求传递的文档，功能规格说明书是有价值且必须存在的。

功能规格说明书“没人读”的一个重要原因是，产品在实施过程中往往会发生变化，因此让人感觉“功能规格说明书并不会体现最终产品”，进而感觉“功能规格说明书是无用的”。

解决“撰写的功能规格说明书没有价值”这个问题，正确的解法不是“不撰写”，而是思考如何避免说明书与最终产品的差距，并且想办法让文档的利用率提升

1. 文档的撰写应当与产品的开发过程相结合
   1. 让撰写的过程变得快速简便，适时更新文档，从而保证文档与产品是相匹配的
2. 文档重点不在于详细，而在于清楚和准确
   1. 功能规格说明不需要包括产品的每一个细节，只需要保证功能的清晰不混淆
   2. 当前的文档不需要展望产品未来的理想化状态，只需要记录目前已确定的决议

针对功能规格设计的几个小 tips

这些与其说时给说明书的建议，更多的是针对设计本身的建议

1. be positive：文档应从正向去描述系统需要采取的措施(例如异常或边界状态)，而不应该简单描述系统的禁用范围
   例如，“系统不允许用户购买没有风筝线的风筝”，可以被替换为“当用户想购买没有风筝线的风筝时，系统应引导用户至风筝线界面”
2. be specific：文档应具体地对功能进行详细说明
   例如，“重点标注出最受欢迎的视频”不够明确具体、缺乏对目标和评判标准的定义，应该修正为“在列表的最前端显示上周播放数最高的视频”
3. avoid subjective language：文档应避免出现主观的描述说明——功能需求应明确、无歧义、可验证，不会因为个人评判标准而偏移
   例如，“网站的风格应该是时尚闪耀亮眼的”，这就过于主观了，每个人对时尚和亮眼的评判标准都是不同的，“这个网站应符合邮递员wayne所期望的时尚”就会变得可验证，而“网站的外观应符合企业的品牌指南文档”将完全避免需求本身的主观性。除了引用参考指南，我们还可以通过量化定义来避免需求的主观性

针对内容需求设计的几个小 tips

个人认为上述很多方法对内容需求的定义与功能设计同样有参考价值。例如，功能设计可能也不局限于真的设计出某个function，可能可以通过和站外信息联动解决需求等等

1. “内容”不局限于文本，我们需要考虑所有所需内容的类型
   1. 图像、音频、视频也是内容。需要提前确定好内容的类型、设计呈现的组合方式、确定需要哪些资源
2. 设计内容时不要混淆其格式和目的，关注内容设计背后的真实需求
   比方说，内容设计中常遇到一个需求-“我们应当有FAQ”。设计过程中如果只关注其格式(一系列简短的问答)，我们很可能会遗忘其目的，最终只是做出了AQ，忽略了“常见”这个点；如果聚焦于真实需求，我们就会发现，FAQ的真实价值是“随时提供用户普遍需要的信息”，甚至我们可以不采用问答的格式（例如飞书多维表格使用页内icon+gif完成了教学和问题解答）
3. 在设计内容、明确内容需求时，我们需要给出每个特性的规模的大致预估，因为内容特性的大小将会对设计中的决策产生巨大影响
   典型如，如果使用的图片素材普遍为高清晰度img，那么可能需要考虑性能问题以及交互优化方案了。
4. 内容特性的交付通常不是一次性的
   1. 内容特性的执行可能比策划更重要。假想阶段看起来很不错的内容特性，有可能会因为实际执行中出现的问题而效果不佳——除了初次上线外，我们还需要策划后续的内容更新，从而保证网站长期满足用户需求
   2. 设计时应对每一个内容特性的“更新频率”进行定义。更新频率取决于产品的战略目标，并结合用户期望和有效资源取一个合理的值
   3. 设计时最好指定内容特性和元素的负责人，保证对应的内容需求可以得到建设和维护
5. 当网站的用户存在不同的需求时，网站应当为不同的用户角色准备不同的内容和呈现方式，例如涉及到读者、写手两种角色的小说网站可能需要分化处理内容
6. 内容需求量较为庞大时，建议整理内容清单(content inventory)

确定需求优先级

在定义需求和功能规格说明两个步骤中，我们完成了对潜在的需求以及特性思路的收集。在这之后，我们需要确定需求的优先级，并为“目前项目中应包含的功能”划定一个明确的范围。

需求的优先级主要取决于两大方面——是否满足战略目标&需求的可行性。
战略目标也就是Chapter 3：战略层-产品目标和用户需求。我们需要评估需求是否可以满足网站目标或用户需求。战略目标和需求可能时多对多的关系。

在审视需求、确定优先级的过程，一定要关注战略目标：

• 不符合当前项目的战略目标的特性均需要被排除
  • 在这个基础上，如果与战略不符的“好点子”反复出现、甚至引发我们对战略的反复审视，那么，我们可能需要回到战略层重新确定
• 战略目标的优先级可以成为需求优先级的首要参考因素

可行性的评估包括①在当前的科技背景下，需求是否可实现，②当前阶段的资源是否可以支持。由于时间等资源而无法实现的特性可以被放在后续的版本更新中。

另外，feature间往往存在依赖关系，不能孤立考虑单个需求。