Your design isn’t a work of art. It’s a business solution. Practice being critiqued.Matthew Smith
上述话是美国互联网公司Zaarly设计总监Matthew Smith的设计箴言，意思是说你的设计是一个商业解决方案，而不是一件艺术品，因此必须为设计评审做好准备。现实生活中，有很多设计师对设计评审多有抱怨，因为设计评审中存在很多的不确定性，不同的人会有不同的审美偏好和价值偏好，一个设计方案不可能满足所有人的偏好。因此，有的时候一个思路比较完整的设计方案，在设计评审中会因部分人的个人偏好而被改的面目全非;还有的时候，设计评审变成了集体决策时间，少许改动也要全员同意，严重影响了项目的节奏和进度。笔者通过参与项目设计评审工作，形成了个人的一些浅见，在这里与大家分享。
为什么需要设计评审?
在很多非设计专业同事的眼中，设计评审的意义就是确认现有的设计是否为大家接受，给设计挑挑毛病。这其实是一个非常错误的观念。这不仅是因为众口难调，更为重要的是，如果设计仅仅是为了让所有人普遍接受，那就不可避免地使设计陷入平庸和毫无个性。设计评审的真正价值在于：
（本文来源于图老师网站，更多请访问https://m.tulaoshi.com/pmsj/）a. 设计评审可以帮助设计师确认当前设计思路是否能够实现产品目标，是否存在设计思路与产品目标偏离状况。
b. 设计评审可以帮助设计师确认当前设计中哪些部分是非常有效的，哪些部分是有问题的和导致问题的原因。
c. 设计评审中来自不同专业角度的反馈可以给设计师提供新的视野，帮助设计师发现更多更优的设计思路。
d. 设计评审中的反馈还可以帮助设计师充分了解自己做的设计方案在后续的设计过程还有那些潜力可以挖掘。
正如上述图文所示，真正意义的设计评审可以帮助设计师改进方案，为设计和产品指引方向，而不好的设计评审会给设计带来很多困扰，甚至还不如不做设计评审。
如何做一个有意义的设计评审?
设计评审有两大种，一种是设计师的评审(参与人员全是设计师)，另一种是项目组的设计评审。前者的评审人员因为拥有相同的知识背景，沟通起来一般不存在太多问题。本文重点讲项目组内的设计评审。在项目组设计评审中与会人员最好保持在4-8人左右，这是一个高效会议原则。人员背景最好来自不同专业，这样可以给项目评审带来更多不同的视野。至于如何进行设计评审，个人认为可以分为三个阶段。如下图所示：
项目初期，设计评审中应该抛开工程上的和设计上细节实现的种种限制，探讨尽可能多的设计方向和设计思路去实现产品的目标。评审话题应该是启发式的，如是否还有其他的方法去实现。通过来自不同专业视野的反馈，以便激发出更多的设计思路。因为没有哪一种设计方案是完美的，只有通过获取更多的方法和思路，才能评价哪一种设计方案在实现产品目标是最优的。
项目中期，设计评审则更多的是讨论不同方案中优势的部分和劣势的部分，不仅要考虑方案当前优劣，还要指出方案在未来继续设计可能具有什么样的潜力和优劣。通过权衡方案优劣后，确定出最有潜力的设计方案继续进行深化。
项目后期，设计评审的重点在于面向设计细节。需要以可用性原则去判断设计方案中的细节是否存在可用性的问题，同时也需要发现设计中细节比较粗糙的地方，留给后续打磨。
设计评审容易出现什么问题?
1. 评审人员的主观意见
关于这一点不少设计师都深有感触，很多参与设计评审的人员尤其是产品经理，经常会提出一些诸如这个界面使用黄色感觉不太舒服、这个标题的字应该调的更紧凑一些，我觉得这个设计不够大气等等的意见。上述意见更多地反映了个人喜好，而无法达到设计评审帮助设计师寻找更优设计方案，指引设计方向的作用。
2. 评审意见模糊
因为参与设计评审人员来自不同专业背景，有不少人对设计过程和设计本身缺乏足够的理解，因此评审意见模糊的情况在设计评审中也经常出现。意见模糊造成两种结果，一是设计师无法得到有效反馈，二是无法激发评审人员的有效讨论。
3. 项目中前期过于纠结细节
细节打磨是提高设计品质的必经途径，这项工作一般在设计方案确定后进行。但设计评审中经常遇见过于纠结细节的评审人员。如下图所示，在项目初期评审中针对某个细节反复争执(并非所有细节都影响用户体验，需要反复推敲。)。过早地纠结细节，容易使设计只停留在一个方案上，而失去寻找更好的方向和思路的机会。
4. 持续的挑战
有些参与设计评审人员在评审中会持续地挑战设计方案，他们经常会问这样的问题：为什么要按照A设计、为什么按照B设计。挑战设计本身不存在任何问题，很多情况下是可以激发大家去寻找新的更优的思路。但在挑战下，人的本能就是去捍卫自己的观点。设计师也不例外，持续的挑战，让设计师会思考如何捍卫当前方案或改进当前方案。虽然说这一定程度上，也促进了设计方案的优化，但弊端也显而易见，设计师和参与评审人员的思维都被限制在当前方案上，偏离了寻找更多和更优的设计思路的初衷。这就像人们经常说的，为了一棵树，放弃了整片森林。
设计师应如何应对设计评审中出现的问题?
A. 准备充分，否则推迟评审时间
如下图所示，设计师在设计评审中提案就像冰山露在海面上的部分一样，其实只是一小部分，而设计过的方案可能就像海面下更大部分。因为设计本身是一个发散和创造的过程，会有很多种方法达到产品目标。而设计师的工作就是在众多方法中寻找到最优的方案并呈现出来。如果在设计评审前没有把诸多方案想透的话就参加评审，评审中很容易出现方案被质疑的状况，被质疑后方案可能还需要重新做，浪费了时间也浪费人力。因此，在设计评审前一定要尽可能探索所有可能的方案，否则不如推迟评审时间。
B. 讲方案前，要明确设计目标。
如上图所示，讲述方案前要把设计要解决的问题，要带给用户什么样的体验(这需要和产品经理和整个团队达成一致)和支撑设计的数据和经验判断先明确出来。
见过很多设计评审中，为某个细节讨论不休， 各说各话，没有在一个层面上讨论。 如果明确了设计目标的时候，设计师在讨论混乱的时候，可以回顾设计目标，把大家拉回正确的方向。而支撑设计的数据和经验判断，则起到了两方面作用;首先帮助设计师讲述方案时显得有理有据，其次让讨论更加有效，评审人员可以更加明确的讨论是数据和经验判断有问题，还是设计表现上的有问题。
C. 引导大家去寻找更优设计方向和思路
引导大家寻找更优设计方向和思路，在设计评审中至关重要，可以说是精髓所在。有很多人错误的认为，设计评审的不过是评审一个设计方案，如果感觉不错就开始开发，如果感觉不行就打回去修改。作为设计师，应该明白设计评审可以给自己带来的帮助，在评审过程中要引导大家去寻找更优设计思路，这里需要注意是思路而不是方案。正如前文所述，评审的意义在于寻找更多的更好的方向，最后由设计师根据反馈改进提出一个最优的方案。如果在评审中提出了解决方法，这种在短时间思考出来的方法，很可能因为思考不周全而存在这样或那样的缺陷。同时也失去了让设计师去思考更优方案的机会。
D. 设计方案得到认同时，引导大家讨论方案中风险点
如果讲述完设计方案，大家都十分认同， 而且也找不到任何更优的设计思路，在这种情况下，设计师应该把讨论转向现有方案在可用性上是否有潜在问题，项目在后期实现和运营中是否存在风险的话题上。如此一来，来自不同专业背景的人员，便可以提供一些专业意见帮助改进现有方案。
E. 设计师需要主导整个设计评审
在设计评审讨论中，设计师一定要主导整个设计评审工作，只有设计师最了解自己方案中哪些地方是强壮和薄弱的。在设计评审中设计师应该起到主导设计评审的作用。此外，设计师在设计评审中接收大家反馈信息，吸收有效的信息改进设计方案，最后方案如何改进应该由设计师来确定。
设计师如何主导设计评审 ?
如上图所示分了三个阶段，首先要在设计评审前做充分的准备，评审中组织讨论和评审后跟进。每个阶段下都列举了一些小方法，这些方法使用时要因地制宜。总体来说，设计师要想主导设计评审，需要在评审前对每个环节都进行充分准备，这些细小的环节，会让设计师在项目组中更具影响力，最后达到推动设计评审高效进行，体现设计师专业性的最终目的。
参与评审的人如何给出有价值意见 ?
1 先听后说，拒绝持续挑战方案
这是一个非常浅显的道理，但知易行难。先听后说可以避免在没有理解对方意图下加以评论并把讨论引入错误的方向。拒绝持续挑战方案则能够避免在持续挑战下，失去了讨论更多和更优方案的机会。
2 在表达个人喜好时一定要提前声明
对此可能很多设计师都深有感触，很多参与设计评审的人员尤其是产品经理，经常会提出一些像我觉得这个设计不够大气，这个标题的字应该调的更紧凑一些，现在颜色感觉有点太朴素了等等的评论。上述评论更多反映的是个人喜好，但千人千面，不同的人会有不同的喜好，很难全部满足。当然这里并不是全盘否定上述评论，只不过在上述评论中一定要提前声明这是个人喜好。这样既可以让设计师了解到评审人员的直观感受，又避免了上述评论成为评审中讨论的重点。
3 以问题开始，按重要程度排序，关键的问题优先提问
这种提出问题的方式最理想的状态就是每一个问题都可以让讨论更向前推进一步，一开始最重要的提问可以使用你是否尝试过使用B方式.的句式开头，这样的提问会给设计师一个表白的机会，我之前思考过B方式，没有使用是因为。然后讨论就被引向了理性，讨论是否有更优的方案，而不是细节的个人喜好。
4 找出当前设计方案中的精华部分
这是在设计评审中很容易被忽略的地方。找出设计方案中做得好的部分，一方面是对设计师所做工作的肯定，另一方面明确了哪些部分是比较好的，需要保留并可以继续探索。
5 找出问题、指出设计师可能遗漏的方向，避免直接给出解决方法
正如前文所说，找出设计中存在的问题，寻找更好的设计方向是设计评审中重要环节。不过要避免直接给出解决方案，让设计师失去了继续优化方案的机会。
