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

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

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

01还原案发现场T p 0 t $ j J

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

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

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

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

1. 共识性需求,还让w f V c R我描述

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

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

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

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

唉,我再次******

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

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

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

我当时就很纳闷,G J & S我们探讨的不应该是用户看到这些内容有没有价值么?我承认,界面是线框图,交互体验也没怎么思考。但如果连价L s W Z V _ T值都没有考虑清楚,, s n Y y k O只是给用户一: | M 2 7个只是好看的“花瓶”产品,这又有什么意义呢?

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

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

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

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

反正对于我来说,( Z I \ L a I v我只能给出,比如“界面默认十条数据”,这样的反馈,至于十条是否合适,我是觉得,应该由UI来l r T h ` o ; w *把控。其实上面的说X u \ \ I是产品来给出定义,这个我认同,但是下面这个,我真是忍不住*****U ` P q @ &**

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

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

4. 最不能忍的:原型高保真,详E 3 ) , 0 3 &细PRD!

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

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

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

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

这种在我的概念里,完全是? 1 j b wm B E – . 3 = u费时间= L g j c _!高保真有啥用。PRD文档写那么详细,谁看啊。而且,评审过后,99%都是有东西需要优化的,高保真与详细PRD的修改时间,真的是白白浪费掉的!

5. 小结

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

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

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

今天我们主要是总结一下,面对这种情况,该如何u – \ m e X应对!

02现状和原因

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

对于需求# # ( 7 T dq } b ~ H段抽象的文字概念,大家可能无法做出过多的争论。x ^ +于是各种R G _ @ Y & b意见,就犹如天雷滚滚一般,都集中在了Y r q Q 7 y & & CC p t i视化的原型之上,而原型的设计者自然也就成为了众人抨击的焦点,其惨烈之程度简直不可描述~

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

1. 感性的个人喜好

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

2. 理性的个人立场

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

领导希望能够早点上线;运营希望有足够多的推广空间,i J T ) _ ? P设计师注重产品是否美观,开发人员则关注设计方案在技术上是否易于实现…..我们可以看到,设计方案所面临的“四面楚歌”之i ) $ F \ ; ~ S |势,而有时候设计方案本身并没有什么不好,但结果却也只能是风萧Y { | A @ +萧兮易; K 1 V 0 4 I N水寒了……

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

背后的逻辑

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

03目的和意义

在探究R # 0 9 G R Q如何才能成功T v s } . U X渡劫之前,我们需要先了解设计评审的目的和意义,主要包括以下四个方面:

1.I D 9 检验目标

在需求分析以及设计规划阶段,我们确定了一系列的目标,而设计方案则是h b { Y这些既定目标的9 | y !产物。在设计评审阶段,首先要检验的就是设计方案是否M \ ; D ; v % L n达成了最初确定的目标。

2. 发现问题

设计评审集中了各种各样的角色,可以及时发9 k 4 0 : i现问题、规避风险。并且这个时候还没有进入实际开发阶段,设计方D S a 9 8 P ) h案的调整是相h 8 f S T对容易的,节省的是整个团队的成本。

3. 达成共识

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

4. 建立口碑

从自身的角R Q –度来说,其实对于产品经理而言,设计评审也是一e L w W 3 x G D m个建立口碑的过程。如果每一次评审都能够有理有据地讲述设计} : u t n Z e U方案,体现专业素] , I 8 | a # d养,久而久之大家会不断地提升对设计者的信任感,沟通也就会越来越顺畅。

04方式和方法

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

1. 会议前:充分准备

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

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

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

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

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

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

然后呢,我陈述了自己的设计理念,陈述理念换回的结果就是这个( q J 8 9 G /界面保持原设计,不用更改; / +~

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

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

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

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

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

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

2. 会议中:主导流程

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

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

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

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

会议讨论中偏离+ 7 & } ` I n $主题的情况简直太常见了,有时候一个原型评审会议,说着说着又回到了需求边界的探讨当中,或者是直接j O u跑到UI设计的层面当中了。K J 8 , K Y c这就需要主持会议的我们具备一定的控场能力S ^ h – P,会议开始前首先明确探讨的主题和边界,会议过程中则需要将偏离主题的讨论及时拉回正* p [ 4 – l k轨。

3.a k : O 7 y h \ n 会议后:筛选意见

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

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

05结语

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

最后再把这样两F , u O x 3 – 0 _段话送给大家,希望与君共勉。

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

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

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

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

相关阅读:《$ D i * 9用户体验设计之Z m q o路(三)原型是设计的表e H ,达》

#专栏作家#

晓庄w u Q C N t 1 m {同学;公众号:晓庄同学q j b产品笔E m z 2 Q 0记,人人都是产品经理专栏作家。互联网老兵,各大平台专栏作者。

本文原创发布于人人都是产品经理。未经许可,禁止转载

给作者打赏,鼓励TA抓紧创作!

2人打x : X X w F l C

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注