上一篇文章，《产品设计 | 用户体验设计之路—原型是设计的表达》我们主要总结了抽象的设计思想如何能更好地通过具象的原型表达出来，这里只回顾一个核心观点，因为这个观点也是支撑我们设计评审的重要依据：

• 原型本身并没有那么重要，重要的是我们的设计思想；

• 但原型又是必要存在的，它是项目开发的标准和依据。

1. 现状和原因

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

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

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

（1）感性的个人喜好

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

（2）理性的个人立场

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

领导希望能够早点上线；运营希望有足够多的推广空间，设计师注重产品是否美观，开发人员则关注设计方案在技术上是否易于实现.....

我们可以看到，设计方案所面临的“四面楚歌”之势，而有时候设计方案本身并没有什么不好，但结果却也只能是风萧萧兮易水寒了......

2. 目的和意义

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

（1）检验目标

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

（2）发现问题

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

（3）达成共识

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

（4）建立口碑

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

3. 方式和方法

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

（1）会议前：充分准备

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

第一方面：各种设计依据

我们需要在会议开始之前，将用户调研的结果、支撑的数据、竞品分析的内容、需求分析阶段制定的目标，等等，都准备充分。

另外，如果某些内容，由于不可抗力因素，并非按照自己初衷设计的，那最好把相关的“证据”也搜集一下，例如客户的要求，或者领导的命令，等等~

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

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

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

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

第二方面：多种可能方案

这里所说的多种可能方案，并不是说需要我们把所有能够想到的方案都呈现出来。而是说有时候确实存在两种，或者两种以上的设计方案各有利弊，我们也很纠结。

这个时候，就可以把这种“选择题”抛给大家，让大家共同确定一种最优解。

第三方面：重点人员，单独确认

参与讨论的人越多，意见发表的越多，就越难以得出结论。所以呢，越是重要的事情，越要尽可能少的人参与讨论，这样才能快速下定论。

这就需要我们在会议开始之前，先私下和一些有话语权的重点人员单独沟通，并达成共识，而不是把所有问题都抛到会议上解决。

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

（2）会议中：主导流程

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

设计方向可以将参会人员的思路都统一到一条线上，在产生分歧时，这个方向可以作为判断的标准和依据。

设计分析是为了让参会人员能够明白设计方案的原委，而不至于把焦点集中在原型界面这种表象化的内容当中。

之后才是设计方案的展示，以及相关的探讨。

对于会议讨论，有这样一句，所有人都应该竭力避免的经典语录：“会而不议，议而不决，决而不行，行而不果！”

会议讨论中偏离主题的情况简直太常见了，有时候一个原型评审会议，说着说着又回到了需求边界的探讨当中，或者是直接跑到UI设计的层面当中了。

这就需要主持会议的我们具备一定的控场能力，会议开始前首先明确探讨的主题和边界，会议过程中则需要将偏离主题的讨论及时拉回正轨。

（3）会议后：筛选意见

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

须知，作为产品设计者，我们一定要保持开放的心态，需要积极采纳有价值的反馈，以及倾听大家的意见，而不要过于捍卫自己的设计。

毕竟每个人提出的反馈意见，最根本的出发点，都是为了产品能够更好。

内部的设计评审，确实能够帮助我们发现以及规避很多问题，但交付设计方案，绝不是设计流程的结束。

我们的设计方案，是否能够达成既定的目标，最终还是要经过用户的检验。如果用户不买单，那这个产品终究也只是个赝品。

在产品上线前后，我们需要使用一些方法来检验设计成果，以帮助我们的产品雏形成功渡劫。

此时可用的方法，总结起来有以下四种。

1. 可用性测试

这种方法常用于产品上线之前。

简单地说，就是通过观察用户使用产品的情况，发现产品中存在问题的一种方式。

具体做法如下：

（1）在测试前，设计出几个能反映出产品核心操作的任务；

（2）招募5名左右的用户，这些用户最好可以代表产品的真实用户；

（3）在测试过程中，仔细观察用户对于典型任务的操作情况，记录下发现的问题；

（4）在测试完成之后，对发现的问题进行分析，并进行优化。

可用性测试是一种定性分析的方法，样本数量小，结果未必完全可靠，但可以了解用户的真实想法。

2. A/B测试

这种方法也是常用于正式上线之前。

简单来说就是比较A方案和B方案优劣的一种方法。为同一个目标设计两种方案，一部分用户使用A方案，一部分用户使用B方案，最后通过用户的使用情况，衡量哪个方案更优。

此种方法需要注意以下三个要点：

（1）设定衡量标准，比如PV、UV、点击量、转化率、跳出率、二次返回率等等；

（2）不同版本保持单一变量，不然很难确定结果不同的触因；

（3）保证两个版本同时测试。

由A/B测试衍生出来的，另外一种常见方法是灰度发布。灰度发布是一种平滑过渡的发布方式，通过观察用户的反馈和数据，如果用户的反应很好，可以逐步扩大范围，直至全部升级。

这种方式其实我们是经常见到的，就比如现在的微信版本中，有很多人已经上线了“视频号”的内容，而另一部分人则还没有。

A/B测试是一种定量分析的方法，样本数量大，结果较为客观，但我们很难直接通过数据了解到背后的原因。

3. 用户反馈

任何的产品，都应该保留用户反馈的通道。比起任何依据理论的推测或者是漫无目的的假设，用户的声音才是我们最应该倾听的。

但系统收集上来的用户反馈往往是零散的，或者说是杂乱无章的，我们需要将这些内容整理分类，才能够真正地发现产品中存在的问题。

我们可以从内容、功能、使用流程、设计、新功能建议和现有bug等几个方面对问题进行归纳。

4. 产品数据

同样在本系列的第一篇文章中，我们表达过这样的观点：

人的反馈是感性的，通过这种反馈得到的信息，有时候往往不可靠，而且最关键的是，有时候用户并不知道自己所说的并非心中所想，这就是感性思维的特征；但是数据是理性的，数据不会说谎，加入埋点技术，我们就可以客观地分析问题所在了。

产品数据，是能够帮助我们产品雏形渡劫的重要内容。

—END—