流程图是产品经理传达需求的常用做法，按照我的经验来看三大类：业务流程、页面流程、功能流程。分别对应着战略、战术、执行三大层次。
记得刚开始做PD的时候，没有意识去画流程图来梳理整个产品的脉络。经常需要修改原型。后来慢慢被迫培养了先画整体的业务流程，然后将具体的业务抽象成一个个功能模块，最后用形象化的页面承载功能的工作方式。
下面来讲讲我使用流程的实际案例，希望能够给大家一些启发，无需深究其中的业务，主要看其中的思路。
业务流程
体现Boss对整个产品的战略思想。产品经理根据老板的传达以及自身对产品的理解，梳理出整个产品核心业务的走向，生成业务流程图。
页面流程
体现PD对核心业务的高度理解。把核心业务的每一个节点抽象成一张张页面图，用页面跳转体现节点关系，生成页面流程图。
功能流程
体现每个功能模块的操作路径。每个核心功能都应该独立化。先用解耦的思想来最小化每个核心功能，然后用流程梳理清楚每一个操作。额，大部分功能模块都是和商城购物相关的。具体如下：
1.订单状态流转
2.优惠券领取
3. h5活动制作
4. 项目开发
5. PD到UI配合
总结
按照这样的思路来梳理产品的整体脉络，会慢慢从表象的视觉层到抽象的结构层，不仅PD自己对产品越来越理解深刻，同时研发RD也会更容易理解需求。
一、如何正确画出功能结构图？
对于PM来说，梳理完产品的整体架构，简单的功能用线框图即可，复杂的功能应该怎么办呢？
这时候，初级PM的做法是一个页面一个页面往下画，一个控件一个控件的抠细节。然后画到一半有问题，再一个页面一个页面往回修改。
（以前趟过的坑）
从时间来看，反复修改十几遍，浪费时间和精力。
从沟通来看，技术会因为一次性做这么复杂的功能，怼你们。
从结果来看，大家看到的是一个细节很完美整体复杂混乱的功能。
为什么需要功能结构图
碰到上述情况的时候，首先你应该整体分析一下这个功能，画出详情的内部结构，然后和前端工程师过一遍需求。让大家清楚这个功能由及部分组成。每部分是什么，以及各有什么作用。
最后根据公司的需求，是做完这些功能重要，还是某个时间点上线重要。来综合考虑是做完整个功能还是只做这个功能的子功能。
这就是功能结构图的由来。
功能结构图是什么
功能结构图是用来表示复杂功能的内部结构，包含了哪些子功能。
设计特性
最好设计成独立的模块，和其他功能尽量不存在关联。
注意是功能内部结构，不要误认为是功能间的关系。（功能间的关系是功能流程图）
如何画功能结构图
以电商app的下单功能为例，来讲一下如何画功能结构图。
1. 分析功能结构
当我们接到这样一个需求的时候，脑子中想到的是我们在京东淘宝等电商平台的下单步骤，很容易就想到至少要这样做。
然后这时候就直接去画页面，或者去抄袭竞品来设计原型。
2. 避免步骤页面化
有3个步骤，那就画3个页面好了。
简单的“步骤=页面”，只是偷懒的做法。
比如提交订单可以只是一个提交按钮，选择商品可以有多种方式，可能会涉及到多个页面。
3. 避免功能竞品化
貌似竞品淘宝有现成的，全部照抄一遍就好了。
事实上你们可能不是电商平台，商品也没有不同的sku。
细化功能粒度
根据自身业务，将下单功能拆分到更细的粒度。
详见订单结构，可以结合订单物理结构、订单逻辑结构、订单金额结构一起阅读。
如果你愿意按照这种思路去拆分，可以避免把步骤当作页面去画了。
再对照自己的业务是不是也需要用购物车，是否也需要有优惠券。如果是刚刚上线的，这两个功能完全没有必要设计。
4. 控制细分粒度
没必要无限制地区细分粒度，一般2到3层就够了。比如一般的下单功能架构图。
不是不可以，而是一般的情况下没必要耗费太多的精力。但如果需要拆分最底交易系统架构的时候，是有必要的。有兴趣的朋友可以看看淘宝产品十年事或者有赞订单系统的拆分。
使用axure画
建议使用axure的流程图功能来画，因为还支持跳转到对应的前端线框图，方便阅读。
矩形框
表示子功能，子子功能。
有向箭头
表示子功能间的关系
虚线框
用来表示这部分属于哪个子功能
二、如何正确的画出功能流程图？
这就是我理解的产品架构三部曲：
常见的错误画法
先梳理一下大部分PM画功能流程的常见错误，方便理解其边界。
1.混入业务维度
特别容易把业务模块也画到功能流程图里面。
区分你的功能流程图里面有木有业务模块并不难。唯一的判断标准是该图中的每个节点都应该是这个产品中真实存在的功能名称，否则应该是混入了其他东西。
真正的难点在于如何将业务流程映射成合理的功能流程，以及功能流程如何映射成恰当的业务
流程。
2.混入页面维度
其次容易将页面写到功能流程图里面。你如某个页面只是某个功能的子集，你非要把它写到功能流程图里面，是不合适的。
比如微信里面，发送照片给好友是一个功能，但是涉及到的页面“照片"、“选择相册”、“某一相册详情”以及操作“选中某一照片”，他们都不是功能，完全不应该显示在功能流程图里。
当然有些功能的命名，有可能和页面是一样的。
3.混入操作维度
每个功能可能包含很多操作，比如微信中发送照片给好友，包含了“点击相册”、“滚动照片列表”、“选择照片并发送”等操作。需要正确区分操作不是功能。
功能流程是什么？
讲了一些常见的错误画法之后，再次定义一下功能流程的概念。
功能流程是指产品的所有功能以及相互关系。
1.功能间关系
注意功能间是相互独立的，但是通过合理组合，可形成新功能。不太建议用一级功能、二级
功能，父功能子功能的叫法。
2.包含哪些元素
功能，使用矩形表示。
功能流向，使用有向箭头表示。
条件，使用有向箭头上的文字表示。
已定义流程，使用组合矩形表示。不是必须的，如果整个产品的功能太复杂，可能需要。
3.功能命名
要么是名词，比如购物车。可加定语，比如：我的红包。
要么是动宾短语，比如确认订单。
要么是通用叫法，比如：我的。
可以参考同行业的TOP5 竞品。
如果功能简单，产品层面的1个功能尽量对应着Axure的1个page页。如果很复杂，请拆分到多个页面。
4.功能定位
功能是逻辑意义上的概念，用户是感知到该产品具备哪些功能。一个功能可能是跨越多个页面，也可能存在于某个页面里。而页面是物理意义上的概念。用户可以在产品里看到包含哪些页面。
另外功能本身是相互独立的。但是通过合理组合，可形成新的功能。不太建议用一级功能、二级功能，父功能和子功能的说法。
如何画功能流程图
1.罗列所有功能
按照PM设定的用户使用产品流程，来画出每个节点的功能。从首次打开app开始算起，进入首页会有多种走向，均需分别画出来。
请注意不要随便把页面名称画出来，除非你确定含有一个同名的功能。
比如上图乍一看，好像这几个都是功能，画的好像并没有错。
可事实上，首页只是页面的叫法，而不是功能。另外它至少包含了发布邀请、查看邀约列表、频道列表三个功能。
2.用有向箭头关联
使用有向箭头将功能之间联系起来。注意箭头方向代表用户的使用步骤。
如果你是使用axure，请不要傻乎乎的使用默认模式拖一根线到功能矩形框上，而是切换到连接线模式然后鼠标移动到矩形框连接红点并关联到另外一个。
3.增加条件判断
很多功能是有前置条件的，请使用有向箭头并辅以文字表示。
所谓的条件就是前后端需要判断的逻辑。常见的条件有3种逻辑结构。
4. 检查是否犯错
上面说的几个常见错误，最好检查一下有没有犯。
5.得到功能流程图
根据上面的步骤，我大概画了一下微信客户端主要的功能流程图。
总结
如果你们的产品比较复杂的话，可能需要根据用户角色、前后端不同来分别画出对应的功能
流程图。
比如微信的功能流程图，至少用户使用微信，用户使用小程序，自媒体使用公众号，开发者开发公众号，开发者开发小程序等很多个。
简单来说，你得清楚你们的业务需要多少个产品来支持，产品间的关系是什么，每种产品需要多少种用户角色，相互间的关系，有多少个端。
三、如何正确的画出功能逻辑图
当我们需要设计任务型功能时，除了基础的线框图和交互，更需要提前搞清楚整个功能的内部逻辑流程，简称功能逻辑图。
举几个大家熟悉的任务型功能作为例子，方便大家理解概念。
比如电商的下单，大概包含查看商品→选择数量→填写收货地址→添加留言→付款。
其中的退货也是，选择商品→申请退货→填写退货信息→卖家审批→寄送商品→卖家确认物品无误→退款到账。
包括优惠券的使用，是生成订单前还是订单后都是有讲究的。
为什么需要功能逻辑图
当需要设计这样复杂步骤的功能，一定要学会画出内部的逻辑流程。
当然有时候也需要结合功能结构的思想，先拆分功能尽量少耦合，再画出内部逻辑。
然后和后端工程师过一遍逻辑，如果没有问题。再去设计具体的前端页面，最后才是专注于视觉细节。
如果没有先产出功能逻辑图，而是只画线框图和交互，那修改迭代的次数至少是上百次。
功能逻辑图是什么
表现功能内部的逻辑走向。可指导设计具体的页面和交互。
1. 功能逻辑图和功能结构图的区别
注意是功能内部的逻辑流程，不是误认为是拆分功能。
两种图形的使用场景是不一样的，分析功能的维度是不一样的。
一般来说先从业务上拆分功能到最细的粒度，然后再去画功能逻辑图。有时候最细粒度的功能很简单，逻辑图可不画。
多啰嗦一句，区分这2者也可以使用UML的用例思想来区分。
2.功能逻辑图和状态机的区别
通俗意义上的功能逻辑图表现是行为这个维度以及变化，而状态机是状态间的变化，维度是状态。
3. 功能逻辑图和UML时序图的区别
算是时序图的简易版吧，UML学起来有一定门槛。但是功能逻辑图很容易上手，只是欠缺一些uml的特性。
如何画功能逻辑图
继续以电商APP的下单功能为例来讲一下如何画下单这个功能的逻辑图。
因为这个功能实在是太复杂，不建议一次性画出逻辑流程。
然后按照子功能分别画出对应的功能逻辑图。注意这里只画了立即购买的下单功能，购物车结算的可以查看加入购物车，加载购物车，展示购物车，操作购物车。
1. 选择商品
2. 确认订单
3. 提交订单
功能逻辑图的元素
建议使用Axure来画，因为还支持跳转到对应的前端线框图，方便阅读。
1. 行为
使用矩形框表示，没可以区分用户行为和系统行为，uml时序图中有区分。
2.流程
使用有头表示行为的流程。
3.判断条件
使用菱形表示逻辑的多种路线。如果不复杂，可不用。
4.其他文字
用来辅助理解，可忽略。
总结
强调一下不要搞混功能逻辑图和功能结构图的运用场景。
我的建议是能拆分就拆分成功能结构，不能拆分就画功能逻辑。
四、如何正确的画出页面流程图
说到也main流程图，看似很简单。但是其实很多人画的不规范，不能清晰表达产品整体的页面架构。
页面流程图是什么？
页面流程图是指产品的所有页面以及相互间流向关系。
1.包含元素
页面，有向线条。
可能包含判断条件。
不包含具体内容。
不包含弹层、元件等视觉组件。
2. 页面命名
要么是名词，比如购物车。可加定语，比如我的红包。
要么是动宾短语，比如确认订单。
要么是通用叫法，比如我的。
可以参考同行业的top5竞品。
尽量保持和原型软件中页面结构的命名一致。
3.页面定位
每个页面尽量是一个完整独立的小功能。
除非功能太复杂，需要多个页面。此时页面的作用是功能的某一操作。
请结合上述的页面命名来考虑每一个页面该如何定位。
4. 维度只有一种
既然是页面流程图，那么研究维度只应该有页面。尤其不应该看到功能和业务。这个错误
很多PM都会犯。
延伸一点，每个产品至少有3大架构：业务流程、功能流程、页面流程。
页面流程的作用
之所以页面流程这个东西出现在产品经理的设计工作中，主要有以下原因。
1.了解全局
对于团队所有人来说，通过页面流程图可以大概了解整个app的情况，偏视觉层。
2.传达需求
对视觉设计师，知道要做多少视觉稿，具体每个页面都有哪些视觉元素。
对前端工程师，知道自己该写多少页面，搭建页面代码结构。
3.评估工作量
用页面数量来评估各自的工作量，可以大概估算出工期。
4. 梳理业务
页面流程是业务的直接体现，根据业务区反复研究它，可以让产品整体变得更简洁，结构变得更优美。
页面流程不能这样画
大部分初级PM画页面流程基本会犯两个错误。
1. 只能有页面这一维度
上面已经说了，再重申一下只应该出现页面这个维度，不应该有什么乱七八糟的业务、功能、甚至是组件、元件什么的。
2.不应展示具体内容
有些PM把页面的具体内容表示出来，其实很不对的。
抽象维度不一致，页面和页面内容是两个概念。
画页面内容需要耗费很长世间。
页面内容改动频率大，需要经常复查并修改。
具体内容有功能、有控件、有图标、有文字，很难抽象表述，以及表述完全。如果你这样画过，你就会理解这里的苦处。
以闪电约app来画一个错误的页面流程图，只画了几个页面。供大家参考。至少犯了以上1、
2、4错误。
页面流程图应该这样画
1.找出所有页面
不管你使用哪款原型软件，总有他的页面结构。据此画出所有的页面不难。
需要注意的是页面是物理层面的，真实存在。而不像业务流程图中的业务模块，只是逻辑层面
的，并不需要真实体现。
如果你是使用axure,可以直接拖动左方页面结构中的页面标题到右边的画布中即可。
2. 用有向线条关联
使用线条将2个页面联系起来，直到把所有的页面跳转加上为止。
如果你是使用axure，请不要傻乎乎的连接，而是使用连接线模式。
3. 增加条件判断
这一步不是必须的，但是稍微复杂一些的产品建议使用。
拿上面的错误图来说，首页和3个页面有关联，那什么情况下跳转到第一个页面呢。这个就是需要条件判断来说明。这一点平铺的UI视觉稿并不能体现这一点PM的价值。
其实，UI视觉稿的平铺图可以作为前端工程师定义代码层面的页面结构，属于物理结构。但是逻辑层面的页面结构必须辅以条件判断。
重新画一下上面的页面流程图，正确应该如下：
4.检查是否犯错
上面说的几个常见的错误，最好检查一下有没有犯。
总结
如果是使用axure来画页面流程的话，可以全选所有页面，然后右键一键生成流程图。
其实页面流程图还需要按照角色（用户、商家），端（客户端，服务端），有时候还需要按照版本来画，根据自身产品的复杂程度，按照此文方法画出即可。
五、如何正确的画出业务流程图
在实际生活中，我们会碰到各种各样的流程。比如你去医院看病，你需要先去服务台领个具体要去看病的某个科室的小票，再前往挂号窗口将小票递给工作人员，缴完挂号费之后拿到挂号单，再前往具体科室去看病。各处都会有自己的流程，按照流程来走可以快速达到目的，减少不必要的麻烦，当然你也可以独辟蹊径，这就属于流程的优化。
流程是为了达到特定的目标而进行的一系列有逻辑性的操作过程，它可以不规范、可以充满问题，但它确确实实存在着。只要有事情或任务，就会有流程的存在，将有一定规律的流程用图表表示出来可以让流程可视化，从而有利于流程的重组优化。
在工作中，我们常用到的流程图有：业务流程图、页面流程图和数据流程图。作为产品，经常谈的是业务流程图；作为交互设计师，则比较关心页面流程图；而作为系统分析师，数据流程图最关键。
PART1 业务流程图
围绕着以下几个问题来讲述业务流程图
什么是业务流程图？
为什么需要业务流程图？
业务流程图的两种图表类型
两种流程图图例和结构
如何绘制业务流程图？
常见的绘制流程图的工具
1.业务流程图是什么？
业务流程图，顾名思义，用来描述业务流程的一种图，通过一些特定的符号和连线来表示具体某个业务的实际处理步骤和过程，详细地描述任务的流程走向，一般没有数据的概念。
业务流程图是最常见的图表之一，能看懂读懂是必修课，能绘制便是非常重要的选修课。
2.为什么需要业务流程图？
分析业务流程，并将业务流程图表化可以帮助分析者了解业务如何运转，帮助分析者找到业务流程中不合理的流向。现有产品存在的业务流程未必是合理的，通过业务流程图，钻研关键事件的流程，分析为什么要这么做，探索出更深层次的问题，从而对现有不合理的业务流程进行重组优化，进而制定优化方案，改进现有流程。
产品在写需求文档时主要是对业务规则的描述，而配合以业务流程图可以让业务逻辑更清晰；日常梳理关键事件业务流程时，画出业务流程图可以帮助发现不合理流程，从而对关键事件进行优化。
3.业务流程图的两种图表类型
（1）管理业务流程图
我们现在所说的流程图其实是传统的管理业务流程图，包含基本流程图和跨职能流程图（泳道图）两种。以医院挂号流程为例。
基本流程图虽然明确地说明了整个流程，但却无法清楚地说明每步流程是由哪个角色负责的。为了有效表示各个流程是由谁来负责的，可以通过泳道流程图来实现，这样不仅体现了整个活动控制流，还能清楚知道各个角色在流程中所承担的责任。
管理业务流程图已基本能满足业务流程走向的表达，但在复杂的系统交互中，表达并发概念时，传统的管理业务流程图已无法表达，这就需要用到UML建模。
（2）UML活动图
UML中共定义了13种图，如下，其中用例图、活动图和顺序图用的比较多。
UML细分了各种图，分别在不同的角度来描述系统流程，在本质上，UML各种图均属于流程图。
其中UML中活动图同管理业务流程图类似可用于表示业务过程，唯一的区别是活动图支持并行行为。传统的流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理过程之间有严格的顺序和时间关系；而UML活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。
那UML活动图是如何来表示并发业务流程的呢？
UML活动图也可包含为基本活动图和泳道活动图，表达的方式与管理业务流程图差不多，但图例上稍有不同（图例区别可参考下方）。
同管理业务流程图一样，泳道让流程中个角色的分工一目了然。一个泳道表示流程内的一个角色，泳道内仅仅画出该泳道所表示角色完成的活动（判断，并行等可以画在任意泳道）。
总结：管理业务流程图或UML活动图均可以用来表达业务流程，具体使用哪种图来表达业务流程可以凭君喜好，但要遵循一定的符号结构，不要混搭。不过要表达并行行为的还是使用UML活动图吧。
4.两种流程图图例和结构
（1）管理业务流程图
管理业务流程图的常用符号如下，其基本结构包含：顺序结构、选择（分支）结构、循环结构。
（2）UML活动图
UML活动图的常用符号如下，其基本结构除了顺序结构、选择（分支）结构和循环结构外，还可能存在并发的事件流。在UML中，可以采用一个同步线来说明这些并行控制流的分岔和汇合。
同步线：分岔是有一个进入转换，两个或多个离开转换；而汇合则是两个或多个进入转换，一个离开转换。
5.如何绘制流程图？
（1）在开始绘制业务流程图之前需要先想清楚的2个问题：
1）所要描述的是哪一段业务流程？
在画流程图之前先确定业务流程起终点，是截取某一段业务进行详细描述，还是整体业务模块进行描述。不可能将所有的流程都放到一个图里展示，也不可能大而笼统不画出关键事件，要学会划分业务流程范围，把握粒度。
举例
还是以医院挂号看病为例，先挂号再看病。整个流程下来其实可以细分为两个流程，分别为挂号流程和看病流程；甚至粒度可以再细点，分为取小票流程、挂号流程、缴挂号费流程、排队看病流程等，但很明显，单独分析取小票流程和缴挂号费流程粒度过小，没有实际意义。
总结：可采用自顶向下，逐层分解的绘制方法。明确你要梳理的业务流程范围，首先列出流程中的关键事件，如医院挂号看病，挂号流程和看病流程便算是整个流程中的关键事件流程；再结合你分析的目的来判断是否需要再往下层进行分解，如取小票流程、挂号流程、缴挂号费流程、排队看病流程。如此例，层层向下分解，直到符合你要分析的目的，当目的是为了对某个业务流程进行优化时，则分解到对应流程即可，绘制出流程图后再进行分析。
2）所要描述的业务流程是否涉及到参与者？
涉及到参与者的业务流程使用泳道图来描述更简单明了。
举例
业务简要描述：数学老师让小丽帮忙把讲台上的写了名字的语文课本送给语文老师，语文老师接下后微笑着对小丽说谢谢。
分析：包含了数学老师、小丽、语文老师这三个参与者，此时用泳道流程图更合适。
（2）问题想明白了之后便可以对业务流程进行梳理，进而分解各个要素。
业务流程图有4个关键要素：执行操作、顺序、输入输出、规则；要更清楚的描述业务流程可以有参与者这一要素。
执行操作：执行了什么操作
顺序：操作产生的顺序
输入输出：发生操作的原因和结果
规则：操作产生的条件
参与者：谁参与了这个流程，可以是系统、可以是页面，也可以是用户
以上个例子为例进行分解：
业务简要描述：数学老师让小丽帮忙把讲台上的写了名字的语文课本送给语文老师，语文老师接下后微笑着对小丽说谢谢。
执行操作和顺序（含输入输出）：请求帮忙、接受帮忙、拿讲台上的语文课本、递交课本、接收课本、道谢
规则：必须是写了名字的语文课本
参与者：数学老师、小丽、语文老师
以上是明确给出了业务描述，按照步骤基本上便能画出业务流程图。在没有明确给出业务描述的情况下，对业务流程的梳理主要有两种方式：
1）深入现场调查，由工作人员介绍业务处理过程。
(2）对现有业务流程的优化。
当已经对现有业务流程熟悉时，通过讨论和分析，可梳理出业务流程，再通过优化现有流程中不合理的地方，从而给出一个更好的流程来。
（3）流程图规范
各图形形状/字号统一。如果各个图形形状大小/字号相差悬殊，这对于理解图形的人也是一种折磨，对于某个比较重要的流程可以使用颜色来区分其他普通流程（但颜色数量和种类不应太多，以免重点模糊），再在该重要的流程旁加上注释说明，就能将重点转达给对方。
流程名用动宾结构，如输入手机号。
流程均以开始框开始，以结束框结束。
流程图从左到右、从上到下排列。
流程线尽量不要交叉。
6.常见的绘制流程图的工具
（1）在线工具
ProcessOn
draw
（2）客户端
Microsoft Visio
edraw亿图
xmind
omniGraffle（mac）
StarUML
我一般常用ProcessOn画业务流程图，一些uml图也会使用StarUML，这两种工具画出来的图都挺赏心悦目。但具体用哪种工具不重要，重要的是学会对业务流程进行梳理并将流程可视化。
