血泪总结！5000字产品需求写作方法论

本文由作者唠呵于社区发布

前段时间，由于项目的开发周期卡得非常紧，在极端的高压下，我一个多月内连续设计了三款B端产品，累积写了好几万字的需求文档，画了数百个页面，每个B端产品都涉及多方角色和系统的交互，业务逻辑非常复杂，回顾那段时间过的，真是生不如死，差点就憋出抑郁症。

但是好在我熬过来了，苦尽甜来，也算是学到很多的东西。

以前做产品的时候，没有那么严格的上线时间点，有充裕的时间思考，哪怕有很多思考得不周全的地方，也可以花很长的时间去弥补，所以问题都被悄无声息地掩盖了，但是，经过前段时间高强度的压迫输出，需要在极短的时间内做出高质量的方案，问题便展露无疑。

比如，

明明老早就已经想好的功能，后面写需求的时候却忘记了，直到测试的时候才想起来。

需求都已经写好了，正打算好好休息，跟朋友happy一下，却突然想到还有一些异常流程没有考虑到，导致前面已经梳理好的所有流程和页面都需要重新改动，那一刻我的心是崩溃的。

需求评审时，程序员直接指出了一堆异常场景，而这些场景此前自己完全没考虑到，顿时一阵语塞，好不尴尬。

有些功能想得太粗，只是简单带过，导致开发还需要来主动问具体的实现逻辑是什么，产品经理的专业性受到了严重的质疑。

之所以会出现上面出现的各种窘境，最主要的原因还是在于自己写需求的方式不对，都是想到啥写啥，没有遵循一定的流程和步骤。

写需求过于随意，则容易过早地陷入细节中，没有做好顶层设计，后面自然会漏洞百出，在开发面前百般出糗，长此以往，一定会让研发同事或者其他团队成员认为你不专业，后续推进必然会存在障碍。

于是，我花了很大一部分时间对此前做的项目进行全面的总结回顾，也找了很多书和文章来看，总算形成了一种行之有效的需求写作方法论，以这套方法论写需求会感觉非常顺，指哪打哪，不会像以前一样写着写着突然感叹自己从哪里来，到底往哪里去的迷茫感。

我打算把这套需求写作方法共享出来，如果大家有遇到跟我一样的问题，希望这个方法能帮助到你们。

为了让这套方法更容易被吸收，我以一个简单的点餐小产品作为案例在全文中穿插着进行讲解。

01

系统用例图

系统用例图是指由参与者，用例以及它们之间的关系构成的用于描述系统功能的视图。

它是我们写需求的第一步，是根据业务用例图分析得到的，针对于业务用例图的用户行为分析后，从系统侧去建立对应的模块。

业务用例图在这里就不细说了，它是我们在调研用户需求的阶段输出的产物，展现形式跟系统用例图基本一样，不同之处只是在于它更注重用户的需求是什么，是从使用场景去考虑的，而系统用例图也更加注重需求对应的系统功能是什么，用户能通过这个系统做些什么。

系统用例图是产品最顶层的设计，它构画出了产品整体的架构，后续所有的流程和页面设计都需要围绕它进行展开，所以应该非常地重视它。

它的目的简单来说就是这么两点:

1.系统有哪些用户角色

2.每类用户角色能使用这个系统做些什么

你可以把系统用例图理解成我们熟知的功能清单，它相当于形象化地展示出每种角色享有哪些功能，并将功能与角色一一对应起来。

比如我们要讲解的点餐小产品，它有两类角色:

1.顾客

2.厨师

顾客可以用产品做什么？他可以用来点餐，以及查看已点餐品的状态。

而厨师可以做什么？他可以查看顾客已点的餐品以及餐品的桌号，还可以操作餐品的状态，操作餐品的状态又可以往下细分，包括开始做餐，餐品售罄，餐品出餐。

那么，我们的系统用例图大概可以画成这样:

用例的层级需要分清楚，比如顾客需先查看已点的餐品，才可以往下查看餐品的状态，厨师需要先查看已点的餐品，才可以往下继续查看餐品的桌号以及查看餐品的状态，不同的用例是有先后顺序的，这一点需要注意。

在这一步，相当于把整个小产品的骨架给搭建起来了，这一步一定要考虑得非常周全，当然，细小的骨头暂时可以缺失，后面在画细节的时候能发现并弥补回来就可以了，不会影响大局，但是千万不能缺了撑起整个骨架的关键骨头，不然后面的流程图也会跟着缺失，流程图一旦出问题，则导致整个产品都会接连出问题，后面改起来一定会非常痛苦，这一点我可深有体会。

当然，很多时候用例图和流程图的思考顺序是相互交叉的，没有绝对的先后顺序，因为你在思考用例图的时候其实就已经把流程熟稔于心了，如果脑里没有流程，你也无法把用例图很全面地画出来，而画流程的时候，又经常会回过头来补充之前用例图没有考虑到的部分，所以，写需求的过程，不是线性的，而是折线型的，需要来回地进行修补。

02

普通流程图

普通流程图是我们最常见的流程图，每个人在工作中或多或少都会接触一点，这里的“普通”主要是为了区别于后面要讲的跨角色或系统流程图来说的，它让你更侧重于业务的流程与步骤，而不要分散精力去关注哪一步是谁做的(这一点是跨角色或系统流程图最为关注的)

比如点餐小产品，它的业务流程是这样的:

1.顾客点餐

2.厨师看到餐品

3.厨师将餐品状态改为开始做餐

4.厨师开始做餐

5.厨师将餐品状态改为餐品出餐，然后把餐品贴上桌号

6.送菜员拿餐

7.送餐品上桌

流程图可以这么画:

流程图中，虽然不同的步骤是由不同的角色做的，但是并没有明确地在图中标注出来，只是文字一笔带过，这一步不需要关注到具体的角色，只需要关注业务流程，从大体上去描述业务是如何运转的，如果过早地陷入细节中，反而会让你考虑得不够周全，导致漏掉一些关键的节点，也会让开发人员看得云里雾里，无法清晰地看出业务的全貌。

由于我举的例子只是一个小产品，所以流程比较简单，如果你设计的是一个复杂的产品，那么，流程的链条则会长很多，而且可能需要画多个流程，包括主流程和子流程，最好把流程的层级关系也标记出来，这样才便于自己或者开发更加理解业务的逻辑。

03

跨角色或系统流程图

跨角色或系统流程图，主要是梳理清楚角色或系统各自的分工和模块相互之间的串联，它是我们画完普通流程图之后第一步要做的事情，相当于是对普通流程图的进一步地解释。

很多做C端产品的朋友很少接触到这种流程图，因为简单的业务逻辑其实只要普通流程图就足以描述清楚，不需要特意区分角色就能看得明白，但是一旦涉及到N多角色多系统之间的交互，如果没有用合适的图形语言来思考和表达，则很容易导致逻辑混乱，不但自己拎不清，则会让看的人摸不着头脑。

对于跨角色的流程，我们一般用泳道图来表现，就拿上面的点餐流程来说，可以画成这样:

上面表现的主要是不同角色之间的交互流程，它更注重的是不同角色之间交互的逻辑，而对于那些比较复杂的产品，还可能涉及到不同系统之间的交互，我们需要关注它们在哪些地方需要产生交互，交互的数据是什么，这个直接影响开发人员对接口的设计。

比如互联网金融产品的授信流程，我们需要体现出我方产品是如何与第三方征信机构进行交互的:

用户提交的信息会通过接口传到第三方的征信机构，第三方的征信机构返回征信的结果。

这种图叫做时序图，通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。它可以表示用例的行为顺序，当执行一个用例行为时，其中的每条消息对应一个类操作或状态机中引起转换的触发事件。

简单来说，就是展示不同系统之间哪些地方需要对话，是如何对话的，对话的顺序是什么。

跨角色或部门流程图展示不同角色或部门之间的交互逻辑，时序图展示不同系统之间的数据传递，根据产品形态的不同，我们可以互相搭配着用。

04

异常流程图

上面所涉及到的流程，考虑的是作为一个用户最主流的场景，通常不会涵盖其他异常的场景。

比如，一个用户在登陆时，一般来说都会输入正确的手机号，输入正确的图形验证码，获取短信验证码，然后输入并登录，这是一个最主流的场景，而对于一个产品设计者考虑的则不仅仅是这些，还需要考虑到一些非主流的场景，比如验证码输错，手机号格式不对，没有输入图形验证码等各种情况。

比如上面的点餐流程，主流的场景就是，用户点餐，厨师看到餐品，开始做餐，出餐，然后服务员拿餐，最后送餐上桌，但是，异常场景也有可能会出现，用户点餐的时候，这个菜品没有了，或者用户点餐后，厨师在做菜过程中发现原材料不足了等等。

当然，我所讲的异常流程图跟异常场景还不是一回事，异常流程图更加关注的是足以形成流程的场景，比如像上面所说的登录的这种，一般不需要动用到流程图去解决，只需要后续在写需求文档的时候，在具体的页面原型上把逻辑说清楚就行。

那什么才是异常流程呢，通常指的是逻辑比较复杂，需要动用到流程图表现出来的异常场景。

就拿现在很火的视频会议来举例。

比如，某视频会议产品有两种付费模式，购买会议次数或者购买包月或包年服务，某用户此前已经购买了2次会议，但是他又不小心去点了购买包月服务，那么，此时系统则需判断该用户是否已经购买过包月或包年服务，即判断他的会议有效期是否已经结束，如果还未结束，则需提示他无需重复购买，如果已经结束，系统还得继续判断他是否还剩没有用完的会议，如果有，需提示他用完才可以继续购买。

这种异常场景相对于上面所提到的登陆会复杂许多，通常需要用流程图表现出来，才不容易出现差错。

我们作为产品设计者，一定不要想当然地觉得用户不会这么去操作就不考虑它，而是需要把所有可能会出现的场景都要考虑到，把体验做到最好，减少用户的损失。

05

页面流程图

上面的流程都想清楚之后，接下来就要进入到具体页面的设计了。

但是，现在还不是画原型图的时候，一定不要一开始就陷入到页面具体的元素中去，比如页面有哪些字段，有哪些按钮等等，而是应该从整体上去考虑。

比如点餐小产品，它的页面流程图可以这么画:

当然，这里还没有把所有的页面都列举出来，只是展示了个大概，方便大家理解即可。

在这一步，我们思考的是，产品总的有多少个页面，页面之间的关系是怎么样的，它们是如何进行交互的，这样我们可以从高处俯瞰整个产品的页面架构以及页面之间的关联关系。

这个过程跟我们写文章很类似，要先列好大纲，然后再针对具体某个论点展开论述，页面架构其实就相当于文章的大纲，后面原型的设计则相当于论点的详述，只有通过这种从宏观到微观，从抽象到具象的思考方法，才能紧跟产品的脉络，不至于迷失方向，出现遗漏或差错。

06

原型图和需求文档

当把上面的所有流程图画完后，接下来就是我们最熟悉的一步了:画原型和写文档。

所谓画原型，无非就是把页面流程图中所涉及到的每一个页面，以及每个页面里所有的元素，包括字段，按钮，菜单等等，全部都画出来而已。

而需求文档简单来说就是看图写字，把上面所画的流程图和原型图一一进行文字说明，把自己脑里面的图形思考付诸于文字，让别人看得更加明白。

文档中需要把流程图的逻辑，以及每一个页面上的元素，操作和跳转逻辑讲清楚，文档的架构可以是这个样子:

说到页面上的操作和跳转逻辑，除了一些页面级的特别细微的点，大部分在上方的几个流程图中都已经说清楚了，在这里只要把逻辑对到页面上的某个具体的元素上就可以了。

比如在异常流程图中所提到的，如果这个人已经购买了会议次数，那么他在购买包月服务的时候就应该提醒他已经购买过了，而在原型图中，就要让开发知道，这个判断是出现在哪个页面的元素上。

比如，它是用户在付费页面上点击付费按钮的时候进行判断？判断后会出现提示吗？提示是弹框还是只需要旁边出现文字说明？这都需要一一说清楚。

07

用户权限表

在文档的结尾或者文档的开头，还需要附上各角色的权限说明，包括功能权限和数据权限。

功能权限：

数据权限：

总结

到这里，一整套写需求的方法就讲完了，这些都是我在做产品的过程中踩了无数的坑之后总结出来的，我自己感觉非常有用，当然，这套方法不一定适合所有人，它也不是一成不变的，我们可以把它看做一款产品，需要不断地对它进行迭代优化，最终沉淀出最适合自己，最行之有效的方法论。