聊一聊我对产品原型的心得体会
做产品原型,我想是每个产品经理最普通也最重要的工作之一。为了做好产品原型,很多人会专门学习多个原型工具,努力让自己的产品原型变得更加的精细,我就曾经花了几百块买了一个产品原型制作教程。不过在工作了了几年后,会对产品原型有了新的体会,我觉得产品原型最为核心的不是呈现精细的页面和炫酷的交互,更为重要的是能否借助产品原型与他人互通,达成共识。今天我就来跟大家聊一聊我对产品原型的心得体会,希望对大家有所帮助。
产品原型一定是服务于沟通的
在理解这句话之前,我们先来看一个案例:
汪晨(产品经理)的领导陈璐最近给他安排了一个新任务,让他负责一个全新产品的研发工作。而前期针对这个产品规划的会议(领导会议),汪晨并没有参加。因此这天陈璐把汪晨叫到办公室,跟他谈了一下相关情况。
陈璐:
关于这个产品的情况大概就是这样,这里有些资料,你拿回去研究一下。你有一周的时间做产品原型,做完以后我们会和相关的领导沟通一下。
汪晨:
好的。那我去准备了。
三天过去了,汪晨也没有找陈璐沟通产品相关的内容。这天陈璐走到汪晨的工位前,询问产品原型的情况。
陈璐:
汪晨,产品原型整理得怎么样了啊?
汪晨:
额,一半多了。这个产品真的还挺复杂的,需要想的细节也很多。不过领导放心,我周末会加班做,一定在准时完成。
汪晨说完,得意地笑了笑,但陈璐却变得严肃起来。
陈璐:
你刚才说整理了一半多,你打开原型我看一看。
汪晨从电脑上打开产品原型。陈璐看到原型,脸色变得凝重。
陈璐:
汪晨,你的工作态度很不错,但你做的产品原型并不是现阶段我想要的。现在我们是要给公司领导汇报产品解决方案。领导关心的是产品框架、核心流程,至于Banner图如何切换、按钮交互是什么,不是领导关心的。你现在做的产品原型,更适合团队沟通执行的时候用。你来我办公室,我再跟你说一下,回头赶紧重新做一份。
看到这里,大家估计能想到汪晨此时的心情是怎样的,他又是怀着怎样的心情在陈璐办公室聆听“教诲”。有人可能会问,这个结果是谁造成的呢?我觉得主要问题出在汪晨身上。汪晨之所以会犯错的原因主要是三个方面:1.对产品各阶段的沟通重点理解不深刻;2.在与陈璐沟通过程中,没有详细了解相关的要求;3.认为产品整个开发过程只需要一份产品原型。
因为我们今天说的是产品原型,那我们就从产品原型入手,来分析一下。从案例中,可以折射出第一个问题:做产品原型的目的是什么?我想对于这个问题,大家是有共识的。进一步分析,又会发现第二个问题:产品原型是否只需要做一个?从汪晨的遭遇可以清晰地看出,肯定不是,是需要多个的。那问题又来了:到底需要做多少个产品原型,有没有标准的格式呢?关于这个问题,我的体会是做多少个产品原型,格式是怎样的,需要和公司沟通机制相匹配。
产品原型的制作是基于公司沟通机制的不断循环,其中的逻辑关系是,在日常工作中,产品人员做产品原型的驱动力应该是源于外部,然后再利用自己的专业知识对需求进行整理,最终产生产品原型,而新的产品原型又会成为下一次与外部沟通的载体,达成共识以后,再进一步的化完善,如此往复循环。可以说,这个循环的过程,将伴随产品整个生命周期中的沟通工作。
基于沟通的产品原型优化机制
产品原型的层级
其实我们讨论产品原型的层级,就是在讨论沟通的阶段,毕竟沟通会直接决定产品原型所要表达的内容。至于沟通可以分成几个阶段,我想不同的公司也会有不同的分法,不过我觉得大致都可以分成三个阶段。
沟通阶段与产品原型类型的关系
框架阶段
通俗的说,框架阶段就是产品初期刚刚立项,或者已有产品要开发全新的模块。这个时候沟通的重点,更多是围绕着产品规划展开的,最终的目标是确定产品的核心流程,换种说法就是确定用户的真实需求。这个阶段的沟通工作将直接决定产品的成败。我相信大家应该听说过或经历过由于前期需求沟通不到位,而导致开发出来的产品不是用户想要的情况,可以说这对产品人员来讲是最痛苦也是最伤士气的事情了。
为了避免这样的情况,就需要重视产品原型的辅助作用。在这个阶段,产品原型可以采用思维导图或者框架图。不过就像我们前面说的,产品原型没有固定的格式,可以采用多种形式,但这个阶段的产品原型必须确保两点:
- 能够清晰表达产品的核心流程;
- 与核心用户达成共识。
可行阶段
确定了核心流程之后,产品经理就需要根据核心流程,规划产品的任务流程,简单说就是用户为了解决某一个问题,需要完成那些任务。这些任务需要完整的表达出来,这就需要产品经理做较为细致的产品原型,但这个阶段的目标不是执行,而是一方面细化流程,另外一方面从技术层面评估是否可行。
这里所讲的技术,并非单指产品底层架构、功能实现,而是包括设计、页面等部门的技术评估。例如,领导希望产品能做得很炫酷,并指出可以参考竞品B(B产品是用H5技术实现的),但目前公司内部并没有能够做H5的技术人员。如果在可行阶段及时发现了这一点,我们可以很快地进行重新讨论,但如果到了执行阶段再发现,那项目风险就会很大了。
不过因为这个阶段的沟通不涉及执行,所以原型没有必要把所有的交互效果做出来,只需要页面和重点版块的交互制作出来即可。
执行阶段
到了执行阶段,就是针对具体怎么做的沟通了,因此这个阶段的产品原型一定是高保真产品原型,其中判断是否是高保真原型的重要标准就是:一个用户是否能通过产品原型看到每一个交互细节(涉及到数据的交互可简化处理)。
之所以这样要求,关键原因是开发产品所涉及到的各个部门,都需要依据产品原型制定自己的工作标准。产品原型做得越精细,相应的工作标准就越详细,后期沟通的成本就会越小,进而产品的风险也就越小。
常见的问题
这里我根据自己的工作体会,整理了几个有关产品原型的常见问题,供大家参考。
1、产品原型与沟通目的不相符
这个问题就是上面我们一直在讲的内容,就不再赘述,但绝对需要特别关注。
2、产品原型没有让所有产品干系人看到
在不同阶段,产品人员需要借助产品原型与产品干系人达成共识。如果因为种种原因,产品干系人没有看到产品原型,没有确认,那产品失败的风险会变得很大,就比如前面提到的开发出来的产品与用户的真实需求相悖;另一方面可能是产品开发过程变得不可控,导致产品无法准时上线。因此,各个阶段的产品原型,一定想方设法与相关干系人进行沟通,达成共识。
3、产品原型与团队习惯存在差别
前面我们也说,产品工作有规范的工作流程,但没有规范的工作格式,所以不同的公司之间会存在一定的差异。产品原型方面亦是如此。如果一个产品经理来到一个新的环境,没有“入乡随俗”,仍然沿用以前的工作格式,那就容易出现沟通不畅的问题,加大产品风险。关于这个问题,一个比较简单有效的方法,就是快速地和相关部门同事沟通,再参阅之前同事做的相关原型,形成基本的概念。然后随着工作的不断深入,再进一步优化。
4、产品原型同一元素存在差异
这个问题更多会出现在具体执行过程中。项目进行过程中,我们难免会对产品原型进行修改。不过为了提高效率,我们往往只会修改一个页面,而其他页面就不做修改。这样一来,其他部门在根据原型工作时,就容易出现这个问题,不知道该按照哪个标准来进行了。这时候,我建议在整体原型之外可以添加一个规范说明,将相应的修改及规范描述清楚,这样其他部门的同事,就有了依据,问题可能就会少很多。
实用案例
项目背景
随着公司规模的不断扩张,客户数量也越来越大,但原有的纸质管理已经不能满足发展需求,因此公司决定由产品部门牵头,开发一套供业务部门使用的CRM系统。
沟通1:需求沟通
沟通形式:会议
干系人:业务部门领导、业务代表(不少于3人)、产品部门领导、技术部门领导
沟通内容:讨论CRM结构框架,梳理核心流程
原型体现:思维导图,辅助白板画流程草图
沟通目标:确定产品方向
沟通2:需求沟通
沟通形式:邮件或会议
干系人:业务部门领导、业务代表或全部(不少于10人)、产品部门领导、技术部门领导
沟通内容:确定核心流程
原型体现:产品核心流程图(子流程自包含名称,没有过多细节)
沟通目标:与产品用户达成需求共识
沟通3:可行性沟通
沟通形式:会议
干系人:产品部门领导、技术部门领导、技术骨干成员(项目相关,包含设计、制作、开发、测试等部门)
沟通内容:评估产品技术可行性
原型体现:可交互的线框图(只包含页面及板块交互,不含细节交互)
沟通目标:确定产品开发可行
沟通4:需求确认
沟通形式:邮件或会议
干系人:业务部门领导、业务代表或全部(不少于10人)、产品部门领导、技术部门领导、技术骨干成员
沟通内容:在可行的基础上查漏补缺
原型体现:可交互的线框图(只包含页面及板块交互,不含细节交互)
沟通目标:确定产品可开发
沟通5:项目启动沟通
沟通形式:会议
干系人:业务代表若干、产品部门领导、技术部门领导、技术骨干成员(项目相关,包含设计、制作、开发、测试等部门)
沟通内容:详细沟通产品细节(辅助需求文档)
原型体现:含交互细节的高保真原型
沟通目标:确定产品执行标准
结语
正如开头所讲的,产品原型是产品经理与外界沟通的载体,其核心价值不在于原型外观做得多么精美,而在提升沟通的效率。在此认识下,我们可以进一步关注沟通的不同阶段及其阶段目标,采用与之相匹配的产品原型,进而实现我们的最终目标—有效沟通。
文 @E木笔记
关键字:产品经理, 产品原型, 原型
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!