2018-11-16
今天为大家更新《用户体验要素》的第四章——范围层，功能规格和内容需求——定义需求
本小结关键词：定义需求
主要观点：无论什么样的需求，你需要定义的需求都可以分为这三个主要类型。
在范围层，我们从讨论战略层面的抽象问题——“ 我们为什么要开发这个产品?”——转而面对一个新的问题：“我们要开发的是什么?”，接下来我们就好好聊聊我们要开发的功能和内容是什么。
功能和内容
如图，在这里，范围层被“功能型产品”和“信息型产品”分成两个部分。在功能型产品方面，我们考虑的是功能需求规格( functional specifications)——哪些应该被当成软件产品的“功能”以及相应的组合。在信息型产品方面，我们考虑的是内容，这属于编辑和营销推广的传统领域。
内容和功能看去很像是两个完全不同的事物，但是当它们在定义范围层的时候，它们所用的方式是非常相似的。在本章中，我将使用一个词“特性( feature)” 来同时表示软件的功能和所提供的内容。
在软件开发中，范围层确定的是全部的功能需求或功能规格( functional specifications)。有些企业用这些术语来表示两种不同的文档：在项目初期，这个词表示需求，描述系统应该做什么；在项目未期，这个词表示功能规格说明，描述系统真正完成了什么。在这种定义中，“功能规格”在“功能需求”确定之后才开始撰写，同时将加入具体的实施细节。
但是大部分的时候，这两个术语是可以互换的——事美上，有些人使用“功能需求规格”来表示他们的文档覆盖了包括以，上两者的内容。我将使用“功能规格说明书”来描述文档本身，而用“需求”来描述文档的内容。
本章所使用的词汇大部分和软件开发所使用的词汇一样。但是在这里的概念同样适用于内容开发。内容开发不会像软件过程的需求收集一样，总是那么正式，但其基本原则是一样的。内容设计者要坐下来仔细考最各种资料的来源，不管是一个数据库还是满满一抽屉的剪报，然后才能决定哪些信息必须纳入设计范围之内。这种定义内容需求(content requirements)的过程，实际上与技术专家和董事会集体商议功能需求，并回顾已有的文档记录没有本质上的区别。两者的意图和方法是一样的。
内容需求常常伴随着功能的需求。现在，真正的内容常常是通过一个内容管理系统(CMS)来进行管理的。这些系统大小不一，大的系统能根据众多不同的数据来源动态生成页面，庞大而复杂；小的可以是一个很轻巧的工具，能以最高效的方式来优化并管理各种类型的内容专题。你有可能会去购买一套专用的管理系统，或从众多开放源代码的备选方案中挑一个，甚至还想从零开始，自己做一个管理系统。不论用哪一种方式，在大部分情况下，你都必须对这个系统进行一些简单的修补以适合你的企业和内容的需要。
内容管理系统必备的功能取决你将要管理的内容的性质。你是否需要维护多语言的文字内容?内容的基础数据是否自带格式?CMS就需要具有处理这些类型的内容元素的能力。你的每一篇新闻稿是否必须要通过六个执行副总裁和一个律师的审核?CMS就需要在流程中支持这些类型的需求。你的内容元素是否要根据每一个用户的喜好或访问终端来动态地组合?那么CMS就必须要能完成这一类高级别的复杂输出。
类似地，功能需求或任何一种技术类产品也常常伴随着内容的需求。在“个人喜好设置”的页面中需要有使用说明吗?需要有错误提示吗?必须要有个专门的人来写这些内容。每一次当我看到网页上出现类似“无效输人”的错误提示时，我就知道这种文字是出自开发工程师之手，并成为了最终产品，因为没有人把这些错误提示纳入内容需求中。而事实上，如果开发者能花一点点时间让某些人看一看应用程序中的内容的话，无数的技术项目会因此得到极大的改善。
定义需求
一些需求适用于整个产品。品牌需求是最常见的一种：某些技术需求，比如支持浏览器和操作系统，是另一种。
另一些需求只适用于特殊的特性。大部分时候，当人们说到某种需求的时候，他们想的是产品必须拥有的、某种特性的一句简短描述。
需求的详略程度常常取决于该项目的具体范围。如果该项目的目标是完成一个复杂的子系统，那么就需要有一个非常详细明确的需求，即使这个项目的范围相对于整个网站来讲非常小。相反地，一个大型项目，它的内容也许只是相似或相同性质的东西(比如提供大量功能相似的产品说明书的PDF文件)，那么内容需求只需要一般化就可以了。
最用之不竭的需求源泉总是来自用户本身。但更多的时候，你的需求将来自与项目利益相关的同事一那些在企业中总想影响你的产品的人。
不管是哪种情况，去了解“人们在想什么”的最佳途径就是直接询问他们。在第3章列出的用户研究技术都可以用来帮助你更好地了解用户，了解他们希望在你的产品上看到的特性的种类。
不管你是从企业内部的管理者，还是直接从用户处获得的帮助，来定义的这些需求，这个过程中得到的需求将分成三个主要类别。首先，最显而易见的是人们讲述的、他们想要的东西。这中间有一部分是非常清晰的好想法，会通过各种途径体现在最终产品上。
有时候人们口中说出来的、所期望的特性其实并不是他们想要的，当人们在某个过程或某个产品中遭遇到一些困难时，想象有某种解决办法可以缓解这一困难，这对任何人来讲都是很正常的反应。有时这个解决办法是行不通的，或者仅仅是治标不治本的办法。通过与用户探讨这些建议，你有时候可以得出能真正解决问题的、完全不同的需求。
在这个阶段能得到的第三种类型的需求是人们不知道他们是否需要的特性。当你让人们讨论新的需求和战略目标时，他们有时会突然想起某个伟大的构思，而根本忘记了那个正在维护中的产品。这些通常会在头脑风暴讨论的时候出现，那正是与会者有机会参与和探讨项目的可能性的时候。
具有讽刺意味的是，那些很少去想象产品新方向的人，恰恰是参与创建和设计产品最深入的人。当你把所有的时间都投，入到维持现有产品时，你经常会忘掉哪些是真正的限制条件，而哪些是为了简化产品而曾经做过的选择。出于这个原因，汇集企业各个部门的成员或不同类型的用户代表来进行头脑风暴会议，是一种打开设计者思路、让他们考虑以前从未想到的可能性的、非常有效的工具。
让一个工程师、一个客服人员、一个营销人员坐到一会议室中谈论同一个产品，这会对大家都有启发意义。听取从自己不熟悉的角度出发来考虑的、对于产品的观点，并给予反馈，可以鼓励人们多角度全方位地思考开发中的产品遇到的问题以及解决办法。
不管你设计的产品在什么样的设备上使用我们的需求序列必须要考虑到硬件需求。这个设备有摄像头吗?有GPS吗?有陀螺感应指针(一种用来测量或保持设备坐标信息的装置)吗?这些因素都将会确立或限制产品功能的可能性。
通过这种方式讨论出来的功能需求通常是得到如何去除某些障碍的方法。举个例子来讲，假设你有一个用户已经决定要购买了——他们只是没有决定是不是买你的产品，你设计的产品要怎样才能让这个过程(首先是选择你的产品，然后买下它)对他们来讲更容易呢?
在第3章，我们看到有一种叫作人物角色(personas)的技术，通过创建虚拟人物来帮助我们更好地理解用户需求。在决定功能需求的时候，我们可以再次使用这些人物角色，把我们的虚拟人物放到一个简短的故事之中，我们称之为“场景(scenarios)”。一个场景是一个简短的故事，简单描述了一个人物角色会如何完成这些用户需求。通过“想象我们的用户将会经历什么样的过程”，我们就可以找到能帮助他顺利完成这个过程的潜在需求。
我们也期望从竞争对手处得到一些启示。任何一个在做同一件事的企业基本上在试图满足同样的用户需求，同时也在试图完成相似的产品目标。竞争对手是否找到一种特别有效的特性，能完成其中的某个战略目标?他们是如何权衡和调整我们所面对的那些问题的?
即使不是产品的直接竞争对手也能提供丰富询潜在看求例如一些游戏平台允许用户创建自己人的社交群组，那么在我们的数字录像软件，上采用相似的特性或建立类似的机制，也许就能给我们一 定的竞争优势，用来超越直接竞争对手。
接下来，会为大家更新功能规格说明文档。敬请期待。
