- 本篇文章的主题主要是把我项目实践过程中涉及到的流程图做一个总结
引言：作为一个产品经理，我时常在思考这个世界本身是由无数的规则所组成，只不过有些是显性的规则，有些是隐形的规则；显性的规则人们从日常经验出发实用归纳法进行大胆的假设推理进行验证，变成这个世界运行的公理，隐性的规则当人们当下无法思考清楚一件事情的时候往往从另一种角度会得出事物的答案；我为什么要说这么一个故事，因为我觉得产品经理的日常工作其实本身也是一个构建规则的过程，就像法律是把规则写在宪法里面，产品经理把脑海里面的规则通过原型页面和流程图的方式表述。
今天我想给大家分享一下流程图，流程图其实是产品经理设计过程中非常重要的一环；不知道大家日常工作有没有遇到这样一个场景，当你辛辛苦苦的设计完一份交互原型和流程说明准备进入内部评审的时候。下面的开发人员他其实只是想着如何挑战你的设计，你兴致勃勃的在需求澄清会上介绍你的业务逻辑，开发同学其实根本不关心这些，他们通常会从一些异常流程和逆流程，场景闭环角度出发思考想着怎么来怼你：
1.比如你发起售后，那么拒绝之后呢，是否能重复发起，页面是否有逻辑说明；
2.你说app定位，现实场景用户网络中断缺省值页面怎么处理；
3.你说订单提交后台审核，这个时候后台商品编辑了，订单怎么处理。
相信我，当你面对一个十年以上的研发人员铁了心准备在会上干你，正确的做法两种要么，当初认怂，这个问题会后讨论，要么在设计页面之前有一份完整的逻辑思考过程。
- 下面进入正文，如何画好一幅流程图，本篇只讨论产品涉及流程图，涉及开发系统架构流程图不做讨论
- 首先介绍流程图各符号含义
- 产品设计过程中需要产出哪些流程图
- 各流程图举例
PS：有不对的地方欢迎指正
1. 流程图符号含义
矩形：一般用作要执行的处理（process），在程序流程图中做执行框
虚线矩形：代表状态图
圆角矩形：表示程序的开始或者结束，在程序流程图中用作为起始框或者结束框。
菱形：表示决策或判断（例如：If…Then…Else）,在程序流程图中，用作判别框。
倒梯形：表达为一个文件，可以是生成的文件，或者是调用的文件。如何定义，需要自己根据实际情况做解释
平行四边形：一般表示数据，或确定的数据处理。或者表示资料输入（Input）。
粗横线代表动作汇合，下一个动作是完成交易，但是必须收到货物和发票，没有先后顺序，用横线代表汇合；并行：随便一条链路完成只会用合并画法
2.一般产品涉及流程图
笔者一般做企业服务较多，按照项目进程：
2.1一般首先调研阶段首先产出业务蓝图，一般用PPT绘制
2.2场景链路图，类似于用户故事地图
2.3这个时候技术人员其实需要出一张零级视图，产品不要求设计，但是至少要求能看得懂
2.4根据各个业务场景设计业务流程图
业务流程图定义：是一种描述管理系统内各单位、人员之间的业务关系，作业顺序和管理信息流向的图表；整体上没有系统情况下纯手工也可以完成业务闭环，但是一般通过互联网就是端口/角色+系统逻辑
注意点：业务流程其实分为两部分，一部分是手工操作，还有一步分是系统处理逻辑，前者是人员操作岗位操作，后者是机器算法处理，很多同学只是画了手工操作部分，但是机器处理直接部分直接画到手工操作泳道图；
还有一些同学在设计业务流程的时候不区分状态和流程，系统状态其实在系统层可以表示出来，人工操作层尽量不展示状态（类似收到系统消息）非判断机制不做表现；这两个点是整个业务流程比较容易陷入的误区
业务流程图的基本元素：角色，端，页面编号，手工操作，阶段，系统处理
表述方式：某个角色， 什么时候，某个端，哪个页面 ，执行动作 ， 产生什么结果
image.png
2.5后续产出页面流程图，页面输入输出
2.6产出页面流程图之后理论上可以设计原型页面，可以补出线框图
2.7针对一些特殊模块，可以补充状态图,每个节点代表状态，横线代表动作
