产品经理怎样活着走出需求评审会?

编辑导语:需求评审会又是撕X大会,产品经理参加的需求评审会应该是数不胜数了,不管产品经理自己主导,还是配合他人,需求评审会的现场都让人不明觉厉,产品经理应该怎样活着走出需求评审会,在一个又一个的需求评审会中磨练出真本领呢?

产品经理怎样活着走出需求评审会?

我发现不管在哪,产品经理总是免不了被diss的命运,这可能就是这个岗位深入灵魂的属性值吧。

一会互联网界的大佬曾经说过:(其实是我说的)“如何让一个未入行的产品经理放弃这条道路?答:那就带他参加一下内部需求评审会吧;如何让一个刚入行的产品经理放弃这条道路?答:那就带他再参加一次外部需求评审会吧!”

对于许多产品经理来说,设计完原型,或许只是噩梦的起点,我们接下来有一项非常重要的任务,那就是先能够活着走出需求评审会。

01 还原案发现场

事情的背景是这样的:我近期不是负责了一条新的产品线么,然后根据我的规划,是打算先搞出来一个MVP产品,看看这个产品对用户有没有价值,以及技术可行性如何。

话说,既然都是MVP产品了,那么界面的美丑我觉得不重要,用户体验什么的都靠边站,我们这一版是内部使用,也不对外,所以安全性也往后排就完事了。并且也说明了,我们要采取敏捷开发的方式,逐步去迭代完善。在这之前,还专门搞了一次敏捷开发的培训会。

然鹅,就是这样的MVP产品,在需求评审的时候,把我郁闷的,差点就去拿我40米的大砍刀了。给我反馈的内容,简直******(脏话)。

反馈的内容,让我忍不住******的,主要有以下几个方面:

1. 共识性需求,还让我描述

产品经理怎样活着走出需求评审会?

一个超级简单的登陆界面,而且我也已经说明了:“现阶段账号管理无需前端界面,直接通过数据库维护账号即可,账号可设定为销售人员手机号,密码可默认为123456。”

然后评审的时候,竟然还让我描述清楚,账号、密码的数据限制都是什么,输错以后的反馈都是什么,巴拉巴拉。

我******,在我的概念里,像这种登录界面,不都是封装好的现成内容么,开发连这些最基本的都不积累么?而且上面我也已经说明了自己的要求,这些都特么不重要,甚至登录界面砍掉都行。。。

唉,我再次******

2. MVP产品,纠结用户体验

产品经理怎样活着走出需求评审会?

这个也是让我略郁闷,这个界面,上来给我反馈一句,别用弹框,弹框的体验不好。

我当时就很纳闷,我们探讨的不应该是用户看到这些内容有没有价值么?我承认,界面是线框图,交互体验也没怎么思考。但如果连价值都没有考虑清楚,只是给用户一个只是好看的“花瓶”产品,这又有什么意义呢?

3. 设计层面,牵扯尺寸把控的细节

产品经理怎样活着走出需求评审会?

我设计了列表形式,然后评审的时候,问我一个界面展示多少条数据。这个吧,对于我一个理工科出身,非设计背景,而且已经在B端混迹多年的老产品来说,着实是难为到我了。

因为在我的概念里,一个界面有多少条数据,这个不应该是考虑整个界面多大尺寸,然后每个列表多大尺寸,有了这两样数据,再说一个界面展示多少条数据才是合适的么~

反正对于我来说,我只能给出,比如“界面默认十条数据”,这样的反馈,至于十条是否合适,我是觉得,应该由UI来把控。其实上面的说是产品来给出定义,这个我认同,但是下面这个,我真是忍不住*******

产品经理怎样活着走出需求评审会?

我都已经给出这样的反馈了,然后还追问我:“这个图标放在标签的前面还是后面,用什么颜色,这个得由你来定一下。”

4. 最不能忍的:原型高保真,详细PRD!

我们团队,虽然提了这一点,但是提的还算客观,大概就是说,让我把细节给落实一下,不然开发过程中,还会有各种沟通协调,各种工作反复,这个我是认同的。

包括我们之前总结过的,作为产品经理的原型设计,应该包含的内容都是什么,尤其是逻辑层面的:

产品经理怎样活着走出需求评审会?

但在我之前工作,有一些**团队,上来就说,原型需要高保真,配套详细PRD(我经历过,一个小产品,就一个月能开发完的那种,然后PRD让写100多页的)。

这种在我的概念里,完全是浪费时间!高保真有啥用。PRD文档写那么详细,谁看啊。而且,评审过后,99%都是有东西需要优化的,高保真与详细PRD的修改时间,真的是白白浪费掉的!

5. 小结

相信很多同学,也都有跟我一样的遭遇吧,甚至是更糟。其实上面的很多反馈,我也是认同的,这些是产品经理的工作,但我不认同的是时间不对,阶段不对。这些绝不是一上来就该做的事情!

就好比我们现在打算盖一栋楼,连盖几层,每层几户,每户是几室几厅都没整明白的,上来就开始讨论床该怎么放,柜子该怎么设计。

关于产品经理做设计应该做到哪种程度,我们之前也是总结过的,有兴趣的同学也可以自行查看一下:《用户体验设计之路(三)原型是设计的表达》

今天我们主要是总结一下,面对这种情况,该如何应对!

02 现状和原因

正如我们引言所述,设计评审,似乎是每一位产品经理成长过程中的必经之劫数。

对于需求阶段抽象的文字概念,大家可能无法做出过多的争论。于是各种意见,就犹如天雷滚滚一般,都集中在了可视化的原型之上,而原型的设计者自然也就成为了众人抨击的焦点,其惨烈之程度简直不可描述~

究其原因,无非是感性的个人喜好以及理性的个人立场不同。

1. 感性的个人喜好

我们在之前的文章中,曾表达过一个观点:评审会议上喋喋不休的争论,是因为所有人都把设计方案当成是画作,而从感性的角度来说,每个人又都有自己的喜好,因此讨论无休无止,永远都确定不了最好的方案。

2. 理性的个人立场

每个人也都有理性的一面,有时候理性的话语听起来似乎都对,但大家就是无法达成共识,这是因为每个人所承担的角色,以及所处的立场不同。

领导希望能够早点上线;运营希望有足够多的推广空间,设计师注重产品是否美观,开发人员则关注设计方案在技术上是否易于实现…..我们可以看到,设计方案所面临的“四面楚歌”之势,而有时候设计方案本身并没有什么不好,但结果却也只能是风萧萧兮易水寒了……

产品经理怎样活着走出需求评审会?

背后的逻辑

感性的个人喜好意味着大家并没有理解原型承载的设计思想;理性的个人立场意味着大家并没有明确产品定位或设计目标。

03 目的和意义

在探究如何才能成功渡劫之前,我们需要先了解设计评审的目的和意义,主要包括以下四个方面:

1. 检验目标

在需求分析以及设计规划阶段,我们确定了一系列的目标,而设计方案则是这些既定目标的产物。在设计评审阶段,首先要检验的就是设计方案是否达成了最初确定的目标。

2. 发现问题

设计评审集中了各种各样的角色,可以及时发现问题、规避风险。并且这个时候还没有进入实际开发阶段,设计方案的调整是相对容易的,节省的是整个团队的成本。

3. 达成共识

设计评审需要让所有相关人员熟悉整体设计理念和设计内容,确保大家的理解与设计方案是一致的。这样才能顺利进入下一个阶段,避免交付之后的反复沟通确认。

4. 建立口碑

从自身的角度来说,其实对于产品经理而言,设计评审也是一个建立口碑的过程。如果每一次评审都能够有理有据地讲述设计方案,体现专业素养,久而久之大家会不断地提升对设计者的信任感,沟通也就会越来越顺畅。

04 方式和方法

如何才能在设计评审会中成功渡劫,这或许是大家最关心的问题,我们可以从会议前、会议中、会议后三个阶段来进行总结。

1. 会议前:充分准备

总结起来,我们需要准备三方面的内容。

1)第一方面:各种设计依据

我们需要在会议开始之前,将用户调研的结果、支撑的数据、竞品分析的内容、需求分析阶段制定的目标,等等,都准备充分。另外,如果某些内容,由于不可抗力因素,并非按照自己初衷设计的,那最好把相关的“证据”也搜集一下,例如客户的要求,或者领导的命令,等等~

举一个我之前实际工作过程中的例子,供大家参考。

产品经理怎样活着走出需求评审会?

就这样一个首页面,评审时有人给出了这样的反馈:“可以把功能入口放上面,然后那些tab切换的内容,别让用户来回切,内容都拉出来平铺展示就行了。”

然后呢,我陈述了自己的设计理念,陈述理念换回的结果就是这个界面保持原设计,不用更改~

“首页之前那么做,是因为考虑作为一个辅导员,在首页最先关注的应该是正在执行任务的进度情况,而且按照我个人理解,根据这些任务的使用频率,依次排列了签到、通知、信息、活动报名。之所以用tab切换的形式,一方面是因为有些任务可能是空的,在当前不一定有,辅导员只需要看到上方的数字为0就可以了;还有一点,也是最重要的一点,就是因为想让用户一眼看到正在执行任务的所有情况,整体任务的进度以及功能入口,在一个手机屏幕内能够展示的下。”

2)第二方面:多种可能方案

这里所说的多种可能方案,并不是说需要我们把所有能够想到的方案都呈现出来。而是说有时候确实存在两种,或者两种以上的设计方案各有利弊,我们也很纠结。这个时候,就可以把这种“选择题”抛给大家,让大家共同确定一种最优解。

3)第三方面:重点人员,单独确认

参与讨论的人越多,意见发表的越多,就越难以得出结论。所以呢,越是重要的事情,越要尽可能少的人参与讨论,这样才能快速下定论。这就需要我们在会议开始之前,先私下和一些有话语权的重点人员单独沟通,并达成共识,而不是把所有问题都抛到会议上解决。

这样可以大大提高会议的效率。当然,同样关键的是,在评审的战场上我们就有了战友,而不至于孤军奋战~

2. 会议中:主导流程

正确的设计评审流程应该是这样的:

产品经理怎样活着走出需求评审会?

设计方向可以将参会人员的思路都统一到一条线上,在产生分歧时,这个方向可以作为判断的标准和依据。设计分析是为了让参会人员能够明白设计方案的原委,而不至于把焦点集中在原型界面这种表象化的内容当中。

之后才是设计方案的展示,以及相关的探讨。对于会议讨论,有这样一句,所有人都应该竭力避免的经典语录:“会而不议,议而不决,决而不行,行而不果!”

会议讨论中偏离主题的情况简直太常见了,有时候一个原型评审会议,说着说着又回到了需求边界的探讨当中,或者是直接跑到UI设计的层面当中了。这就需要主持会议的我们具备一定的控场能力,会议开始前首先明确探讨的主题和边界,会议过程中则需要将偏离主题的讨论及时拉回正轨。

3. 会议后:筛选意见

在会议中,我们会收集到大家表达出来的各种各样的意见。等到会议后,我们就需要对意见进行筛选,而我们需要重点筛选的是那些客观的、明确的、可以操作的反馈意见。

须知,作为产品设计者,我们一定要保持开放的心态,需要积极采纳有价值的反馈,以及倾听大家的意见,而不要过于捍卫自己的设计。毕竟每个人提出的反馈意见,最根本的出发点,都是为了产品能够更好。

05 结语

通过以上的方式方法,我们或许能够避免大多数的问题,保证活着走出需求评审会,应该问题不大。但免不了会有一些完全不在同一频道的同学,这个木得其他办法,想要生存,唯有你足够强大!除了能力,还需要个人魅力,晓之以情,动之以理,才能化险为夷~

最后再把这样两段话送给大家,希望与君共勉。

我们可以把产品的用户体验分为4个层级:

  1. 第1个层级是有用;
  2. 第2个层级是可用;
  3. 第3个层级是易用;
  4. 第4个层级是好用。

我们也可以把产品设计师分为3个等级:

  1. 第1个等级,平庸的设计师想的是完成需求;
  2. 第2个等级,优秀的设计师想的是尽自己所能把需求做到最好;
  3. 第3个等级,卓越的设计师则优先考虑,这个需求到底合不合理,值不值得去做,对产品有什么帮助,用户是否需要它,等等。

#专栏作家#

晓庄同学;公众号:晓庄同学产品笔记