如何写一个优秀的Use Case(1)
时间:2009年02月28日 内容来源: 互诺科技 浏览量:0

做一个互联网产品设计者,编写Use Case是日常工作的一个重要内容,也是重要的技巧。
回想起来自己当年从市场部转入到产品部,编写UC也是从0开始,最初就是拿着别人写的东西,然后按照自己的思路去设计新产品。刚好今天因为工作的关系,又再跟同事说如何写好UC,顺便这里总结一下。
先发一个UC的常用模板:
————————–
用例名称
最新更新日期:

负责人:

用例描述:

用户界面设计:

用例场景:

用户:
前置条件:
主流程:
后置条件:
扩展流程:
输入项详列:
输出项详列:
关联UC

补充规约:
遗留问题和可能的解决方案:

————————–

作为产品设计师,开始做一个新产品设计,一开始的时候,通常是在脑子里面的一堆想法,idea或者是跟需求方讨论出来的一些业务规则等等,最终要变成可以实施的项目,需要产品设计师去梳理,规范化需求,并最终形成需求文档,UC是其中最典型的文档产出物了。

我的建议是:

1、原则上流程图,特别是业务流程图是最先开始要拿出来的,在流程图中要确保各个业务流程是完整的,而且是效率最高的。这个需要比较多时间的讨论和细化。
2、将业务流程拆分成为一些典型的用户交互模块。比如:用户管理模款、帐户管理模块等
3、将每一个模块划分成为典型的用例组合,比如:用户注册、用户信息修改等等。
所以在具体开始写UC的时候,我的建议是:

1、不要一个UC写完整了再写一个,建议是先通盘写出所有UC的名称(其实名称一定程度上已经定义好了UC的主要工作目标了,比如:用户注册、注册用户信息修改、帐户信息检索等)。等于是写文章的一个提纲,主要的章节都有了。然后再看一遍,对照自己脑子里面的业务流程,看看是否有遗漏的。

2、写完成UC的描述,我的常用格式是:通过本UC…., 比如“通过本UC,用户可以完成支付宝用户的注册。” UC 描述基本上已经明确定义了该UC的范围,大小。在往下写之前,对该UC应该完成的主要功能,以及会遇到的所有分支、输入输出应该有明确的定义。UC的撰写过程只是将上述的内容进行细化和规范化,变成其他人可以阅读使用的东西。特别提醒一点:UC是给别人看的,而不是你自己看的。

3、下面说说正式写UC正文的时候,我个人觉得特别要注意的地方:

正确的定义UC的用户和前置条件,将会有效的改善UC的流程复杂性。比如:淘宝要做一个专门为淘宝卖家准备的产品。淘宝卖家第一次进入该产品,需要确认一个服务条款。怎么定义用户和前置条件?常见的会有:
用户已经登录
用户为淘宝卖家
用户尚未确认最新版本的服务条款

根据上面的业务是为淘宝卖家做准备而言,上面的用户定义貌似没有问题,但是在实际产品设计中中会遇到一个问题:怎么判断用户是淘宝卖家?用什么条件?看,麻烦来了,所以,我的建议是,把上面的第二条去掉。会有问题吗?当然具体还是要看业务,我只是举例子,说:用户的定义将很大程度上影响流程的复杂性。

4、主流程一定是你希望的流程,你认为用户最顺利操作你的产品的流程,那么它就是主流程。很多Pd在写UC的时候。主流程无比复杂,里面加入无数的判断,就是因为这一点上没有明确。我自己的感觉是,往往一个UC,主流程可能很短,而分支流程会比主流程多,而且复杂。
Kimi注:未完,待续

原文:http://www.kimihome.net/blog/?p=701