用户体验——以用户为中心的Web设计_Chapter4. 范围层：功能规格和内容需求
1.范围层的定义
定义项目范围就包括了两方面：一个具有价值的过程导致一个具有价值的产品。
过程（process）的价值在于，当整个事情还处在假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点。
产品（product）的价值在于，它给了整个团队一个参考点，关于在这个项目中要完成的全部工作，它也提供了一门共同的语言，用于讨论这方面的事情。
用文档来说明项目要求，这件事很麻烦，但是你必须要做。这是由以下两个主要原因：
原因1：这样你才知道正在建设什么
如果详细记录下你正在建设的内容，每一个人就会知道这个项目的目标是什么，什么时候达到这个目标。最终产品不再是一个停留在产品经理头脑里的不定型的图像。
拥有一系列明确的要求，能让你把责任分配得更清晰，这可以大大提高协作效率。在了解一个详细策划的完整范围之后，你就可以看到各个相对独立、也不显著的要求之间的内在联系。
原因2：这样你才知道不需要建设什么
当有一个想法出现的时候，用一个文档来记录他们，可以为你提供一个评估这个想法的架构。把一些杰出的想法（可能对于项目当前来说还是不能实现的想法）收集起来，找到一种适宜的方式，让它们符合你的长期规划，这才是真正的价值所在。
2.功能和内容
在这里，范围层被软件界面的网页和超文本的网页分成两个部分。在软件方面，我们考虑的是功能规格——哪些应该被当成软件产品的“功能组合”。在超文本方面，我们考虑的是内容，这属于编辑和营销推广的传统领域。
在软件开发中，范围层确定的是功能需求或功能规格（functional specification）文档。内容的开发者常常不会像软件过程的需求一样正式，但基本原则是一样的。内容设计者要坐下来仔细考量各种资料的来源，不管是一个数据库还是一抽屉的剪报，然后才能决定哪些信息必须纳入设计范围之内。
现在内容常常是通过内容管理系统（content management system，CMS）来进行管理的。这些系统大小不一。你也许决定购买一套专用的管理系统，或从头开始建设一个管理系统。不管哪一种方式，在大部分情况下，你都必须对这个系统进行一些简答的修改以适合你的企业和内容的需要。
一个内容管理系统可以实现自动化流程，能出示和交付内容给用户。
3.收集需求
一些需求适用于整个网站。品牌需求是最常见的一种；某些技术需求，比如支持浏览器和操作系统，是另一种。
另一些需求只适用于特殊的特性。大多数时候，人们说到某种需求的时候，他们想的是产品必须拥有的，某种特性的一句简短的描述。
最用之不竭的需求源泉总是来自用户本身。不管你是从企业内部的管理者，还是直接从用户处收集这些需求，这个过程中得到的需求将被分成三个主要类别。首先，最显而易见的是人们讲述的、他们想要的东西。这中间有一部分是非常清晰的好想法，会寻找各种途径进入最终产品。
当人们在某个过程或某个产品中遭遇到一些困难时，想象有某种解决办法可以这一困难。通过与用户探讨这些解决办法，你有时候可以得出真正解决问题的、完全不同的需求。它们代表了一条通向下一个版本的路径：用户实际想要的东西。
在这个阶段能得到的第三种类型的需求是人们不知道他们是否需要的特性。让一个工程师、一个客服人员、一个营销人员做到一间会议室中谈论同一个网站，这会对大家都有启发意义。听取各方从自己熟悉的角度出发来考虑，可以鼓励人们从不同角度来思考开发中的网站遇到的问题以及解决办法。
4.功能规格
程序员们痛恨功能规格，因为它们非常枯燥，并且会占用大量的编码时间去阅读它们。结果，那些“没有人读的功能规格”反过来又强化了“撰写它们是一件浪费时间的工作”的印象。
无论这个项目有多么庞大和复杂，有几条规则适用于撰写任何类型的需求。
乐观（be positive）。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。比如，下面这句描述就不太好：
这个系统不允许用户购买没有风筝线的风筝。
替换成
如果用户想买一个没有先的风筝的话，这个系统应该引导用户到风筝线的界面。
具体（be specific）。尽可能详细的描述清楚情况，这是我们能决定一个需求是否被实现的最佳途径。
避免主观的语气（avoid subjective language）。这是另外一种需求“保持明确”和“避免歧义”的途径——因而也避免了误解的可能性。
5.内容需求
很多时候我们说到的内容指的是文本。但是我们还应该记住图像、音频和视频也算是内容的类型。这些不同类型的内容可以一起协作去满足某一个需求。
不要混淆某段内容的格式和它的目的。内容特性每一个预期的规模，都将对你必须做的用户体验决策产生极大的影响。内容需求应该提供每一个特性规模的大致预估：文本的字数、图像的像素大小、下载的文件字节、类似PDF的独立内容元素或类似音频或视频一样的特性。事先知道我们必须考虑的内容元素的大小，能让我们在这个设计过程中做出最明智的决定。
尽可能早地确定某个人来负责每一个内容元素是非常重要的。一旦它被认为对我们的战略目标是有效的，任意一种内容特征听起来不可避免地会被当成一个好主意——只要是别人来负责建设和维护它。如果我们在没有确定谁将负责每一个内容特性需求的情况下，过多地投入到开发流程中去，那么我们最后得到的很可能就是一个千疮百孔的网站，因为那些在假象阶段人人喜欢的特性，将在实际执行的时候变的非常沉重。
6.确定需求优先级
在战略目标和需求之间，你几乎看不到一对一的简单关联。有时一个需求可以满足多个战略目标。同样，一个战略目标也常常关系到多个不用的需求。
因为这些范围建立在战略层的基础上的，因此我们就需要去评估这些需求是否能满足我们的战略目标。我们还要确定这些需求的可行性有多大？
如果你的战略计划或可视文档在战略目标的范围内确定了一个清晰的优先级别顺序没那么这些优先级别应该是决定人们所建议的相关特性的首要因素。有时候，两个不同战略目标之间的重要程度也会出现不适很清楚的情况，这时候，特性最后是否能纳入项目范围之中，往往取决于企业的政治局面。
