随着互联网行业的兴起，产品经理这个工作岗位才逐渐进入了人们的视野。现在过年回家跟亲戚聊天，我说自己是做产品的，也有一两个亲戚会略知一二地点点头。不过，大多数人只是听说过这个岗位，你要让他说出这个工作具体是干什么的，就答不上来了。事实上，在面试的时候，有时候我会问想应聘产品岗位的萌新应届生，你觉得产品经理是做什么的？他们当中的许多人可能就是看了《人人都是产品经理》，或者是被各种乔布斯或张小龙的故事所感召，才想来试试看这个岗位。在面对这个问题时，基本上答得都比较片面。

这很正常，产品经理这种工作岗位，在不同公司、不同资历，甚至项目的不同阶段上，做的事情千差万别。而反观互联网公司里的其它岗位，其实已经高度的专业化和流水化了。设计输出设计稿，研发编写代码，运营推动用户增长与活跃……乍一看来，产品好像是这些专业分工里，唯一一个万金油的岗位。那么，产品到底在产出什么呢？

事实上，产品经理作为向上承接需求，向下推进实施的岗位，工作中很重要的一个职责，就是让团队所有成员理解一致，向着共同的目标走。比如，在承接需求时，产品其实是「翻译家」，把用户或业务方的想法，转化为实际的流程；在和研发沟通时，产品其实是「建筑师」，就像建筑师不会砌一砖一瓦一样，产品也不会写一行代码，但是要负责梳理清楚产品中的所有逻辑；而在项目进入开发阶段后，产品又像「监工」，要保证产品的开发上线进度与质量。所有这些工作，都需要产品和各个岗位的人有大量的沟通与交流。正所谓一图胜千言，为了提升沟通效率，这也练就了产品经理的一个共性：擅长画图。以至于我有时候会调侃，所谓产品经理，其实就是产「图」经理。

当然，这也只是描绘产品经理的一个片面视角，但我发现并没有很多人从这个角度来探讨过，因此就有了本文：产品经理的工作中，都需要画什么图呢？

脑图：整理思路

最基础的图，就是脑图（思维导图）了。脑图的应用范围非常广，少数派也有专门的付费教程，对应到产品的工作中，脑图可以用于新功能的头脑风暴，展现产品整体的功能框架，梳理某次产品迭代的具体功能点等等。这其中，我认为对产品经理，尤其是产品新人最有用的使用场景，还是将零散的思绪碎片，整理成为体系化的思路。

我常常会告诉产品新人，对于还未成型的东西，与其撰写一份 Word 文档，不如试着在脑图工具中呈现自己的想法。举个例子，这幅脑图展现的是社群运营的一个基础框架。你可以看到，其中涵盖了建群、拉群、群运营等方面的内容。从最终结果来看，它完全可以转写成一份标准的 Word 文档。然而，如果你考虑它的诞生过程，你会发现只有脑图能很好地完成这个工作。

.png)

所谓诞生过程，其实也是产品经理整理自己思路的一个过程。对于产品新手来说，往往很难在短时间内成体系地表达自己的想法，更多时候，脑海中飘浮着无数零散的、不成体系的想法。即使对于年资较深的产品经理来说，在工作时也会遇到自己不擅长或陌生的领域，一下子没有成熟的经验。例如在制作这幅社群运营的脑图时，对于没有经验的新人来说，可能最先想到的一些很零散的东西：群裂变、讲课促活跃、群托、引流公众号等等。

想像一下，如果这个过程是在 Word 文档中，或者哪怕是大纲工具里，你只是不停地留下一堆关键词。而脑图则完全不一样，许多人认为脑图最大的特点是发散性，在我看来并不全面，脑图的另一个重要优势是它定义了最小单元。每一个小格子浮在画板上，都是一个独立的个体，对应着零散的思绪。

这时候，我的做法就是会打开一个脑图，把脑海中的想法，先以关键词的形式，快速地倾倒在脑图中，不用考虑他们的层级或从属关系，只需要在画板上留下一个一个独立的小格子。之后，随着自己思考的深入，以及资料的查阅，再把所有倾倒出来的碎片，逐步由点连成线，整理他们的层级关系，把想法串联起来，形成一套体系化地思考。

原型策划图：产品经理的基本功

做原型策划图可以说是产品经理的基本功了。不同公司或不同的项目上，对原型策划图的期待与标准也不尽相同。有的大公司只需要产品经理出具最基本的线框图，会由专业的交互设计与 UI 设计在此基础上精进；有的公司产品其实也兼具了交互的属性，在策划时要一并考虑在内；还有的时候，特别是需要用于前期演示的项目时，产品经理甚至需要出具带动效和跳转的高保真原型图。

在我看来，无论是最简单的线框图，还是高保真的原型，要坚持的一个基本原则是：突出页面的重点。在大多数流程里，原型策划图的下一步都是交付给设计师，而设计师如果不能直接从页面上清晰地理解重点，那么就需要大量的口头沟通，这时候往往出多版设计稿也难以达到预期的效果。

要回答什么样的原型策划图有重点，不如先来看看反面案例。下图是最近我团队中一个产品新人做的策划。可以看到，页面上的元素，以一种让人不能理解的方式排列着，看着这样的原型策划图，你几乎很难想像出最终这个页面是长什么样子的。

其实，只需要遵循一些很小的原则，就能让你的原型策划图看起来不至于这么惨不忍睹。我总结了几个最关键的原则如下：

1. 字体的使用：如无特殊需要，使用无衬线体。同时一定要有大有小，重要的标题、版块名称使用大号字，必要时加粗。不重要的提示、说明文案，使用小字。除了大标题外，尽可能不要使用纯黑色的字，即 HEX 值是 000000 的颜色。一般来说，按文字的重要程度，依次使用 HEX 值是 333333，666666，999999，cccccc 的字体颜色就够了。

1. 操作与内容分离：页面上哪些只是显示的内容，哪些是可以操作点按的元素，应该有明显的区分。最简单的方法，就是任何可以点按操作的元素，都使用系统级的标准控件样式。

2. 布局有区分度：一个页面上，一般都会有多个区域或分布，这些区域之间，要不有着明显的间隔，要不应该有明显的留白，总之，让人一眼能够分辨出哪些元素是一个区域，哪些元素是另一个区域。

3. 元素间对齐：在页面元素的摆放上，一定要注意对齐。其实常见的对齐就三种：左对齐、右对齐、居中对齐。清晰的原型策略图，让人一眼就能看出页面间元素是如何对齐的，糟糕的策划图，就像上图一样，让人完全不知道对齐线在哪里。

4. 排版上重复：页面的复杂程度，有时候并不仅仅来源于页面上呈现内容的多少。如果能够统一成一种清晰的、可预见的风格，那么用户的理解成本也能大大地降低。例如，你很难想像，任何 Feeds 流产品，如果每一条内容都有一个新的样式，是多么让人崩溃的一件事情。因此，在排版上，最好在不同区域之间，重复使用同一种设计语言。

适当地添加图标与现有素材：在页面上添加图标，可以让人更直观地理解功能的意义。产品经理虽然不会亲自设计图标，但有许多网站提供了大量的现成图标，可以直接下载回来使用，例如 www.iconfont.cn 。另一方面，如果有一些 Banner 图、功能区域，你已经有一些现有的相关素材，也可以直接展示在页面上。

在遵循这几条简单的原则后，上面的原型策划图，经过不到半小时的优化，就已经可以变成这样了：

1. 字体的使用：文字由原先的宋体换成了黑体，并区分了字体大小、颜色与粗细。

2. 操作与内容分离：按钮变成了蓝底白字的统一样子，提醒开关使用了标准的 iOS 系统控件；

3. 布局有区分度：页面主要分为了四个区域，即体重记录区、饮食/运动建议区、Tips 区、Banner 图区；

4. 元素间对齐：例如，在 Tips 区，现在都是统一的左对齐了；

5. 排版上重复：例如，在 Tips 区，重复使用了图标+小标题作为第一行，小字说明作为第二行的版式；

6. 适当地添加图标与现有素材：顶部使用了系统的状态栏，右上角使用了微信小程序的胶囊按钮，页面上体重趋势和最底部的 Banner 图使用了现成的图片；

你可以看到，和最初的策划相比，两者想展示的内容和功能是一模一样的，但经过优化后的版本，虽然不尽完美，但多多少少已经让人看了之后，能理解页面上的核心重点，想像出大概的最终样子了。

用例图：确定与展示产品的功能边界

产品经理进阶的标志之一，就是承接的需求，从清晰确定的，逐渐变成模糊待定的。在这个过程中，需要产品经理不断推敲一个功能或模块的边界在哪里，哪些要做，哪些不做，哪些在这个版本中做，哪些可以之后做。

在这个过程里，很多时候就像是一场拉锯战。尤其是对于专攻中后台领域的产品经理来说，这一点会更加感同身受。在策划一个中后台系统时，往往会需要和各个业务方确认，哪些人来做哪些事。在这个过程当中，用例图就能派上用场了。

用例图其实是非常简单的一种图，和脑图有些类似，主要包含两个部分：角色和其相应的职能。它让人能够清晰地认识到，这个系统中包含了哪些功能，分别是由谁来执行或使用的。

在介绍更深入的细节前，用例图可以给所有人一个概览和框架：这套解决方案，从不同的角色视角，都可以做些什么。由此，在这个基础上，可以进一步地讨论：当前的功能点是否已经足够，需要新增或精简功能的边界范围吗？角色的职能是否已经定义清楚，不同业务部门之间是否达成了共识，这套系统上线之后，大家各自需要承担的职能？只有当这些大的方向敲定后，产品进一步地落实和推进细节的工作才是有意义的，否则，很可能出现中途返工的情况。甚至，最恶劣的是，在系统开发完成上线后，各个业务部门之间才开始推诿扯皮。

可见，用例图在向上承接需求时，可以帮助产品经理快速地和业务部门达成框架性的共识，从而进一步地落实细节。相同的道理，用例图在向下交付给研发具体实施时，也可以从先宏观的角度上，方便研发理解目前要做的功能和模块，包含了哪些功能点，整体的规模如何，做到心中大致有数。

流程图：学会使用泳道图、状态转换图

如果说用例图是相当宏观的一个层面，那么再往下一级，就到了流程图这个层面。在用例图表现出角色和职能的基础上，流程图还引入了操作的先后顺序、判断条件等关系。

像上图就是一幅最常见的流程图，在这里我们就不多加以介绍了，大家应该都非常熟悉了。当然了，画流程图也是要讲究基本法的，每个形状各代表什么，可以大概看一遍。不过，一般来说，记住圆角矩形代表开始/结束，菱形代表判断，矩形代表操作和步骤，大多数时候这就够用了。

我们主要来说一说流程图的进阶版本：泳道图和状态转化图。

泳道图：展现角色和阶段

泳道图顾名思义，它的形态就像游泳池一样，区分了不同的泳道。不同的泳道可以代表不同的角色，或者不同的业务阶段。在实际运用中，大多数时候一条泳道代表着一种角色，从而描绘了角色之间的流程关系。

像下图就是很典型的一幅泳道图。在互联网药房开药与购买的流程中，有四个核心的参与方：医生、患者、药房和互联网医院平台，这四者共同组成了完整的互联网开药与购买流程。如果使用传统的流程图，因为涉及的角色较多，不同流程之间往往会有角色的切换，让人难以理解。而使用泳道图，每个角色做什么，都区分在了泳道当中，非常直观。一般来说，当一幅流程图中参与的角色达到三种及以上时，使用泳道图都是更清晰的表达方式。

当然，上面这幅泳道图只是一维的，也就是说它只有竖着的泳道，用来描述不同的角色。实际上，在更复杂一些的业务中，我们还可以画二维的泳道图。所谓二维的泳道图，就是它既有竖着的泳道表示角色，又有横着的泳道表示业务阶段。如下图所示，就是一幅典型的二维泳道图。除了竖着的泳道标识着不同的角色，整个业务流程，还分为了前期筹备、线上兑换、到店核销、结算付款几个阶段。

一般来说，在绘制二维泳道图时，为了视觉上更加清晰直观，我建议竖着的泳道使用明显的分隔线，而横着的泳道，则使用底色来加以区分。

状态转换图：另一种维度的流程图

产品经理在工作中常用到的另一种流程图，叫做状态转换图。其实，常规的流程图和状态转化图，实际上是从两个不同的视角来抽象业务，前者关注于角色的操作流，后者则是状态的转化流。

在实际的流程图中，角色的操作自然会引起状态转化，状态的转化往往也涉及到角色的操作，因此，两者会有一定的重叠，大多数时候，画常规的流程图就已经足够了。不过，如果这个业务比较复杂，涉及到的状态转换较多。产品经理就有必要绘制一幅状态转化图，来更清晰地展现整个业务逻辑。

如上图所示的状态转换图，和常规的流程图相比，你会发现它有一个非常明显的特点：在状态转化图中，我们并不关心整个流程什么时候结束，相反，我们关注的是每个流程最终的状态是什么，以及状态之间是否存在互相转换的关系。由此，可以帮助研发更好地理解，哪些状态是终态，哪些状态是中间态，从而编写出逻辑更清晰的代码实现。

模型关系图：方便与研发沟通

如果说刚刚提到的状态转化图可以帮助研发更好地理解产品逻辑，那么，会画模型关系图的产品经理，会更受到研发的欢迎。事实上，模型关系图处在一个非常微妙的中间地带。它可以是产品经理来绘制的图，也可以是研发自己完成的图。这样的图长什么样呢？

这是一幅比较简单的模型关系图，可以看到，它其实是列举了一个功能或模块中，应该将哪些数据分别记录在哪些表当中，以及这些表之间是如何互联关联的。稍有技术基础的产品经理马上会反应过来，这个多多少少已经有些接近数据库的设计了。没错，实体模型图实际上可以近似理解成一种简化的数据库关系图。

对于研发来说，大多数时候，其实需要将设计稿和产品逻辑，自行翻译到代码逻辑和数据库设计上来。而产品如果能够绘制这样的实体模型图，相当于帮助研发完成了一半的翻译工作。最重要的是，绘制这样的图形，并不仅仅只是在帮助研发。对于产品经理自身来说，实体模型图可以在一定程度上帮助产品经理评估功能的复杂程度，或者在现有基础上升级的可迁移性。

举个例子来说，很多初级的产品经理，往往不能理解，自己觉得很简单的一件事情，为什么研发会反馈需要花很多时间做？或者反过来，有时候自己觉得挺大的一个改动，研发表示分分钟就能改完？如果产品经理能学着绘制实体模型图，对数据结构有一定的了解，在评估这些复杂度时，其实有相当简单的判断方法：

• 比较简单：基本不涉及实体模型的变更，或者，只是在现有的模型中，增加一些字段。如在患者指标组这个实体中，增加一个权限的字段。

• 一般：涉及到新增实体模型。例如，在现有标准指标的基础上，如果需要增加相应的标准解读，就需要创建一个新的实体模型「标准解读」，并关联到现有的「标准指标库」上。

• 比较复杂：往往涉及到现有实体模型之间的关系变动。例如，「患者指标」和「患者指标值」原先是「1:n」的关系，即一个患者指标下面，可以关联多个指标值。如果在变成「1:1」的关系，即一个患者指标，只对应一个指标值。这就是相当大的一个数据结构调整，还涉及到历史数据的处理等一系列复杂问题了。

框架图：为长期规划

再资深一些的产品经理，还需要画很多的框架图。所谓框架图，往往是从一个相当长期的视角，来从宏观上解构产品。这样的框架图，并没有特定的画法，往往只需要根据实际情况，展现出产品或模块的主要逻辑关系，例如包含关系、层级关系等。

例如上面的会员体系产品框架图，展现的就是整个会员体系的长期规划和组成模块之间的关系。要落地会员体系，包含了一系列的功能，可能需要一年的时间来逐步完成。同时，这些工作之间，还可以分为不同的层级和依赖。例如，整个会员体系的建立，都基于最底层的账号体系的改造，在这个基础上，才能在各个业务应用之间打通信息。更进一步的，才是搭建会员体系的积分、余额等功能，并将它们组合成不同的权益，最终才是考虑呈现给用户的展现形态。

你可以看到，产品框架图更关注如何从宏观上解决一个问题，而不去放大某个局部所需的功能特性。因此，它更多地是从回顾性的、前瞻性的、全局性的角度，去输出产品各个模块或系统之间的分布与关系。因此，产品构架图并不是必须的。往往，只有在规划整个产品的未来完整发展规划，或回顾性地整理某个系统的结构时，才需要准备。

另外，这些分解出来的模块之间，彼此之间还可能存在着包含、交叉、互相影响等关联。值得注意的是，如果你发现在框架图中，过多地出现了交叉关系，这可能不是一个好的征兆。你的产品架构，最终往往也会转化为相应的技术架构，从而影响最终的代码实现。好的技术架构应该是高内聚低耦合的，就像好的产品架构，也应该是符合这一特点的。

写在最后

上面提到的各种图，都是产品经理在日常工作中经常需要画的。除了这些图之外，产品经理要会画的图，还可能有用户故事地图、甘特图等等，不过这些涉及到敏捷开发或项目管理的一些技能，并不一定对每个产品经理都具有普适性，这里也就先不展开介绍了。

总结下来，产品经理在画这些图时，需要时而从具体的层面，描述我们为什么如何一层一层搭建一幢大楼；时而需要切换到抽象的层面上，向大家展示这座高楼的钢条构架；时而再到具体的层面上，观察每一间房子的装修；再回到抽象的层面上，谈一谈大楼内功能区域的楼层分布……当然，这并不是说产品经理针对每一个功能和模块，都需要画这么多图，而是根据项目的复杂程度、接收方对背景的了解、项目的实施阶段等因素，有选择性地画需要的图。

你会发现，这些图结合在一起，是具有高度的伸缩性（scalability）的，既可以随时深入到具体的细节，也可以随时到抽象的框架。产品经理如果能成为一名优秀的产「图」经理，在合适的时机，抛出需要的那张图，对团队沟通效率的提升将是空前的。