在本课中呢，我们来学习一下如何撰写《用户用例文档》。

说到用户用例，大家肯定会想到另外一些以“用户”开头的词，比方说，用户画像，用户原型，用户故事什么的，那么，用户用例和这些词之间有什么关系呢？

接下来呢，我们就先来简单介绍一下它们之间的关系。

说起来呢，无论是用户用例，还是用户画像，用户原型，用户故事，其实都和产品管理中一个很重要，也是很流行的一个工作有关，什么工作呢，就是场景构建。

因此，我们先简单了解一下场景构建是什么，大家看PPT1：

PPT1

关于场景构建的详细介绍，大家可以参考《不懂电影的产品经理不是好产品经理—产品场景的系统化设计》这篇文章，或者在千聊中有个音频《产品经理应该涉及的三种场景设计》，大家听一下就成啊。

如果我们从电影的角度看，其实场景构建就类似于电影中的情节设计，那么，一个情节都应该包括哪些要素呢？五个：

1）时间：说明在这个时间点会发生什么；

2）地点：说明在这个空间里要发生什么；

3）人物：说明谁处于这个时间和空间里；

4）事件：说明在特定的时间、空间里，这个人物做了什么；

5）关系：说明这个场景中出现的人和物与其它的哪些场景有或明或暗的联系。

这五个要素在我们的场景设计中都是如何体现的呢？大家看PPT2：

PPT2

由此可以看出，如果说时间和地点是静态要素的话，那么，事件和关系则是动态要素，这是什么意思呢，很简单，时间和地点往往是确定的，比方说，我们星期六到4S去买一部汽车，星期六和4S店就是时间和地点，这个时间到这个地方买汽车，无论有多少人，大家都是一样的，不会变的，而事件和关系，则会有明显的差异，比方说我们可能已经在网上查了很多资料的，这次去就是看看实车，谈谈优惠，而有的消费者呢，则可能是去看看车，试驾一下，了解一下车的参数，然后作为备选的，这就是事件，而关系又是指什么呢，比方说，我们去4S店，可能带的是自己懂车的朋友，而别人呢，则可能带的是自己的媳妇和孩子，他们和我们在买车这个事件上就肯定形成了一定的关系，而这种关系则会对我们的买车产生影响。

这就是场景中的静态因素和动态因素，但是大家发现了一个关键点没，无论是静态因素，还是动态因素，会随着一个要素的不同而产生不同的结果，这个要素是什么呢，就是：人物。

换到产品管理工作中，就是指角色群。

这个讲过很多次了，再重复一遍啊，角色群包括：使用者；购买者；影响者；决策者和倡导者。

关于这个角色群的说明，在第十节课，产品定位文档中有介绍，大家可以返回去看看啊。

因此说，人物/角色群就构成了场景的关键，其实想想也是，一部电影，就算情节再精彩，但是没有能够演绎这个情节的演员去诠释，整个电影就会苍白无力。

同样的道理，如果我们搞不清楚角色群到底是怎么回事，那么，你设计的场景再天衣无缝，也没有办法把合适的角色纳入进去。

总之一句话，场景设计的关键在人物，它直接会影响到静态因素和动态因素的显现能力。

了解产品管理近十多年发展的朋友应该知道，其实最早的时候，并没有场景这么一说，那个时候的产品经理主要的任务就是研究角色群的每类角色，后来才逐渐形成场景构建的工作。

好，关于场景和角色群（以下我主要以使用者，也就是用户进行说明）的关系就说这么多，接下来，我们看看针对一个用户，我们需要做的研究工作有哪些。

总结起来，其实就是三个，大家看PPT3：

PPT3

针对这三个研究项，我们通常使用的工具就是三个：一张图，一个文档，一个表格。

特征，我们通常会用用户画像来呈现，这个工具呢，在PMM中就有，大家可以用一下，很好用的。

问题/需求，我们通常会以用户故事表格的形式来呈现结果，这个呢，大家可以参考《产品经理们，今天我们讲“故事”》这个系列，里面有详细的样例。

行为，这个就是今天我们讲的这个《用户用例》文档要来呈现的了。

好，正式开始我们今天的课程。

在这个文档中，主要的内容分为三个部分，分别是第二，第三和第四部分，不过第二部分依然是前面文档内容的汇总和摘抄，我就不详细讲了，大家看图1：

图1

我们来看第三部分，在这个部分里，一共有四个关键章节，分别是3.2主要用户描述，3.3主要用户需求，3.4可选用户描述，3.5可选用户需求和3.6用户目标。

具体怎么来写呢，其实也是参考前面的成果，我的DD这个产品，在前面的市场细分工作中一共划出了几个目标人群呢？两个：分别是“专业使用型”和“主动需要型”，这两个就是这个部分中的主要用户，怎么来写这个章节呢？大家看图2：

图2

我这里以“专业使用型”为例做个说明，很简单，只需要把PMM中制作好的用户画像插入进来就可以了。

同样，在3.3“可选用户描述”这个章节中也用这种形式就可以了。

接下来我们来看3.3和3.5章节，这俩章节写什么呢，就是写两类用户各自的需求是什么，呈现形式都是一样的，我还是以主要用户为例进行说明，大家看图3：

图3

这个表格中的内容也很简单，主要是来源于前面所做的问题汇总矩阵和需求矩阵表中的内容。

我们再来看第三部分中的最后一个章节，用户目标。

这个目标是指什么呢？在撰写说明中有介绍，大家看图4：

图4

关于用户目标的介绍，大家只记住一句话就可以了：目标就是用户期望实现什么。目标不是任务。

这是什么意思呢？

比方说，产品经理希望在使用DD的翻译过程中，词库中的词条能够智能的形成为产品管理的专业词条，而不是默认的，例如PM，应该是产品经理，而不是项目经理，那么，对于这类用户来说，目的是什么呢？

就是提高翻译质量，提升翻译效率，这就是用户的期望，之所以说目标不是任务，就是因为任务是实现这个目标的过程，例如，产品经理在使用DD的过程中，DD会根据产品经理的使用自动更新词库，这个就是任务，而不是目标，产品经理使用DD最终的目标还是希望形成产品管理词库，从而在后续的使用中更有效率和更有质量。

明白了这个，这个表格就好写了，大家看图5：

图5

好，到这里，第三部分的五个章节就算完成了，接下来就要进入到本文档中最关键的一个章节了，就是对用户用例进行说明。

虽然关键，但是呈现形式还是比较简单的，就是一张表格，大家看图6：

图6

关于每项如何是什么意思，表格中都有解释，接下来，我还是基于案例来说说如何来写。

先来看表格中前面的六项，大家看图7：

图7

这六项是比较好写的，无非还是前面内容的摘录，不过在写这六项的时候，有一个地方需要注意一下：一定要为用户起个名字。

有朋友会说了，这不是多此一举吗，非也，我们得这样想，这里只是针对专业使用型这类人群进行的用户说明，如果你有多个目标细分市场，那么，如何在用例中区分呢，当然，你可以说，我可以用ABC的字母来代替，但是既然都用到ABC了，为什么不起一个比较形象，能代表这个目标细分人群特点的名字呢？

这就像电影里的角色名字，主角，正面人物的名字永远都是高大上的，对吧，这也就是为什么在撰写说明中提到的：在表格中，用户被当成Actor。

国外同行在撰写这个表格的时候，是一定会为用例起一个很好的名字的，原因是因为他们会把这个虚拟的人物当成自己团队中的一份子，既然是自己人了，那当然该有个名字的。

好，接下来我们看后面的内容怎么来写。

1）前提条件

前提条件是指什么呢？

就是指用户在使用产品前的因素。

比方说，对于DD而言，有些用户在开始查词之前，习惯于看一下词库是否有升级，这就是前提条件。

就我个人的经验，可以说所有的产品都有前提条件，比方说，开车的时候，我们会有哪些前提条件呢，这个就多了，开窗透气，热车，对吧，还有女孩子们化妆，在往脸上正式捯饬各种粉之前，要做什么呢，肯定是得用洗面奶或者洁面膏先把脸洗干净，对吧。

2）使用条件

使用条件是指什么呢？

就是指导致用户以明确方式使用产品的因素。

这个比较容易理解，比方说对于DD这种软件产品而言，肯定在软硬件上会有一些要求，硬盘空间了，CPU要求了，操作系统版本要求了等，同样，在一些其它产品上也会有使用条件，比方说刚刚过去的618，有些朋友肯定拿了各个电商平台的一堆优惠券，红包什么的，但是要使用这些优惠券，平台肯定有条件要求，比方说，100元的优惠券，只有消费金额达到300元的时候才能用。

这就是使用条件。

3）产品交互的正常流程

产品交互的整成流程，这个就简单了，就是指用户通常使用产品的主要流程。

这个我们一般会通过使用流程图的形式来呈现，如果是软件或互联网产品，我们会通过构建产品原型来表现，而对于其他产品而言，一般就是用流程图制作工具来实现。

大家在日常工作中做的比较多，我就不展开讲了。

4）异常流程

异常流程，从名字上就可以知道，这个是指产品使用的流程变化以及不同的使用方法。

什么意思呢？

一般来说，我们设计的使用流程通常是按照我们构想的最合理的，最规范的使用流程来设计的，但是用户千千万，我们不可能要求每个用户都按照我们设计的使用流程来使用产品，我们也做不到，对吧，因此，这种非规范流程的使用，就被称为是异常流程。

比方说，对于DD而言，在查到一个生词的时候，我们会提供加入单词本的功能，我们设计的流程是右键点击生词，出现“加入单词本”的选项，点击选项按钮，这个词就加入到了单词本。

但是，有些用户就不这么使用，他们习惯的流程是复制这个生词，然后从工具选项中打开单词本界面，然后再把这个生词黏贴进生词本。

其它产品同样有异常流程，比方说我们在使用电脑关机的时候，我们建议的流程是退出全部打开的应用程序后再关机，但是有些用户就不，他们的操作是不退出这些程序就关机。

这就是异常流程。

知道异常流程的目的是什么呢？主要有两个：

1）更加了解我们的目标用户真实的使用产品的过程，从而尽可能的改进产品的用户体验过程。

2）知道异常流程可能带来的产品使用风险，从而不断提升产品的质量，比方说不退出打开的程序就关机，那么很有可能造成某个程序文件的损坏，那么，作为操作系统或电脑厂商的产品经理，就要考虑如何保证异常文件在异常流程状态下不会被损坏。

我们在做异常流程设计的时候，需要注意两点：

1）异常流程不是错误流程，它只是不同用户在使用产品时，因为习惯，经验，能力等因素造成的使用差异。

2）我们无需对所有可能的异常流程进行设计，我们也做不到，我们只需要对集中，主要的，关键的异常流程进行确定和设计就可以了。

5）后决条件

后决条件是指什么呢？

它是指用户在使用产品完成后的因素。

比方说，对于DD而言，有些用户在使用结束，关闭程序后，还会刷新一下桌面，或者打开任务管理器确定一下是否在内存中退出了，当然，现在windows操作系统已经对内存管理做得很好了，这个习惯是以前内存管理不好的时候形成的。

其它产品同样有后决条件，比方说，我们把车停下，在遥控锁车后，很多车主还是习惯拉拉车门，确定一下是否把门锁上了，还有化妆品，晚上女孩子在卸妆的时候，肯定不是直接洗把脸就完了，而是要先用卸妆水，对吧。

后决条件和前提条件是一组条件，我们确定这俩条件的目的是什么呢？

说起来也简单，就是从细节上想清楚一个产品的使用过程，不断改进和完善用户的产品体验过程，这个工作从产品管理的角度看，就是业务流程构建。

6）使用频率

使用频率就就简单了，就是指在给定的时期内产品将被用户使用的次数。

比方说，对于DD而言，像这种专业使用型的用户，在一周的时期内，使用频率为每天3次，每次50分钟。

7）假设条件

最后呢，还有一个条件我们不用忘了写，就是假设条件。

什么是假设条件呢？

就是指用户用例中形成结论的所有没有明确数据或事实支撑的主观思考的条件。

比方说，对于DD而言，上面提到的专业使用型的用户使用频率，如果我们没有确切的数据支持，那么，我们必须在这里写清楚，这个结论是基于假设的。

其实假设在产品管理中是很正常的，尤其是对于一个新产品而言，我们做的很多预测性结论都有一定程度的假设成分来里面，这个不用耿耿于怀，本来管理产品的过程，就是逐渐把不确定变为确定的过程。

好，关于后七项怎么来写，我就简单说这么多，大家看图8：

图8

最后来总结一下撰写用户用例这个表格的内容。

1）在主要的13项内容中，其实是有规律的，比方说刚才提到的前提条件和后决条件就是一组关系条件，同样，正常流程和异常流程也是一组关系流程，如果我们用一张图来形象表现的话，那么就是这样的，大家看PPT4：

PPT4

如果用一句话来概括用户用例如何来写的话，那么就是：

一个具备什么样特征的用户（用例特征说明），在什么样的条件下（条件说明），用自己习惯的流程（流程说明）感受到了什么样的用户体验（体验说明），并产生了什么样的使用结果（频率说明）。

2）用户用例的工作要远远多于很多朋友花了大部分时间在做的产品原型，前面也提到了，产品原型只是用户用例中的一个内容而已，或者可以这样理解，产品原型是表现产品是什么样子的，而用户用例则是表现产品被什么样的用户去使用的。

这样揭示了一个真相，就是作为产品经理，如果把大部分的精力放到产品原型设计上，那么多少是有点没抓住重点的，毕竟产品经理，最需要研究的是用户如何使用产品来解决问题，而不仅仅是产品做成什么样。

3）如果从产品场景构建的角度看，用户用例更多的是构建使用场景，那么，用户场景和营销/运营场景在哪里构建呢，这个呢，我会专门做一套课来介绍的。

好，本节课就讲到这里。