我们做产品设计的时候，会碰到非常多的业务流程，有简单的，有复杂的，有单作业的，也有多作业的，当我们碰到需要跟开发解释一个相对复杂的流程时，无论多么详尽的表述，都远不如一个清晰的流程图来得有用。
如果一个业务流程你认为它复杂到无法用流程图来表达，那多半你也无法用文字来表达。
有些文科出身的产品经理，对文字的敏感度远超图形，所以他们能用非常详细的文字去描述一个流程的各个细节，但是如果你让他们画一个流程图出来的时候，却没人能看得懂，如果你刚好是这样的人，希望这篇文章对你有帮助。
一、认识流程图
在绘制流程图之前，需要先认识流程图上的不同图形代表了什么意思，以便你在绘制流程图时可以正确使用它们。
一般用【椭圆形】表示流程的开始或结束节点，用【矩形】表示流程的常规节点，用【菱形】表示流程的判断节点，节点与节点之间，通过【箭头】进行连接。绘制的时候可以考虑给不同的图形加上不同的颜色，这样辨识度更高。
这样的约定使流程图的绘制者和阅读者更容易达成共识，也使绘制的流程图更具易读性。
二、单作业流程图
这是最简单的一种流程图形式，它只是系统中、甚至只是某个系统功能模块中的流程；它只描述一个用户的动作，或者只是描述一个功能模块的运作逻辑。
比如我们可以来绘制一个最简单的用户登录操作流程图：
上图是从用户操作的角度，描述用户完成一个业务操作的流程，这种流程图，称为【业务流程图】。
我们再来绘制一个登录校验的流程图：
上图是从系统角度，描述一个功能的处理逻辑，这种流程图，称为【系统流程图】或【功能流程图】。
我们甚至可以对输入手机号这个操作单独绘制它的校验流程图：
通过以上几个简单的流程图，我们来总结一下一个合格的流程图应该怎么画：
1、用正确的图形表达对应的节点，节点文字简洁清晰描述执行的动作，必要时可增加注释。比如上图校验手机号对前3位数字的判断，由于条件比较多，如果将所有可能的前3位数字全部写出来，流程图就太过臃肿，像这种情况，只需要简单举个例子或加个注释说明，让开发知道这里是要进行什么判断即可，至于详细的判断规则，应该详细记录在需求文档中。
2、同一个判断节点，判断结果控制在3个以内，2个最佳，如果判断条件比较多，尽可能分多个判断节点，每个节点只处理一个判断条件。如果一个判断条件有2个结果，那么两个判断条件放在一起就可能大于4个结果。
3、线条尽可能少交叉和重叠。
4、尽可能合并相同作用的流程节点。这样可以使流程图更加简洁，但要注意，如果两个节点的作用不相同，一定不要使用相同或相似的节点文案。
5、按主线流程从上到下绘制，支线流程从左往右延伸。人的阅读习惯是从上到下，从左到右。
6、如果一个流程过于复杂，可以将其中可独立的子流程单独绘制成流程图。比如上述例子中，将登录的主流程和登录中输入手机号校验的子流程分别绘制两个单独的流程图，这样更便于开发理解，如果混在一个流程图中，会让人觉得看起来要处理的逻辑太多，主流程和子流程交叉进行，看图的人会觉得未免过于复杂难懂。
根据上述结论，我们来看一个极端的反面例子：
从上面的例子中，我们可以知道这个流程图有以下问题：
1、全部的节点都用错了图形。
2、一个判断节点同时进行多个条件判断，判断结果太多，流程混乱。
3、流程线条重叠，影响阅读。
4、关于是否11位数字是一个单独的判断条件，只需要输出一个错误提示结果即可，太多提示显得流程过分冗余。
5、流程“左右开弓”，阅读时容易感到无所适从。
三、多作业流程图
多作业流程图就要复杂得多，它可能涉及多个角色，也可能涉及多个系统，甚至可能同时涉及多个角色和多个系统，接下来将逐一举例说明。
在这之前，我们需要先认识一个新的图形——【泳道图】。
顾名思义，泳道图有多个泳道，每条泳道可以代表一个角色或一个系统，这样我们就可以在不同的泳道中表达多角色或多系统之间的协作流程。
举一个多角色协作的例子，假设 OA 办公系统中请假的主要流程是这样的：员工请假→上级主管审批→人事经理审批→总经理审批。全部审批完成后请假才能生效，如果有其中一人拒绝，就不再将流程提交给下一个审批人。我们来绘制一下这个流程图：
每一条纵向的泳道代表一个角色，按照审批顺序从左向右排列，然后把每个角色的流程画在对应的泳道内。
多系统的流程也是相同的画法，如果是多角色多系统同时存在呢？
还是上面的例子，我们假设考勤是个单独的小程序，员工通过考勤小程序请假，审批者通过 OA 系统审批，这个时候就涉及多系统多角色的协作。我们上面画的是纵向泳道图，这个时候我们只要引入横向泳道图来表示多个系统就可以了：
1. 流程优化
一个流程图好不好，不只是看它是否画得清晰易懂，也不只是看它画得是否美观简洁，还要看它表达的逻辑是否合理以及是否最优。
上图是大多数平台注册时需要填写的字段，首先我们针对上图这些注册条件，绘制出一个注册流程中校验手机号是否已注册的流程图：
这个流程图画的没有问题，在逻辑上也是成立的，但它是否就是合理的或最优的呢？我们来分析一下。
如果用户按主线流程最终注册成功，这个流程是没有问题的，但如果用户的手机号之前已经注册过，对用户而言，这个时候用户已经输入了一堆的信息，你才告诉用户注册不了，用户会觉得反感，甚至恼怒，对平台而言，发送验证码的短信费用，本是一笔可以避免的支出。
因此，我们可以对这个流程进行优化，首先在用户输入手机号之后，系统先查询手机号是否已注册，如果已注册，这时就可以马上提醒用户：
如果用户不理会提示，继续往下填写注册信息，在发送验证码的时候，如果手机号已注册，此时发送验证码给用户是没有意义的，所以在发送验证码时，需再次进行手机号是否已经注册的校验：
通过这样的流程优化，可以达到降本增效的目的。
降本：降低成本。优化后的流程，当用户看到手机号已注册后，就不会继续往下输入，降低了用户输入后续信息的时间成本；手机号已注册不发送验证码，减少短信费用，降低平台的经济成本。
增效：增加效率。优化后的流程，当用户输入手机号之后，如果手机号已注册，用户就可以马上转去登录，提前中断没有必要继续往下进行的注册流程，缩短整个操作的时间，提升操作效率。
一个流程如果太长，我们在规划流程的时候，需要注意跳出流程的节点。
比如上述注册流程图，我们可以像下方这样，发现手机号不是11位数字之后，仍然往下走，等所有判断条件执行完之后，将所有的错误信息一次性报给用户：
这种方式对用户来说体验是比较好的，可以一次性知道所有错误并修正，但有时候我们的系统流程很长，每一步都需要做大量的判断，耗费大量的时间，那我们会采用另外一种方式，就是提前中断，跳出流程，如下，当判断到用户的手机号已经不是11位数字，就不再往下判断，直接报出错误提示：
优化后让流程变得更加简单，但也意味着绘制的流程图会更加复杂，因为要考虑更多的流程场景，因此，优化流程才是真正考验产品经理功底的工作。
我们再来看看上述的考勤流程可以怎么进行优化。
我们仔细分析一下，就会发现考勤的流程还涉及其他的场景。
第一种场景：提交请假申请的人本身就是部门负责人，在系统中没有直属的上级主管。这种场景下，如果一个人本身就是上级主管，那么提交之后，上级主管这一级就默认审批通过，直接提交给人事经理审批：
第二种场景：假设人事经理的直属上级是总经理，人事经理请假的时候，流程怎么走？这种场景流程其实没有变，只是出现了特殊的情况，就是请假人刚好是审批人，同时上级是直接审批人，又是最终审批人，这种情况下，我们还是按流程来走，只是遇到相同审批人的时候，默认审批通过即可：
实际上流程一个都没少，只是因为角色重叠，所以两个角色完成了4个角色的流程。虽然流程简化，审批自动通过，但在设计系统的时候，即使是自动通过的审批节点，在系统中也需要进行记录。
最后我想说，在做产品设计时，不要滥用流程图，不要什么逻辑一上来就画流程图，有些逻辑很简单，一两句话就能说明白，就没必要画流程图，流程图看多了，也容易疲劳。
*本文示例流程图均进行一定程度简化，仅为说明原理，不代表实际业务，请注意分辨。