1700423325
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422473]
1700423326
原因#1：这样你才知道你正在建设什么
1700423327
1700423328
这似乎很明显，但是它对于正在开发某个产品应用程序的团队却一个惊喜。如果详细地记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候将达到这个目标。最终产品不再是一个只停留在产品经理头脑里的不定形的图像，它变成了一个在企业内部的每一个级别的每一个人都触手可及的东西，从高层管理人员到入门级的工程师，人人都能参与进来。
1700423329
1700423330
如果没有文档的要求，你的项目很可能会变成一个叫作“电话”的校园游戏—在团队中的每一个人都有各自关于产品的想法，然后通过口口相传的方式传递出去，每个人的描述都略有不同。甚至更糟的可能是，每个人都认为别人肩负着设计和开发产品关键环节的责任，但事实上这个人并不存在。
1700423331
1700423332
拥有一系列明确的要求，能让你把责任分配得更清晰，这可以大大提高协作的效率。在了解了一个详细策划的完整范围之后，你就可以看到各个相对独立、也不显著的要求之间的内在联系。举个例子来讲，在早期的讨论中，支持文档和产品规格表可能看起来像是独立的功能内容，但是把它们作为要求确定下来，会让这种有所交叠的事情更加明显，并且同一个小组的人可以把它们都负担起来。
1700423333
1700423334
1700423335
1700423336
1700423337
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422474]
1700423338
用户体验要素：以用户为中心的产品设计（原书第2版） 原因#2：这样你才知道你不需要建设什么
1700423339
1700423340
许多功能听上去都相当地诱人，但是它们对于项目的战略目标并不是必需的。此外，所有在项目开始如火如荼地进行时，关于功能的、各种各样的可能性都会浮现出来。当这些想法出现的时候，用一个文档来记录它们，可以为你提供一个评估这些想法的架构，帮助你了解他们是如何（或是否）满足你当初所承诺要做的那些事。
1700423341
1700423342
了解你“不需要做什么”也就意味着知道哪些是你“不需要马上去做”的东西。把这些杰出的想法收集起来，找到一种适宜的方式，让它们符合你的长期规划，这才是真正的价值所在。确定具体、系统的发展要求，并将任何不符合这些要求的想法作为潜在的未来功能囤积起来，只有通过这种更慎重的途径，你才能真正管理整个设计过程。
1700423343
1700423344
1700423345
1700423346
1700423347
当前难以满足的需求，可以成为启动下一个版本的基础，这样就能形成一个不断循环的开发过程。
1700423348
1700423349
如果你不能有意识地管理你的要求，你将陷入可怕的“范围蠕变（scope creep）”中，这个词总会让我想起一个景象：一个雪球向前滚了一英寸（接着又是一英寸）每一次滚动都会捎带上更多的雪，直到它冲到山脚下。在这个过程中，雪球变得越来越大，你越来越难以阻止它。与这个景象相同的，每一个额外的要求看上并没有增加太多的工作量，但是当它们汇集到一起的时候，你的整个项目就会失去控制地膨胀，结束时间遥遥无期，而费用预算正不可避免地朝着最终的分崩离析飞奔而去。
1700423350
1700423351
1700423352
1700423353
1700423354
用户体验要素：以用户为中心的产品设计（原书第2版） [:1700422475]
1700423355
用户体验要素：以用户为中心的产品设计（原书第2版） 功能和内容
1700423356
1700423357
在范围层，我们从讨论战略层面的抽象问题—“我们为什么要开发这个产品？”—转而面对一个新的问题：“我们要开发的是什么？”
1700423358
1700423359
1700423360
1700423361
1700423362
在这里，范围层被“功能型产品”和“信息型产品”分成两个部分。在功能型产品方面，我们考虑的是功能需求规格（functional specifications）—哪些应该被当成软件产品的“功能”以及相应的组合。在信息型产品方面，我们考虑的是内容，这属于编辑和营销推广的传统领域。
1700423363
1700423364
内容和功能看去很像是两个完全不同的事物，但是当它们在定义范围层的时候，它们所用的方式是非常相似的。在本章中，我将使用一个词“特性（feature）”来同时表示软件的功能和所提供的内容。
1700423365
1700423366
在软件开发中，范围层确定的是全部的功能需求或功能规格（functional specifications）。有些企业用这些术语来表示两种不同的文档：在项目初期，这个词表示需求，描述系统应该做什么；在项目末期，这个词表示功能规格说明，描述系统真正完成了什么。在这种定义中，“功能规格”在“功能需求”确定之后才开始撰写，同时将加入具体的实施细节。
1700423367
1700423368
但是大部分的时候，这两个术语是可以互换的—事实上，有些人使用“功能需求规格”来表示他们的文档覆盖了包括以上两者的内容。我将使用“功能规格说明书”来描述文档本身，而用“需求”来描述文档的内容。
1700423369
1700423370
本章所使用的词汇大部分和软件开发所使用的词汇一样。但是在这里的概念同样适用于内容开发。内容开发不会像软件过程的需求收集一样，总是那么正式，但其基本原则是一样的。内容设计者要坐下来仔细考量各种资料的来源，不管是一个数据库还是满满一抽屉的剪报，然后才能决定哪些信息必须纳入设计范围之内。这种定义内容需求（content requirements）的过程，实际上与技术专家和董事会集体商议功能需求，并回顾已有的文档记录没有本质上的区别。两者的意图和方法是一样的。
1700423371
1700423372
内容需求常常伴随着功能的需求。现在，真正的内容常常是通过一个内容管理系统（Content Management System, CMS）来进行管理的。这些系统大小不一，大的系统能根据众多不同的数据来源动态生成页面，庞大而复杂；小的可以是一个很轻巧的工具，能以最高效的方式来优化并管理各种类型的内容专题。你有可能会去购买一套专用的管理系统，或从众多开放源代码的备选方案中挑一个，甚至还想从零开始，自己做一个管理系统。不论用哪一种方式，在大部分情况下，你都必须对这个系统进行一些简单的修补以适合你的企业和内容的需要。
1700423373
1700423374
