一、流程图定义
流程——顾名思义：水流的路程；事物进行中的次序或顺序的布置和安排。
流程是自然而然就存在的，它可以不规范，可以不固定，可以充满问题。
由两个及以上的步骤，完成一个完整的行为的过程，可称之为流程；注意是两个及以上的步骤。
流程图的核心就在于如何排布事物进行的次序，不同的顺序可能造成截然不同的结果。
二、流程图目的
产品经理画流程图的目的不外乎几点：
-
流程图为产品设计基石，可以保证产品的使用逻辑合理顺畅
-
传达需求，用流程图来更好地表达产品逻辑
-
查漏补缺，检验是否有遗漏的分支流程
三、流程图分类
流程图以描述对象分类，包括：业务流程图、页面流程图、功能流程图、数据流程图等。
业务流程图（Transaction Flow Diagram, TFD）
先以宋丹丹小品中的一个脑筋急转弯为例：把大象装冰箱，总共分几步？
三步：
-
第一步，把冰箱门打开；
-
第二步，把大象装进去；
-
第三步，把冰箱门关上。
这看似是一个笑话，但其实蕴含着很强的逻辑思维。
首先这里忽略了很多现实中的限制条件。比如，以大多数冰箱的容积都不可能将大象塞进去；比如是否能把大象切成块放进去？如果把大象塞进去，它会不会又跑出来？
但抛开这些限制条件，那把大象塞冰箱的极简流程就是三步：打开冰箱门，把大象装进去，最后把门关上。
我们做业务流程图，其实很多时候都需要具有把“大象塞进冰箱”的思维方式，抛开很多现有的认知局限，将具象的行为一个个抽象出来。
结合上面的例子，再来细细品味“业务流程图”的定义：
抽象地描述事物进行的次序和顺序，不涉及具体操作与执行细节；在互联网软件行业通常指脱离产品设计的用户行为流程。
业务流程图是一种系统分析人员都懂的共同语言, 用来描述系统组织结构、业务流程。
不管是否理解上述定义，下面带着抽象思维去思考购物行为的业务流程图应该是什么样的？
以上的三步组成了一个最简的一个流程，其完全涵盖了任何购物行为的核心。
无论是网购还是在实体超市，都是以这三个行为为主体，然后进行扩展的。
相对于大家平时看到的复杂的网购流程图，以上的三步流程简直简单的令人发指，而这恰恰是印证了大道至简的原理。
我始终坚信：无论再复杂的事情都能简化为极其简单的事情，如果你无法将其简化，说明只是你没有理解其核心。
依据上面的最小流程单元，我们下面尝试能不能将其扩展，尝试套用在更细节的流程图上面。
页面流程图（Page Flow Diagram）
定义：指电子产品具体所呈现的页面跳转流程图。其承载了业务流程图所包含的业务流转信息。
下图以淘宝为例，展示出了网购的页面流程。
由上图红框中的三个节点我们可以看出，页面流程图依然是包含在业务流程图的。
这恰恰符合定义中的要求，同时也印证了页面流程图的正确性。
相较于一开始的极简流程图，现在的流程图已经渐渐变得复杂了一些。
我们将抽象的业务，映射在了具象的页面上，用软件的页面承载起了业务需求。而以上就是由业务流程图到页面流程图的转化过程。
功能流程图（Function Flow Diagram）
定义：指单页面内或多页面之间的功能操作流程，其包含在页面流程中。
任何功能都是被包含在页面内的，但一个页面内往往不止一个功能，所以单单页面流程图可能无法完整表达所有流程，而这时就需要用功能流程图来更加具体表达每个页面内所包含的功能。
由上图红框中的四个节点我们可以看出，功能流程图同样也是由页面流程图拓展而来的。
功能流程图是在页面流程图的基础上继续深化，变得更加复杂；同时也渐渐变得像大家日常看到的流程图一样。
数据流程图（Data Flow Diagram）
定义：特指软件产品中，描述数据在不同节点被处理的过程所画的图表，主要表达计算机程序对于业务的实现原理；用户在功能流程图中的每一个操作，对应都会反映在数据流程图中。同时，数据流程图也可以叫程序流程图（Program Flow Diagram）。
它是一种能全面地描述信息系统逻辑模型的主要工具。它可以利用少数几种符号综合的反映出信息在系统中的流动、处理和存储的情况。数据流程图具有抽象性和概括性。
可能业务流程图、页面流程图和功能流程图大家都耳熟能详，但数据流程图恐怕了解的就比较少了。
其实，每个流程图中都有一个核心伴随着不同操作在整个系统中不断流转。比如业务流程图大多以人为核心，每个节点都是在传递人的不同行为。
而页面流程图和功能流程图也类似，都是以人的操作行为为核心，在不同页面和功能间进行流转。但数据流程图不同，它是以数据为核心，展示整个系统中，数据是如何被处理的。
其更偏技术思维，更多的是展现后台程序的实现原理。所以，常常是开发人员绘制此图，而产品经理涉及较少。但随着产品经理地不断成长，向上提高到战略层，而向下则会深入到实现层。理解程序的开发原理和背后的数据流转，无疑会让产品经理对产品设计有更加深刻的理解。
下面仍以购物流程为主题来展示数据流程图。
相较于之前的图表，数据流程图增加了新的维度——程序。客户端在展现用户操作行为的同时，也表达了程序在用户行为背后的动作。
而往往大家说一个产品复杂的时候，可能只注意到了它的前端交互复杂，而忽视了后端逻辑的复杂。
对于一个优秀的产品经理来说，不止要关注前端的用户体验，更要能看清事物背后的逻辑。
毕竟人人都可以对用户体验指手画脚，而说到程序实现，那可就体现出产品经理的专业性来了。
小结
以上几幅图片分别展示了一个产品的业务流程、页面流程、功能流程和数据流程。
从中可以发现：由业务到页面，再到功能，再到数据处理，是顺序拓展的。
一个产品的页面或功能，不是凭空出现的，而是依据业务层的各个节点和流程进行设计的——这就是为什么在做产品设计时一定要先理解业务的原因。
在初步学习画流程图时，尽量将业务、页面、功能和数据区分清楚，并且逐层递进，不要把多种类型的流程图混杂一起——这样反而会将思想搞得混乱。
四、流程图的颗粒度
所谓流程图的颗粒度，其实就是指流程图的细致程度。
我在画流程图时也常常会犹豫纠结：
-
这个功能点用不用描写得更详细？
-
这条分支用不用标出来？
-
这个和服务器的交互事件用不用在流程图体现？
……
等等这些问题，也都是产品经理在日常画图时会遇到的。
依然拿购物流程为例，最简的业务流程分为三个步骤，那如果细化一些，是否可以画出不同的流程图呢？
显而易见，即便针对同一个流程，也能画出不同的流程图。
如上图，将挑选商品拆分为三个步骤，将结账拆分为两个步骤。
但两个流程图依然表达的是一套流程，而这就是每个人对于颗粒度的把握有所不同。
有很多新人总想一步到位，一次画出完美的流程图，但这其实是一种非常不可取的思维。
任何完善的流程图，都需要经过由简单到复杂的过程，而不是一蹴而就。
理论上来说，流程图的细致程度越高，产品设计就越准确顺畅。但实际情况中，过度的详细反而是浪费时间。
而对于度的把握能力，则需要经验积累以及团队磨合，这里也是体现产品经理对颗粒度把握能力的地方。
我们画流程图的最终目的是让团队成员理解我们的产品设计，而不是需要画一幅非常详细的流程图。理想的情况应该是以最简的形式，画出团队都能理解的图表。
五、流程图画法
上面讲解了流程图的定义和分类，下面就进入具体的流程画法讲解：
流程图基本元素：
以上为流程图中最常用的几种元素。不常用的元素就不在此展示了，大家可以在Microsoft Visio中查看。
1. 泳道图
泳道图是流程图中的一种画法，是将流程图中的一些流程节点按操作角色的不同而划分。
比如刚才的数据流程图其实就采用泳道图的画法展示，其中顶部为两个不同角色——用户和服务器。
同时在竖向的基础上也可以添加横向泳道，以不同页面来给操作分类。
对于涉及到多角色比较复杂的流程图来说，画泳道流程图会看起来更加清晰明了。
......
