流程驱动设计（Flow Driven Design，以下简称FDD），是指根据实际业务流程，设计产品流程，并以产品流程为驱动，设计产品架构、功能的方式。
大多B端产品的设计流程长且复杂，这种方式正好契合B端产品的特点，能够较好地帮助产品经理以流程为主线梳理B端业务逻辑，解决B端产品设计中遇到的问题，因此接受度高，使用范围广。

什么是流程

流程是指某一角色为了完成某一任务，有顺序地进行一系列操作的过程。这里的顺序可以是时间顺序、空间顺序、业务关联顺序等。

流程六要素

（1）参与者
流程中每个步骤的执行者，可以是一个系统或者一个角色，具体选取维度根据实际业务来定，而且不需要保证一个流程的所有参与者是同一维度中的，即一个流程中的执行者既可以是角色、也可以是系统。
（2）节点
流程中的每个步骤，参与者执行的动作。例如，填写申请、审批。
（3）顺序
节点的前后排列规则，一般是按时间的先后进行排列。例如，先由普通员工填写请假申请，再由部门领导审批。
基于每刻报销识别的一些流程细节，连续多级审批是一个人可自动跳过，驳回后修改再提交可跳到相应的节点。
（4）输入
除第一个节点外，每个节点在开始执行前都需要有输入的内容，输入的内容决定了这个节点将如何执行。例如，部门领导要执行审批动作，就需要有员工填写的申请单，这里的“申请单”就是领导“审批”的输入。
（5）输出
除最后一个节点外，每个节点结束后都会产生一个输出传递至下一节点，成为下一节点的输入。例如在普通员工“填写申请单”这一节点中，“申请单”就是这个节点的输出。
（6）标准化
绘制流程图时应该符合绘图规范，采用一套标准化的方式表达并传递输出信息。

基本结构

（1）顺序结构
顺序结构是简单的线性结构，各节点按指示顺序执行。
（2）分支（选择）结构
分支结构是对某个给定条件进行判断，条件为真或假时分别执行不同的节点动作。

（3）循环结构
循环结构是当流程中某一判断达到相应条件后，会反复执行某个动作，这个反复执行的动作又称循环体。
循环结构又可以分为当型循环和直到型循环。

• 当型循环，指在执行循环体前先进行条件判断，当条件满足时进入循环，否则结束循环的结构。
• 直到型循环，指先在执行了一次循环体之后，再对条件进行判断。当条件不满足时执行循环体，当条件满足时则停止执行循环体的结构。

分类

按不同分类维度，流程可分为多种类型。

• 主次维度。按流程的主次程度进行划分，流程可以分为核心流程、次要流程、异常流程。
• 功用维度。按流程的功用进行划分，流程可以分为业务流程、功能流程、操作流程、页面流程、数据流程、状态流程。

【PS：和UML联系起来】
（1）业务流程
业务流程是指用户为完成业务目标所需要的完整闭环流程，无论是线上执行的步骤还是线下执行的步骤，是自己执行的步骤还是他人执行的步骤，均包含在内。
（2）功能流程
功能流程是指用户利用产品完成某一任务的流程，它与业务流程的差异在于功能流程仅针对产品中流转的部分，不包含线下步骤和在其他关联系统内流转的步骤。
（3）页面流程
页面流程是指在功能流程基础上，用户利用产品完成某一项任务所需经过的页面，就组成了页面流程。
（4）操作流程
操作流程是指在页面流程基础上，用户利用产品完成某一项任务所需进行的操作步骤，就是操作流程。
（5）数据流程
数据流程是指产品在业务处理过程中，数据从输入到输出过程中所经历的流动、处理、存储，包括常见的前端数据和后端数据交互、关联系统对接时的数据流转等。
（6）状态流程
状态流程是指一个对象在随功能流程流转过程中发生状态变化的过程。

表现形式

【PS：和UML联系起来】
（1）基本流程图
按照流程图的基本规则，以图形化的形式，线性地展示流程中前后节点的顺序。
（2）跨职能流程图
跨职能流程图又称泳道图，是在基本流程图的基础上，将进程中各步骤按执行的职能单位（如角色）、系统或功能模块划分出一个个泳道，以便相关人员更直观地查看各职能角色在全流程中所起到的作用和对其他职能角色的影响。
（3）数据流程图
数据流程图是数据流程特有的一种表现形式，对于很多产品经理来说比较陌生，用得也较少。数据流程图的绘制规则与基本流程图的绘制规则也完全不同，产品经理需要对后台的数据处理机制非常了解才能绘制出来，因此一般由架构师或者后台开发人员负责绘制，产品经理能看懂就行。

（4）时序图
时序图与跨职能流程图类似，
横坐标按职能角色、系统、对象等划分出一条条生命线，纵坐标按时间顺序展示操作步骤和控制焦点。时序图既能展现业务流程，也能展现数据流程，是比较全面的一种表现方式，不过开发人员用得更多一些。

流程驱动设计实践

1）梳理业务流程

厘清头绪，找到一条或多条主线将这些需求、概念、规则串联起来。
用户体验地图梳理的其实就是业务流程。只不过用户体验地图梳理的是某个单一角色视角下的业务流程，并不完整，需要与其他有相同或强相关业务任务角色的体验地图融合，才能得到一条完整的业务流程。
对于以流程为主线的业务，为什么不在调研的时候直接用业务流程进行调研，而要以用户体验地图的形式进行调研呢？这里有以下两个原因。

• 调研时面向单一角色。在调研过程中，为了聚焦，也避免浪费他人时间，往往是一个一个进行的，而不是一次性把所有相关角色的代表都召集起来，一起进行调研，这样场面会非常混乱，效率也很低。
• 信息量不足。在没有充分调研需求的情况下，我们当时的已知信息不足以构建完整的业务流程，需要等调研结束，我们掌握了足够的信息后，在团队成员一起分析梳理、整合信息后才能构建。我们也不能指望业务代表在调研前能了解这么多的细节，这在B端业务中几乎是不可能的事，所以我们无法在调研前就得到一条完整的业务流程。

2）设计功能流程

梳理了主要业务流程后，再考虑如何将这些业务流程搬到线上，让整个流程在系统中也能流畅地运转起来。
由于实际业务场景比较复杂，不同节点可进行线上化的程度不同。有的节点适合全部搬到线上，而有的节点只能部分搬到线上，有的甚至完全无法纳入系统。
线上化遵循的原则：

• 保证线上流程的完整性。这是第一优先原则，无论选择哪些节点进行线上化操作，最后形成的线上流程一定要能够形成闭环。有些节点虽然经过分析不太适合线上化，但为了保证线上流程正常运转，仍然需要在线上增加相应功能。
• 发挥线上优势。任何一个产品都只是一个工具，并不能做所有事情，也不应该做所有事情。虽然通过系统能让很多工作更方便、快捷、自动化，但也有其不足之处。例如需要与人深度沟通的工作，就不是系统所擅长的了。
• 投入产出比合理。在前面两个原则都满足的前提下，我们还要考虑节点线上化的投入产出是否划算，有些价值不大，但需要投入较多资源的节点，需要评估前期是否可以先通过人工进行线下处理，以节省资源开发价值更大的节点。

  3）优化功能流程

  功能流程的优化主要从三个方面着手。
  （1）查漏及精简
  初步设计的功能流程会有很多不足之处，我们需要仔细检查节点是否有遗漏，每个节点执行的充分且必要条件（即输入）是否已具备。同时要与业务代表一起评估每个节点的必要性，很多时候看起来流程上只是增加了一个小节点，但在实施过程中其实会增加很多工作量，所以对于流程节点，依然要遵循“奥卡姆剃刀”原则。
  （2）划分泳道
  为了一目了然地知道各个参与者所需执行的节点，我们需要将基本流程图按参与者划分成一个个泳道，将他们各自的执行节点规整到各自的泳道中，避免混乱。
  在泳道图中，需要注意参与者不只是需求分析中明确的具体角色，还有其他关联方，如“考勤系统”，代表这个节点任务由考勤系统处理。
  （3）细化子流程
  对于一些比较复杂的流程，为了让流程图的可读性更强，减少干扰，我们需要把子流程拆分出来单独进行梳理。

  4）提炼功能模块

  细化了功能流程后，我们就可以结合前期调研的需求，提炼出产品所需的功能模块，根据与业务的相关性，功能模块可以分为主要功能模块和辅助功能模块两大类。
  （1）主要功能模块
  主要功能模块是与业务直接相关的功能模块。提炼这部分功能模块时，主要方法是找出流程、需求中涉及的管理实体，如员工、薪酬、考勤、组织架构等，然后在后面加上“管理”二字，变成“××管理”，如员工管理、薪酬管理、考勤管理等。提炼管理实体时要坚持相互独立，完全穷尽的原则，确保提炼出所有要管理的实体，同时不同管理模块不要出现重复管理的情况。
  （2）辅助功能模块
  只有核心功能模块，产品仍然无法正常运转，产品体验也存在缺陷，所以我们还要提炼辅助功能模块，以保证核心功能正常使用和提升产品体验。B端产品常用的辅助功能模块有：基础设置（为主要功能提供基础信息配置的地方）、工作台、帮助中心、消息中心等。

  5）设计产品结构

  将功能模块及其子栏目按层级关系设计出产品结构，并用脑图的形式展现出来。（信息结构）

  6）明确功能字段

  为了减少产品原型设计过程中出现因前期思考不够细致而反复修改的情况，我们可以在产品结构图的基础上进一步细化各个功能的具体字段。
  这样做的另外一个好处在于，遇到有一定IT基础的业务方，甚至可以直接拿这个脑图和他们确认需求，而不需要等设计完产品原型再去确认、修改，从而大幅提升双方沟通的效率。

  7）设计产品原型

  产品原型只是一个表现手段，无论你使用什么工具，通过原型整理思路，表达清楚需求才是重点，切莫本末倒置，把时间和精力过多的花在设计高保真产品原型和原型动效上。
  设计技能比较薄弱的产品经理，建议一方面学一些基础规范，如《简约交互四原则》、尼尔森十大交互原则；另一方面多看看商业化的SaaS产品，因为很多即使业务不同的B端产品在表现层面也是大同小异的，多看一些成熟的产品页面会给你很多启发。

流程驱动设计的不足

对于简单、核心业务流程较少的产品非常好用，产品经理掌握了这种方法，足以应对大多数产品设计。不过这种方式对复杂的、涉及多领域的产品则显得不太好用了，原因有以下几个。
1）复杂流程易混乱
以电商后台为例，无论是商品管理、仓储管理、物流管理还是订单管理，每部分的流程都非常冗长复杂，如果要从头到尾完整地梳理其业务流程，不仅对产品经理来说是个巨大挑战，而且经常会出现遗漏。另外，即使产品经理将业务流程梳理出来，最终得到的流程图的可读性也极差，让人一眼望去头皮发麻。
这个问题也不是简单地拆分子流程就可以解决的，因为我们设计的功能流程要想指导实际的产品设计，节点粒度就要足够细，甚至细到“点击某个按钮”，所以在复杂的业务流程中即使拆分了一些子流程，主流程依然会很复杂，依旧容易混乱。
2）模型不匹配
流程驱动设计是一种线性思维的设计方法，用开发人员的话说，这是一种“面向过程”的设计方式，而了解过后台开发的人员知道，现在的开发语言主要是一种“面向对象”的开发方式。这种差异就会导致产品经理基于流程设计的产品模型与开发人员所需要的开发模型不匹配的问题。
【PS：“面向过程”的设计；“面向对象”的开发；】
在产品设计初期，我们无法保证开发人员对业务的理解足够准确和深入，而如果理解偏差较大，开发模型设的计就会出错，后面要想修改将是伤筋动骨的。为了避免这种问题，我们最好能够理解开发人员的“面向对象”的开发方式，并为其提供准确、匹配的模型。
3）耦合度高
在设计B端产品架构时，有个非常重要的原则叫作“高内聚、低耦合”。
在B端产品设计中，由于业务复杂，架构师或后台开发同学很难准确、合理地基于这一原则设计后台架构，而业务方又不可能懂得这一原则，所以B端产品经理作为中间桥梁，就需要在进行产品设计时就遵从这一原则，让产品从业务角度做到“高内聚、低耦合”，这样才能让架构师或后台人员更准确合理地设计后台架构。

高内聚的意思是让同一业务领域的管理实体、功能尽可能地聚合在一起，做到相近的业务形成内部聚合。 低耦合的意思是不同业务领域的功能尽量减少交叉和重复，降低耦合度，做到不同业务的关联尽量少。

如果没有遵循“高内聚、低耦合”的原则，就会造成以下两大问题：业务难复用；维护成本高；
4）协同成本高
业务越复杂，开发团队就会越庞大，管理、协同成本也会越高。为了方便管理，公司就会按业务模块划分一个个小的开发团队，各自负责产品相应的部分，这样虽然提升了管理效率，但也造成了新的问题。

• 各个小团队无法形成对产品全貌的认识。
• 不同团队协同内容、方式、边界不清晰，难以按标准划分，容易疏忽遗漏。
• 由于很多信息无法及时获悉，比如同一名词的定义不同，增加了不同团队间的沟通成本。

领域驱动设计

为了解决上述流程驱动设计中的四大问题，需要找到一个能够化繁为简、设计的产品模型与开发模型匹配，同时又能降低业务模块耦合度、统一团队沟通用语的方法——领域驱动设计。 要理解领域驱动设计，可以先了解“微服务”。