(转)产品经理在工作中需要会画的 7 种图

(转)产品经理在工作中需要会画的 7 种图

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

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

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

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

脑图:整理思路

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

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

社群运营规则的脑图(点击查看大图)

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

想像一下,如果这个过程是在 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)的,既可以随时深入到具体的细节,也可以随时到抽象的框架。产品经理如果能成为一名优秀的产「图」经理,在合适的时机,抛出需要的那张图,对团队沟通效率的提升将是空前的。

(转)产品经理在工作中需要会画的 7 种图

https://blog.hanry.top/Think/5746894d/

作者

萨雷斯煜

发布于

2020-08-02

更新于

2020-12-29

许可协议

评论

Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×