做一个互联网产品设计者，编写Use Case是日常工作的一个重要内容，也是重要的技巧。
回想起来自己当年从市场部转入到产品部，编写UC也是从0开始，最初就是拿着别人写的东西，然后按照自己的思路去设计新产品。刚好今天因为工作的关系，又再跟同事说如何写好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