编辑导语：需求评审会又是撕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个等级，卓越的设计师则优先考虑，这个需求到底合不合理，值不值得去做，对产品有什么帮助，用户是否需要它，等等。

相关阅读：《用户体验设计之路（三）原型是设计的表达》

#专栏作家#

晓庄同学；公众号：晓庄同学产品笔记，人人都是产品经理专栏作家。互联网老兵，各大平台专栏作者。

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

题图来自Unsplash，基于CC0协议