第四章 范围层-功能规格和内容需求
当把用户需求和产品目标转变成产品应该提供给用户什么样的内容和功能时，战略就变成了范围
一、范围层定义
- 定义项目范围包括两件事：
- 这个过程是有价值的
——过程的价值在于：
当整个事情还处于假设阶段的时候，它能迫使你去考虑潜在的冲突和产品中一些粗略的点。我们能确定现在能解决哪些事情而哪些必须要再迟一点才能解决。 - 这个过程能产生有价值的产品
——产品的价值在于：
被定义的这个产品给了整个团队一个参考点，明确了这个项目中要完成的全部工作，他也提供了一门用于讨论这件事情的共同语言。定义好你的要求能保证在设计过程中不会出现模棱两可的情况。
- 用文档定义需求，原因：
- 你才能知道你在建设什么（目标）
- 你才能知道你不需要建设什么（范围蠕变）
二、功能和内容
- 范围层分为功能型产品和信息型产品两部分：
——功能型产品，考虑功能规格，哪些应当当作软件产品的功能和相应的组合
——信息型产品，考虑内容，这属于编辑和营销推广的传统领域 - 软件开发中，范围层确定的是全部的功能需求或功能规格。
- 内容需求常伴随功能的需求。现在，真正的内容常常是通过一个内容管理系统（CMS）来管理的。一个内容管理系统可以实现自动化流程，能展示和交付内容给用户。
三、定义需求
- 需求分为适用于整个产品的需求和只适用于特殊的特性。需求的详略程度常常取决于该项目的具体范围，最用之不竭的需求是来源是用户本身，直接询问他们是了解用户需求的最佳途径——具体见第三章用户研究技术。
- 需求分为三种：
- 人们讲述的，他们想要的东西，其中一部分是非常清晰的好想***通过各种途径表心啊在最终产品上。
- 有时候人们讲述的需求并不是他们真正需求的，经过与用户探讨这些建议，得出的真正解决问题的需求。
- 人们不知道他们是否需要的特性，经常会在头脑风暴种出现。
- 汇集各个部门的成员或者不同类型的用户进行头脑风暴，是一种打开设计者思路，让他们考虑以前从未想到的可能性的、非常有效的工具。
- 产品的直接竞争对手也会提供丰富的潜在需求。
四、功能规格说明
功能规格说明不需要包含产品的每一个细节，只需要包含在设计或者开发过程中出现有可能混淆的功能定义。同时功能规格说明也不需要展望产品未来的理想化状态，只需要记录在创建这个产品时依据确定下来的决议：
- 乐观（描述这个系统将要去做什么事防止不好的事情发生）
- 具体（尽可能详细的解释清楚状况）
- 避免主观的语气（使需求保持明确、避免歧义以避免误解）
五、内容需求
- 不要混淆某段内容的格式和它的目的（一个FAQ给予用户的真正价值，在于它可以随时提供用户普遍需要的信息，。其他的内容需求也可以满足同样的目的；但是当关注点是格式时，目的本身就可能被遗忘）。
- 内容特性想要达到的规模，将对你所做出的用户体验决策产生极大的影响。内容需求应该提供每一个特性规模的大致评估。
- 尽可能早地确定某个人来负责每一个内容元素。
- 定义每一个内容的更新频率，更新频率来自于产品的战略目标。
- 对于已有大量内容的项目使用记录清单记录内容信息。
六、确定需求优先级
- 需求是否满足战略目标（包括网站目标和用户需求）
- 实现需求的可行性有多大？
- 优先级是决定是否采纳人们所建议的相关特性的首要因素。
- 当出现两个目标之间重要程度不好界定的情况时，要考虑企业的政治局面。
- 解决与管理层之间争论的最好办法是要求“制定战略”。关注战略目标，而不是实现战略的手段。
京公网安备 11010502036488号