文章大纲
一、 为什么要画流程图
二、流程图基础知识
三、 流程图介绍与实战
四、参考文章
一、 为什么要画流程图
流程图是对过程、算法、流程的一种图像表示，在技术设计、交流及商业简报等领域有广泛的应用。通常用一些图框来表示各种类型的操作，在框内写出各个步骤，然后用带箭头的线把它们连接起来，以表示执行的先后顺序。用图形表示算法，直观形象，易于理解。有时候也被称之为输入-输出图。顾名思义，就是用来直观地描述一个工作过程的具体步骤，对于产品而言，使用流程图可以实现高效率地与领导、客户、开发人员、测试人员进行沟通。
二、流程图基础
1. 流程图工具的选择
专业的绘图软件
Microsoft Visio，最优秀的绘图软件，功能强大和易用性完美结合，还有数据库、机械等流程图，与Word、PPT等Office文档兼容性很好，插入到这些文档中后，能够直接点击打开编辑/保存；（类似软件：Edraw、Dia、Smarcha）
SmartDraw，最流行的商业绘图软件，包含数百个示例，数千个符号和外形供你使用，充分满足制作各类图表的需要；
DiagramDesigner，是一款小巧免费的流程图绘制软件，速度飞快，功能丰富，支持中文，有模板库，是一个开源软件；
MsvDraw，是一款新的流程图绘制软件，新颖小巧，功能强大，可以方便绘制各种专业的流程图;
其它：Concept Draw PRO、Embedded Vector Editor、PERT Chart EXPERT。
在线的绘图软件/网站
Tersus，是一款基于AJAX的在线绘图工具，支持手绘以及任意图表的制作；
Gliffy，支持中文，操作简单，支持协同编辑，可直接导入Macromedia Freehand、Microsoft Visio，等进行编辑；（类似软件：Draw Anywhere）
Lovelycharts，功能强大，支持拖拽等；
其它，Flowchart、Best4C、ProcessOn。
2. 流程图规范
共识
虽然流程图的类别没有严格的分类标准，但对于其图形表达已经有一套基本的共识。在介绍具体的流程图前，我们先对常用的图形标准达成共识：
流程图尺度把握
（1）给业务人员看的“人人交互模式
对应去掉系统后，人和人之间的交互，此时忽略系统在其中做了什么。以下面的流程图为例：
你发现我们的表述的意思是“用户支付订单->只有用户支付完订单后，客服才能确认订单->客服确认订单后物流才能来收货”，这里体现了人每做一步后，另外一个人才能做另一件事情，没有体现系统在这其中专递信息做了什么，如“系统创建订单->系统显示订单给客服” 等中转过程。因此我们称其为人人交互模式的表达。这个维度上，可以让业务人员聚焦于自己需要做什么事情上。
从递送发票这个环节看，我们也是这样的逻辑“财务打印发票->打印完毕后物流才能寄送发票”，也体现了一个人人交互模式。
而这里特殊的地方是是：
“用户支付完订单”，虽然是对系统的操作是人机交互了，但没有这一步就不会进行发货；
“用户点击确认收货” ，没有这一步，订单就不算完成。因此也要在流程图里面体现。
（2）给研发看的用“人机交互模式”
注意人机交互级别的流程图，主要涉及到人输入什么，系统会反馈什么，但是有两个原则需要注意。
原则一：一个页面定义成一个操作，看下面的例子：
假设在商品详情页此时展示的是一件衣服，则可以选择衣服数量，选择衣服颜色和大小等操作，但流程图的作用不是表达具体功能的，所以忽略这些操作。
一个页面只表达一个操作，下面的页面的第一个操作就是“用户点击确定”，概括为“用户选择商品”。而后面的两个页面也可以概括成“用户提交订单”和“用户支付订单”。
另外不要写画成“用户选择商品->系统显示订单->用户确认订单->系统显示支付界面->用户支付订单”，没有错但略显啰嗦。
流程图重点表达做了什么事情，是不关心所有的功能。用流程图表达功能也不是最佳方案。如果这个例子想表达的是页面的功能，建议直接画页面流程图即可，这个表达对研发更容易阅读，或者用用例图来表达功能合集表示功能之间的包含关系等，都是比这个更恰当的表达方式。
再如下图，有的人说是否应该将其中的细节画出来？如：判断是否已经上架，判断是否有库存等，结论是不应该画。
原则二：和后端服务器交互的定义成一个操作
具体看下面的流程图：
此时当用户进行登录操作的时候，输入完用户名和密码并点击确定，此时APP需要询问一下服务器：服务器大哥，请告诉我密码是否正确？。系统会回答：密码是正确的，或者密码是错误的，或者这是一个用户名没有注册过。
这些涉及到和服务器的交互，显然不问服务器就不知道，则可以在流程图里体现出来。
注意此时忽略人和APP在一个页面内的交互。如：如输入手机号后提示手机号格式错误，你会发现就是一些简单的前端逻辑判断，还不如在原型页面写备注来的简洁和高效。
下面这两个流程图都属于过度表达了。
3. 如何一步步思考画出流程图？
这里有两个基本原则：
- 打通主流程：先粗后细，再加泳道；
- 完善细节：先加异常，再拆流程，再合并流程。
原则一， 打通主流程：先粗后细，再加泳道
第一步：先粗后细的思路
打通主流程意思是不考虑任何异常情况，就考虑正常完成订单的流程。在上篇文章中就是按照这个方式完善了主流程。
我们当时分了三步，分别是：
- 完成很粗的主流程；
- 完善送货流程细节；
- 完成寄送发票等细节。
这里就体现了先粗后细的原则。
完成粗的主流程：
完善寄送发票等流程：
第二步：加泳道的方法
线粗后细完成后，这个过程中出现一个问题，即当有财务，物流和运营等多个角色来处理，每个角色不能很清晰的看到自己的业务怎么办？此时可以用泳道来解决，具体见下图：
此时每个角色下面所对应的就是该角色所进行的动作，非常像游泳时的“泳道”。每个泳道对应的可以是：客服、物流，财务等角色。系统也可以算作一个角色，但应尽可能将其看做一个人，而不要拆分成前端和后端。
原则二，完善细节：先加异常，再拆流程，再合并流程
这样算会否就算完成流程图呢？还没有，需要进一步完善。概括一下就是： 先加异常，再拆流程，再合并流程。我们一个一个来看：
第一步：加异常
上面的流程图我们始终没有考虑异常情况。此时可以从第一个动作一直到最后一个动作逐一梳理是否会有异常的加入。
如本例中，从前往后梳理依次是：用户付款后要求退款怎么办？客服时候可以不发货？用户如果拒收货物怎么办？用户如果一直不点击收货按钮怎么办？用户如果买了以后要退货怎么办？如果用户输错了密码怎么办？如果用户不要发票怎么办？
这里包括三类异常：不操作如何处理，反悔如何处理，错误操作怎么处理？
此时对于用户不要发票，我们如何处理？
此时对于“用户如果一直不点击收货按钮”这个做法，我们就考虑加入“系统自动确认收货”这个流程了。
第二步：拆流程
列出逆流程后，通常就涉及到每个逆流程的完善。但是我们发现“用户收货后退货”这个逆向流程比较复杂，包括：用户提出退货需求，商家同意，用户寄送和商家退款等环节。则退货流程就可以在其他流程图里面再画，这就体现了拆流程的特点。
再如“用户支付订单”会存在支付成功，支付失败，待支付等等流程也可以在其他流程图里面处理。
第三步：合并流程
我们看订单寄送发票的流程包括 “财务打印发票，物流寄送发票”两个步骤，可以抽象成寄送发票。对于财务人员当然要开发票，写不写不影响问题的理解。 在这一步重点在于，去掉本次流程图不关心的内容。如果系统自动收货不是你本次重点表达的内容，也可以去掉。
三、 流程图介绍与实战
流程图是产品经理传达需求的常用做法，PM经常会用到的流程图包括：产品功能流程图、业务流程图、页面流程图等。
1. 产品业务流程图（绘制人：产品经理）
定义
产品业务流程图就是通过图形化的表达形式，阐述产品在业务层面控制的图表。产品业务流程图通常作为产品设计初期阶段的工具使用，通过图形化，能够更清晰、直观地传达产品在业务层面的控制（如业务动作、方向、逻辑等信息）。
作用
业务流程图通常用于介绍产品业务，如产品经理需要向老板介绍产品业务时，用流程图辅助讲解的效果，相较于纯语言或文字表达要好得多。
绘制业务流程图的过程能够帮助PM根据产品定位对产品业务进行设计、分析与优化。
实例
注：这里我们以ofo小黄车为例，粗略地绘制其业务流程图、功能流程图、页面流程图，希望能够帮助理解
2. 产品功能流程图（绘制人:产品经理）
定义
产品功能流程图就是通过图形化的表达形式，阐述产品在功能层面控制的图表。产品功能流程图通常作为产品设计中期阶段的工具使用，通过图形化，能够更清晰、直观地传达产品在功能层面的控制（如功能动作、方向、逻辑等信息）。
作用
功能流程图通常用于介绍产品功能模块的相互关系或某个功能模块的具体组成，如产品经理需要向开发人员介绍某个新增功能模块时，可以在原型图宣讲之前使用功能流程图让其对功能的轮廓和走向了然于胸。
绘制功能流程图的过程能够帮助PM确定产品的功能范围同时避免不合理的功能使用逻辑。
实例
3. 产品页面流程图（绘制人:交互设计师、产品经理）
定义
产品页面流程图就是通过图形化的表达形式，阐述产品在页面层面控制的图表。产品页面流程图通常作为产品设计后期阶段的工具使用，通过图形化，能够更清晰、直观地传达产品在页面层面的控制（如页面功能和信息、方向、逻辑等信息）。
作用
页面流程图通常用于介绍产品页面元素及页面之间的跳转关系。
产品页面流程图一般由专门的交互设计师进行设计，其绘制过程能够帮助交互设计师确定产品页面之间合理自然的跳转顺序以及页面本身的功能及信息构成。
实例
