本系列文章全部是笔者关于《用户体验要素——以用户为中心的产品设计》一书所做出的概括总结，感兴趣的读者可以自己去查看书本
上篇地址：用户体验要素（二）：战略层
1 我们为什么需要做范围定义？
很多时候我们有一个固定的工作流程，但是没有日程安排，没有里程碑，项目怎么也看不到尽头。因为根本没有人知道这个项目的范围，所以也没有人知道它会在什么时候结束。
产品或者网站的范围定义是需要基于产品需求的，这个需求需要落实在文档而不是某个人的脑海里。
- 这样你和团队成员才知道你在建设什么
- 这样你和团队成员才知道你们不需要建设什么
同时，范围的确定能够帮助我们有效的管理整个项目的进程，防止陷入某个可拍的范围蠕动中。
当前难以满足的需求，可以成为启动下一个版本的基础，这样就能形成一个不断循环的开发过程
2 范围层到底是什么？
在战略层，我们讨论的是“我们为什么要开发这个产品？”
而在范围层，我们则需要探讨“我们开发的是什么？”
范围层示意
如上图所示，范围层被“功能型产品”和“信息型产品”分成两个部分。在功能型产品方面，我们考虑的是功能规格——哪些应当被当成软件产品的功能以及相应的组合。在信息型产品方面，我们考虑的是内容，属于编辑和营销推广的传统领域。
- 在软件开发中，范围层确定的是全部的功能需求或功能规格（function specifications）。在项目初期，我们定义功能需求，即这个软件或者系统应该做什么。而在项目末期，我们需要描述这个系统真正完成了什么。
- 内容需求侧通常伴随着功能需求，一般我们会用CMS系统来做内容管理。
CMS示意图
3 如何定义需求
-
从内部管理者和用户处获得。这个过程中我们会得到三种类型的需求：
a. 人们讲述的，他们想要的东西。
b. 人们在使用产品过程中遭受到某种困难，通过他们说出来的实际上是他们本能想到的某些解决方法而不是真正的问题或者需求。因此还需要的分析用户说出的问题本质，发掘本质需求
c. 人们不知道他们是否需要的特性。 -
通过用户角色建模，帮助我们更好的理解用户需求
-
从竞争对手处获得一些启示，就是我们常说的竞品分析。
4 确定需求的优先级
主要两点：
- 这个需求能否满足我们的战略目标
- 实现这些需求的可能性有多大（时间上、资源上）
5 需求文档
关于需求文档，作者提出了几个准则，笔者也觉得十分受用
Positive 描述系统应该做什么，而不是不应该做什么
【错误】这个系统不允许用户购买没有风筝线的风筝
【正确】如果用户想买一个没有线的风筝的话，这个系统应该引导用户到风筝线页面
Specific 尽可能的详细
【错误】最受欢迎的视频要重点标注
【正确】上一周被播放最多的视频要显示在列表的最前端
Avoid Subject Language 避免主观语气。功能规格必须可验证，也就是说它必须要能被证明“这个需求有没有被满足”
【错误】这个网站的风格应该是时尚，闪耀的
【正确】网站的外观应该符合企业的品牌指南文档
最后笔者还想加一句，写完需求文档后最好站在团队成员，或者一个对项目不怎么了解的角色角度去阅读，看看你的需求文档是否说的明白清楚，别人是否能看明白。
说到底，需求文档，是给别人看的，为的是方便别人的工作，而不是自己想法的笔记本。
网友评论