产品经理常用的图表类型，以及图表的使用场景。

背景：

初级产品经理在接到需求时，不能用文字表达抽象概念，而是需要使用一些计算机术语（人人都懂的术语或图表），通过图形和图表来描述抽象概念。. 下面，我们将讲解产品经理常用的图表类型以及图表的使用场景。

一、ER 图

ER（实体关系）图是描述实体之间关系的经典图。它是由科学家 Peter Chen 于 1976 年发明的，最初用于关系数据库。

ER图是产品经理在工作中经常处理的图。有很多方法可以呈现 ER 图。最常用的是在UML中使用类图指定的符号标记规范进行描述和描述。使成为。

以下所有示例均通过 Process On 工具进行操作。

在ER图中，每个大框代表一个对象，框内第一行描述对象的名称，第二行描述对象中的数据字段，大框与大框的连接，表示关系实体之间。如果新手产品经理不明白什么是“关系”，可以看之前的文档

多对一关系ER图示例：

两个ER图用实线连接，实线标注N:1，表示多对一关系，即多个学生对应一个教室。

如下图所示，是一一对应的ER图，意思是一个公民必须对应一张身份证，一张身份证也对应一个公民。

一对一关系ER图

1. 使用场景

在产品设计的初期，我们必须考虑这些实体类型之间的关系。如果你现在正在构建的产品经常存在逻辑混乱和功能重复的问题，那么在后期分解需求之后，你可以从分析ER图开始。另外，产品经理在输出PRD文档时，如果使用文字和图表，也不能很好的体现需求中的实体关系。这时候，我们可以考虑用ER图来表示。

通常产品经理只要掌握一对一关系、一对多关系、多对多关系，就能解决我们工作中遇到的大部分实体问题。

2. 流程图

国际标准组织ISO（International Standard Organization）于1970年定义了流程图的基本符号规则，方便不同背景的读者阅读和理解。建议尽量使用简单的绘制规则。用于绘制流程图的符号。

(1）流程图的符号要求

流程图看起来很容易画，但是画一个标准的流程图需要一些练习。下图介绍了绘制流程图的一些具体符号。我们必须清楚地记住每个符号。意思是，绘制流程图时不要犯错误。

以下是一些重要且最常用的符号，请牢记！

(2）流程图的三种结构

流程图由顺序结构、选择结构和循环结构三种结构组成，构成了流程执行的全过程。

① 序列结构

在顺序结构中，每一步都是按顺序执行的，是最简单的基本结构。如图所示，A、B、C是三个连续的步骤，依次执行，即完成上一个框指定的操作后，才能进行下一个动作。

② 选择结构

选择结构也称为分支结构。选择结构用于判断一个给定的条件，根据判断的结果判断一些条件，根据判断的结果控制程序的流程。判断流程可以有

③ 循环结构

循环结构，也称为重复结构，是一个进程在一定条件下重复执行某项操作的进程结构。循环结构可以分为when结构（when）和until结构（while）。

when-type结构：这个结构可以理解为判断给定条件p是否成立，当P成立时，执行A（step）；然后判断条件p是否成立；当P成立时，再次执行A，如果如此重复，当条件p不成立时，就跳出循环。

until型结构：首先执行过程A，然后判断给定条件P是否成立。如果p不成立，则再次执行A，以此类推，直到P成立，循环过程结束。

流程图是产品经理必须掌握的一种图表。当产品经理得到一个涉及跨模块、跨部门、跨角色协作的需求时，他们会用流程图来描述业务流程和用户的操作流程。真正的原型应该简单明了。如下图所示，可以清楚地描述每个角色以及过程中应该做什么。

3. 状态机图

初级产品面对业务流程，会用文字来描述状态之间的流转，比如订单的开始状态计算器上的c怎么用，到订单的确认状态，再到订单的结束状态。这个描述很难理解。，我们需要通过状态机图向各位朋友介绍各种状态。状态机图，也称为有限状态机图，是描述所有状态以及状态之间的流动规则的图。

Source State：受转换影响的状态；如果对象处于源状态，则当对象接收到转换的触发事件并且满足保护条件（如果有）时，可以触发传出转换。

目标状态：转换完成后激活。

在软件设计领域，“状态”在业务系统中无处不在：订单要有状态，账户要有状态，店铺要有状态。可以说，任何物体都有状态。状态机要注意以下几点：

状态值是有限集。状态的所有枚举值必须涵盖所有实际可能的情况。状态值必须是互斥的，不能有歧义。为了更准确地描述状态，状态还可以有子状态，比如订单。“Cancelled”，对应的子状态是“Customer Cancelled”，“Merchant Cancelled”，“System Cancelled”状态应该能持续一段时间，而不是很快就会结束的短暂状态，比如订单的状态可以是“Pending Ship”、“Pending Evaluation”，但不能是“Shipment” – 可以等待 xxx 发货，“Evaluating” – 可以等待 xxxx 评估。二、使用场景

当产品经理收到需求时，一个实例可以承载多个操作，并且有多个状态，那么prd文档必须包含状态机图，否则prd文档很难描述清楚实体之间的状态相关。

下图中的状态机图描述了一个订单完成时的review、pending execution、中间状态、状态流。使用状态机图比使用文字更简单、更清晰。

三、用例图

它是用户与系统之间交互的最简单表示，显示了用户与与他相关的用例之间的关系。通过用例图，人们可以获得系统的不同类型的用户和用例，简单来说就是一个角色或用户。在不同的场景下，能做什么，在实际工作中，我们会用到简单的用例图，也有复杂的用例图，很少接触。

虽然用例本身涉及很多细节和可能性，但用例图提供了系统的高级概述。它提供了“系统做什么”的简化图形表示，因此被称为“构建系统的蓝图”。

由于其简单而纯粹的性质，用例图是项目参与者之间交流的绝佳工具。用例图是对现实世界的描述，它允许项目参与者了解系统将要做什么。

1. 用例 – 用例是描述系统提供的服务的外部可见系统功能。用椭圆表示。

2. 子系统（Subsystem）——用来展示系统的一部分功能，这部分功能是密切相关的。

用例图中涉及的关系，如关联、泛化、包含、扩展等，这里不展开。有需要的可以去百度一下相应的资料。

使用场景：

产品经理使用用例图一般有两种场景。

首先是描述用户的行为。通常，我们会使用用例图来描述用户可以对模块进行的操作。

第二个是ER图。在描述实体的操作时，我们也使用用例图来描述实体可以支持的操作。

用户操作用例图

学生实体用例图

本文由@danny 发布，为做好产品原创，人人都是产品经理。禁止任何未经许可的复制。

题图来自pexels计算器上的c怎么用，基于CC0协议