在实际生活中，我们会碰到各种各样的流程。比如你去医院看病，你需要先去服务台领个具体要去看病的某个科室的小票，再前往挂号窗口将小票递给工作人员，缴完挂号费之后拿到挂号单，再前往具体科室去看病。各处都会有自己的流程，按照流程来走可以快速达到目的，减少不必要的麻烦，当然你也可以独辟蹊径，这就属于流程的优化。
什么是流程图？
定义
那什么是流程图呢？说文解字是一种了解定义的好方法。流程图=流程+图，如下图：
流程：是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程，流程是自然而然就存在的。但是它可以不规范，可以不固定，可以充满问题。所以就会造成看似没有流程。
图：是将基本固化有一定规律的流程进行显性化和书面化，从而有利于传播与沉淀、流程重组参考。
从定义可以看出，只要有事情和任务，流程就会有，但是并不是所有的流程都适合用流程图的方式去表现，适合用流程图去表现的流程是一定程度固定的有规律可循的，流程中的关键环节不会朝令夕改的。
流程图与其他图表的对比
工作中我们还用到或听到很多其他类型的图表，比如交互设计师们经常说的线框图(Wireframes)，信息架构图或站点地图(Site Map)，，开发工程师们经常说的用例图(Use Case)或E-R图。这些不同的图表要表达的内容有何种差异呢？简单做个对比，如图：
如果要串到某一个项目来说，可以理解成：
用例图（Use Case）：表现了一个角色在系统里要完成的活动是什么，比如用户这个角色与ATM取款机的交互过程中，用户需要完成的活动有存钱，取钱，查询等。而存钱这个活动再可以进一步细分为插卡，输入密码，输入金额，ATM吐钞，用户收款，退卡等活动。用例图可以不考虑用户动作的前后次序，而仅仅提取一些关键的动宾短语，映射出系统应该满足的功能点。常用用例图的人是产品经理和开发工程师。
流程图（Flow Chart）：则表示用户每一个活动的前后次序，比如用户必须要先插入银行卡，才能够输入密码，且流程图必须直接表现出各种异常判断，比如当密码错误时，出现什么提示，密码输入错误超过多少次时，出现什么提示和动作。常用流程图的人是产品经理，设计师，或者任何需要讲述业务如何运作的人。
信息架构图，站点地图(Site Map)：表现为了做一个这样的系统，功能与内容的展现层次是什么，比如用户一进去后，欢迎页面的导航如何设计，是否直接出现取款，存款，查询，或者还有别的导航？常用信息架构图的是设计师。但是常用组织架构图的是HR。
线框图（Wireframe）：将具体每个界面的内容布局和权重表达出来，且标注出一些交互细节的设计，比如当密码错误后，如何提示下一步动作。常用线框图的人是设计师。
实体关系图（E-R图）：则是数据库架构的工作，表示一个业务系统或场景中的实体时间的关系，比如储户与银行卡的关系是归属1对多，通过开卡事件产生关联。一般来讲，用矩形来表示实体，椭圆标识这个实体的属性，比如储户这个实体的属性有：姓，名，手机号码，住址等。而银行卡的属性有：开户行，开户名称，银行卡号等。
以上的这些图表各自都有领域的专家，我这里就不班门弄斧了。
那么流程图要体现出他的差异定义，要素是什么？总结出了流程图的6大要素，希望大家能够记住，这6个要素可以在以后的文章里不断回顾，你也可以拿来判断你所看到的流程图是否专业。
- 参与者：谁在这个流程中？可以是系统，可以是个打印机，更多的指什么角色——一般是有某种工种的人。比如客服同时有小A和小B两人，但是若他们的工作性质完全一样，那么在流程图里只需要写一个客服角色就可以了。
- 活动：做了什么事，比如点餐，结帐等活动。
- 次序：这些事情发生的前后顺序如何，哪个任务是其他任务的前置条件？比如客人不结帐，就不会产生送他优惠卡的活动。
- 输入：每项活动开始取决于什么样的输入物或数据，比如做饭的师傅开始做菜时，需要拿到具体的点菜单。
- 输出：每项活动结束后，会输入什么样的文档或数据传递给下一方，比如师傅做好菜后，如何让负责传菜的人知道菜已经做好？
- 标准化：采用一套标准化的符号用以传递你的流程图，从而使受众更快明白。
关于流程图的标准化，并不是强制的，事实上，我们见过很多种类的流程图，只要能够传递明白任务和次序其实已经归类于流程图了
流程图的分类
常见的流程图有 业务流程图 ， 页面流程图 。
在工作中，可能会发现经常谈的是业务流程，而作为交互设计师，他们更多产出的是页面流程图。页面流程图和业务流程图到底有什么关系呢？ 先有谁，其次再有谁呢？
先讲个故事：假设你的梦想是开个中高档的全国连锁餐馆，那么首先你想到的应该不是如何去选址，而是将为何要开连锁餐馆这件事情，以及你的定位，核心竞争力想清楚。是快餐，还是点餐，是连锁还是加盟？定位于社区还是繁华商圈？是川菜还是江浙海鲜？是面向中老年还是年轻人？是家庭主题还是动漫主题？竞争对手是谁？需要什么样的投资？可能的风险是什么？这些都想清楚了，问题都有答案了，所谓战略层要清晰了吧。然后假设你现在分析来分析去，与主要投资方决定了一个方向：面向年轻人的时尚动漫茶餐厅，连锁，但是先在厦门开始第一家，选址定位于年轻人约会，扫街的地域，比如风景区，著名商圈，电影院旁……那么，接下来呢？
接下来就是想办法让这些实现吧？那么需要做什么事情呢？选址？拉投资？搞装修？选餐饮菜单？雇佣员工？每一步怎么去做，时间点是什么？等等的任务拆解以及计划，就需要到战术层了。
这些事情的执行，总是需要请人的吧？先是核心团队分工去部署各项建设任务，当餐厅开设起来后，就需要组织稳定的运营团队，如服务、卫生、厨房、采购、人事等等，厨房里面还得分工，白案，热菜，冷菜等等吧？每个部门需要设置管理层以及汇报关系吧？所以你的组织结构就诞生了。
那具体每种角色是如何顺畅合作完成日常稳定的以及突发的各项任务呢？比如，当顾客上门时，谁去引导客人入座，谁去点菜，怎么将点菜的讯息迅速传递到厨房，并分发到酒水间、冷菜间、热菜间？并保证客人尽快能够吃到所点的菜？你必须要考虑各种人员的协作流程，优化效率，所以业务流程就出现了。
人肉运营了一段时间，没有借助任何点餐系统，你发现也还可以。客人点菜时，服务员手抄写下客人的要求，因为有复印纸，所以服务员能够将副本送入厨房，同时写下餐桌号码。厨房规模较小，负责分配任务的员工看下菜单，分别往冷菜处的黑板上写下需要他们处理的，以及跑到热菜区的黑板上写下待处理的菜品，以及去酒水间报下品名即可。可是随着经营的扩大，以上的人肉方式出现了很多问题，首先，手抄效率太低，顾客频繁换菜，响应来不及，手抄出错，导致经常报错菜。厨房很混乱，不得不多招了几个人专门跑堂。而一旦顾客要加菜，撤菜就更麻烦了，需要找出他们当时点的菜，再进行人工的批注和修改，同时要修改厨房后端的各个黑板……
所以你们想要开发一套智能系统，取代很多人肉工作，你们请了系统开发团队，他们经过评估，判断从点菜开始，一直到传菜都可以用系统解决。手持终端，能够快速传递顾客点菜需求到打印机，打印系统能够根据顾客点菜的类型进行自动的分单打印，所以热菜间看到自己的热菜菜单，冷菜间看到自己的冷菜菜单，而酒水间看到酒店菜单。当他们准备完毕后，送出，传菜员可以根据菜名与打印出来的单据进行传菜并根据顾客的点菜小票进行核对。这套系统同时必须配备结算系统，将最终确认掉的菜单及消费价格传递到结算前台，收银员能够快速进行操作。
这套系统最终是需要展现出来的，那么手持终端的界面如何设计？服务员能够用更少的点击完成一个菜的点餐吗？结算中心的界面如何设计？
通过以上的故事，是不是更明白从战略、战术、业务流程图到页面流程图的关系了？总结下：
- 先是有一个业务需求和业务目标，也即我们的愿景是什么？（战略）
- 然后就诞生了我们需要分解出什么样的任务，如何执行战术？（战术）
- 然后就诞生了需要架构什么部门，岗位去分工协作？（组织架构）
- 然后就诞生了不同的部门在协作完成某件任务时的业务流程？（业务流程）
- 业务流程基本稳定后，往往会考虑优化效率，所以会诞生出系统来支持流程，减少人肉环节，促进数据采集（系统愿景）
- 为了设计这个系统，PD需要思考什么功能能够取代某个环节的人肉工作（功能需求，系统流程）
- 不管是怎么样的功能最终都会以界面的方式呈现，设计师们会关注用户在系统里的任务流，行为路径，让用户完成任务更加高效愉悦。（页面流程）
当然，除了业务流程，系统流程，页面流程，还有数据流程被人关注。
我们平时工作中，还会经常听人谈到泳道图、任务流程图等等概念，究竟是神马关系呢？
在工作中，我们经常能够看到两种业务流程图，从表现形式来看，一种很好区分，俗称为“泳道图”的它，在样子上也确实像个泳道，可以有横向的泳道，也会有纵向的泳道。泳道图在某些文档里会被称为“以活动为单位的流程图”，浮在泳道中的都是一个个活动。
另外一种类型是以部门和岗位为单位的流程图，下图中的圆形就代表一个个部门或岗位。矩形代表活动。这种流程图关注事情如何完成的逻辑，但是在体现各个部门的责任上比较弱。如果是某个岗位的人来看，很难像泳道图那样一眼就能看到自己部门的职责和任务。所以现在用得比较少。
再回过头来说泳道图，泳道图有几个关键点：两大维度，活动流转，流程要素。
业务流程图是什么？
业务流程图，顾名思义，用来描述业务流程的一种图，通过一些特定的符号和连线来表示具体某个业务的实际处理步骤和过程，详细地描述任务的流程走向，一般没有数据的概念。
为什么需要业务流程图？
分析业务流程，并将业务流程图表化可以帮助分析者了解业务如何运转，帮助分析者找到业务流程中不合理的流向。现有产品存在的业务流程未必是合理的，通过业务流程图，钻研关键事件的流程，分析为什么要这么做，探索出更深层次的问题，从而对现有不合理的业务流程进行重组优化，进而制定优化方案，改进现有流程。
产品在写需求文档时主要是对业务规则的描述，而配合以业务流程图可以让业务逻辑更清晰；日常梳理关键事件业务流程时，画出业务流程图可以帮助发现不合理流程，从而对关键事件进行优化。
业务流程图的两种图表类型
管理业务流程图
我们现在所说的流程图其实是传统的管理业务流程图，包含基本流程图和跨职能流程图（泳道图）两种。以医院挂号流程为例。
基本流程图虽然明确地说明了整个流程，但却无法清楚地说明每步流程是由哪个角色负责的。为了有效表示各个流程是由谁来负责的，可以通过泳道流程图来实现，这样不仅体现了整个活动控制流，还能清楚知道各个角色在流程中所承担的责任。
管理业务流程图已基本能满足业务流程走向的表达，但在复杂的系统交互中，表达并发概念时，传统的管理业务流程图已无法表达，这就需要用到UML建模。
UML活动图
UML中共定义了13种图，如下，其中用例图、活动图和顺序图用的比较多。
UML细分了各种图，分别在不同的角度来描述系统流程，在本质上，UML各种图均属于流程图。
其中UML中活动图同管理业务流程图类似可用于表示业务过程，唯一的区别是活动图支持并行行为。传统的流程图着重描述处理过程，它的主要控制结构是顺序、分支和循环，各个处理过程之间有严格的顺序和时间关系；而UML活动图描述的是对象活动的顺序关系所遵循的规则，它着重表现的是系统的行为，而非系统的处理过程。
{cat\_tips\_A}那UML活动图是如何来表示并发业务流程的呢？{/cat\_tips\_A}
UML活动图也可包含为基本活动图和泳道活动图，表达的方式与管理业务流程图差不多，但图例上稍有不同（图例区别可参考下方）。
同管理业务流程图一样，泳道让流程中个角色的分工一目了然。一个泳道表示流程内的一个角色，泳道内仅仅画出该泳道所表示角色完成的活动（判断，并行等可以画在任意泳道）。
总结：管理业务流程图或UML活动图均可以用来表达业务流程，具体使用哪种图来表达业务流程可以凭君喜好，但要遵循一定的符号结构，不要混搭。不过要表达并行行为的还是使用UML活动图吧。
两种流程图图例和结构
管理业务流程图
管理业务流程图的常用符号如下，其基本结构包含：顺序结构、选择（分支）结构、循环结构。
UML活动图
UML活动图的常用符号如下，其基本结构除了顺序结构、选择（分支）结构和循环结构外，还可能存在并发的事件流。在UML中，可以采用一个同步线来说明这些并行控制流的分岔和汇合。
同步线：分岔是有一个进入转换，两个或多个离开转换；而汇合则是两个或多个进入转换，一个离开转换。
如何绘制流程图？
在开始绘制业务流程图之前需要先想清楚的2个问题
所要描述的是哪一段业务流程？
在画流程图之前先确定业务流程起终点，是截取某一段业务进行详细描述，还是整体业务模块进行描述。不可能将所有的流程都放到一个图里展示，也不可能大而笼统不画出关键事件，要学会划分业务流程范围，把握粒度。
{cat\_tips\_E}举例{/cat\_tips\_E}
还是以医院挂号看病为例，先挂号再看病。整个流程下来其实可以细分为两个流程，分别为挂号流程和看病流程；甚至粒度可以再细点，分为取小票流程、挂号流程、缴挂号费流程、排队看病流程等，但很明显，单独分析取小票流程和缴挂号费流程粒度过小，没有实际意义。
总结：可采用自顶向下，逐层分解的绘制方法。明确你要梳理的业务流程范围，首先列出流程中的关键事件，如医院挂号看病，挂号流程和看病流程便算是整个流程中的关键事件流程；再结合你分析的目的来判断是否需要再往下层进行分解，如取小票流程、挂号流程、缴挂号费流程、排队看病流程。如此例，层层向下分解，直到符合你要分析的目的，当目的是为了对某个业务流程进行优化时，则分解到对应流程即可，绘制出流程图后再进行分析。
所要描述的业务流程是否涉及到参与者？
涉及到参与者的业务流程使用泳道图来描述更简单明了。
{cat\_tips\_E}举例{/cat\_tips\_E}
业务简要描述：数学老师让小丽帮忙把讲台上的写了名字的语文课本送给语文老师，语文老师接下后微笑着对小丽说谢谢。
分析：包含了数学老师、小丽、语文老师这三个参与者，此时用泳道流程图更合适。
问题想明白了之后便可以对业务流程进行梳理，进而分解各个要素
业务流程图有4个关键要素：执行操作、顺序、输入输出、规则；要更清楚的描述业务流程可以有参与者这一要素。
- 执行操作：执行了什么操作
- 顺序：操作产生的顺序
- 输入输出：发生操作的原因和结果
- 规则：操作产生的条件
- 参与者：谁参与了这个流程，可以是系统、可以是页面，也可以是用户
以上个例子为例进行分解：
业务简要描述：数学老师让小丽帮忙把讲台上的写了名字的语文课本送给语文老师，语文老师接下后微笑着对小丽说谢谢。
- 执行操作和顺序（含输入输出）：请求帮忙、接受帮忙、拿讲台上的语文课本、递交课本、接收课本、道谢
- 规则：必须是写了名字的语文课本
- 参与者：数学老师、小丽、语文老师
以上是明确给出了业务描述，按照步骤基本上便能画出业务流程图。在没有明确给出业务描述的情况下，对业务流程的梳理主要有两种方式：
- 深入现场调查，由工作人员介绍业务处理过程。
- 对现有业务流程的优化。当已经对现有业务流程熟悉时，通过讨论和分析，可梳理出业务流程，再通过优化现有流程中不合理的地方，从而给出一个更好的流程来。
流程图规范
- 各图形形状/字号统一。如果各个图形形状大小/字号相差悬殊，这对于理解图形的人也是一种折磨，对于某个比较重要的流程可以使用颜色来区分其他普通流程（但颜色数量和种类不应太多，以免重点模糊），再在该重要的流程旁加上注释说明，就能将重点转达给对方。
- 流程名用动宾结构，如输入手机号。
- 流程均以开始框开始，以结束框结束。
- 流程图从左到右、从上到下排列。
- 流程线尽量不要交叉。
常见的绘制流程图的工具
在线工具
客户端
- Microsoft Visio
- edraw亿图
- xmind
- omniGraffle（mac）
- StarUML
具体用哪种工具不重要，重要的是学会对业务流程进行梳理并将流程可视化
