如何顺利通过设计评审？来看京东高手的实战经验！

设计评审是设计师完成方案后召集项目相关人员进行集中确认的会议，也是保障视觉、开发、测试等后续环节顺利进行的重要环节。如何有效应对及解决评审会上遭到的各种质疑和挑战，本文整理总结出了一份不完全指南。

项目里通常会有两种评审，一种是组内评审，参与者都是组内的产品/交互设计师；另一种是整个项目组的评审，相关人员包括需求方（产品/市场/运营）、视觉、开发及测试等。二者的核心目的都是陈述清楚你的设计方案，接收大家反馈信息，吸收有效的信息改进设计方案，只不过后者面向角色多，因此需要准备的内容会更加全面。

由于我所在的项目团队中，交互设计师同时承担了产品的工作，因此，本文所说的评审更像是把大众认知的「需求评审」和「交互评审」合并成了「方案评审/提案汇报」。

评审前准备

1. 知己知彼，了解评审对象

首先第一件事，了解参与评审的人员都有谁，不同角色关注的重点是不一样的：

• 总监老板：关心扩大业务、有效利用资源以及实现公司目标。
• 产品经理/决策人：关注达成 KPI、方案是否满足业务和用户的需求。
• 视觉设计：构思页面的视觉风格、重心和装饰元素。
• 研发/测试：关注多流程状态、关键字段的规则定义、极限情况、多角色权限等，以确定前后端接口、评估开发工作量和预估工时，输出测试用例。
• 运营/市场：关心品牌一致性、产品特性，以及是否有引人入胜的故事可以讲述。
• BD/销售：关心方案如何使产品在竞争中脱颖而出，是否能帮助他们达成更多交易。

如果是提案汇报型的评审，即向老大及项目组向上汇报，那么一定要研究 keyman，即评审中的关键人物，Ta 的年龄、专业背景、社会层次、喜好偏爱等。把设计作出亮点（反差），亮点不需要很多，三个足矣。

2. 准备充分，梳理清楚方案

作为评审的核心材料，事前要做足够多的功课、准备足够有力的依据。这不是一蹴而就的事，而是在做方案的过程中就要贯彻落实清楚的内容。尽可能从更立体更本质的角度来看待问题和输出解决方案，比如用户目标、商业目标和技术实现，能产生什么价值，能带来对方关心的什么东西等等。

在正式评审时，我们可以只拿出一种设计方案。但是在评审之前需要把能想到的方案都仔细考虑一遍。这样，当被问到“这里为什么不设计成那样”时，就可以从容应答，把之前已经思考过的其他方案中存在的问题一一列举出来。

这里提供一些建议大家参考：

• 多做调查研究：多看看同类型产品是怎么做的，比如说友商的竞品，又或者是一些大厂的产品，揣摩一下别人遇到同样问题时会以什么样的手段来解决，并且尽量去思考他们这样做是出于什么样的考量。
• 提前与开发评估方案的可行性。让开发人员对设计方案有一定的了解，提前预知可能遇到的问题，这样能有效降低在评审会上遭到质疑的风险。
• 在组内进行方案 review，如果是新人设计师可以多和导师或其他交互设计师沟通，会得到不同角度的专业意见。
• 有时候要考虑的情况太多，难免会遇到遗漏的情况。可以在平时工作中建立一个适合自身产品的交互走查表，在评审前及时查漏补缺。
• 如果时间允许，至少提供两种截然不同的方案，因为比起在一个方案上评头论足，人们更喜欢做选择。甚至还可以准备一个基于 AB 方案之间的影子方案，在 AB 方案争执不下的时候拿出来。
• 对流程具有一定复杂度的产品而言，传统用流程箭头标注的交互稿其实并不实用。老板没时间仔细阅读你精心撰写的交互说明。这时，通过轻量级的动效工具产出可交互原型，可以帮助设计师在提案、评审过程中，让老板以及团队人员对方案的实际效果有一个更直观的体验。

一个交互设计师完整的输出物应当包括「原型」 + 「文档」

A. 原型（Sketch/Figma/Principle）

完全或者关键界面，具备演示意义的文档。如果有时间，可以做成可点击的 Demo；如果敏捷沟通，可以是静态图片。

B.交互说明文档，包括但不限于

• 页面内容说明（数据来源、数据特点、内容类型、范围、极值、排序规则、权限表等）；
• 交互流程、反馈、异常、空状态等；
• 交互动效、视觉要求说明。

原型是偏感性认知，交互设计文档是面向开发执行。

评审时主要是演示原型，讲解概要、关键改进和关键步骤。当开发质询你某个页面细节时，再拿出交互文档进行针对性解答。

3. 提前通知，协调人员时间

评审会不是讨论会，而是方案的确认会。事先罗列清楚评审的主题，并同步到群里，确定没有大方向上的问题再进行评审，这样也可以避免大家在讨论时偏题，众说纷纭，既浪费了时间又没解决真正的问题。

至少提前一天以邮件方式通知到各位，邮件内说清楚评审会的目的、内容、会议时间、地点、参会人员等，协调好人员时间。邮件中最好能包含确认的交互设计文档或查看地址，让大家能提前了解方案。提前好预定会议室，并在会议开始前提前十分钟到达会议室调试好电脑、投影等设备。

评审中组织

除了自身的设计方案要靠谱之外，正确地理解、传达和说服别人也很重要。否则，即使你设计出一套完美无瑕的解决方案，你却没能很好地跟别人陈述清楚你的设计思路以及你的设计是如何解决问题，这套方案也难以得到别人的赞同。

1. 明确设计目标

评审开始后，在正式讲述方案前，先花几分钟把设计要解决的问题，要帮助用户达成什么目标和支撑设计的数据和经验判断，通过思维导图、流程图或者其他的可视化手段明确出来。

• 为什么做这个产品/功能
• 它能解决哪些问题
• 为什么要现在去做它
• 它能给我们带来什么收益

不仅利于大家一目了然地理解和讨论，而且在后期出现讨论混乱的情况时，可以回顾设计目标，把大家拉回到正确的方向上。

2. 拆分场景讲述方案

整个方案可以拆分为不同的使用场景和对应的功能流程图，在阐述时有主次之分，先讲大场景，再讲小分支，最后拿着对应的场景、功能流程图和最后的交互原型一一对应。

在陈述方案时尽量把整个设计的过程都表达出来，描述清楚 What-Why-How，原先是怎么思考的，现在为什么会变成这个样子，这个设计是如何解决问题的。有时，提及曾经考虑过的其他解决方案以及否决的理由也很有帮助，可以在讲述时简短地带过，或者展示一下备选方案。

TIPS：声音洪亮，语速要慢，贵人语话迟，说得太快，自己会紧张。要有自信，对自己的方案有信心。

3. 引导大家讨论

一旦讲述完设计方案，大家会提出各种各样的意见。应该如何处理这些反馈，引导大家讨论呢？

首先也是最重要的，闭嘴，多听少说。

当别人发表意见时，不要马上打断来捍卫自己的方案，先从整体上倾听和理解他们想要表达的观点。然后，针对他们的问题提出疑问，阐明和定义问题很重要，确保双方谈论的是同一件事，再给出自己方案的理由。作为设计师，既不要盲目跟从别人的意见，也不要盲目否定自己的方案。

如果遇到当场解决不了或者讨论进行不下去的问题时，新人可以寻求导师的帮助，没人帮助的话，先把问题记录下来会后解决，不要硬刚也不要当场拍脑袋给结论。如果是自己的交互方案有问题或者没想全面，勇于承认，学会妥协，不要钻牛角尖。

如果讲述完设计方案，大家都十分认同， 而且也找不到任何更优的设计思路，在这种情况下，设计师应该把讨论转向现有方案在可用性上是否有潜在问题，项目在后期实现和运营中是否存在风险的话题上。这样，来自不同专业背景的人员，就可以提供一些专业意见帮助改进现有方案。

评审的本质是让参会人员理解并认同方案价值，对方案的实现方式达成统一。讲述方案的目的不是为了说服大家，而是通过客观的描述，让大家展开自己的思考，引导大家从更多维度发表意见从而寻求更好的设计方向。

评审后跟进

评审结束后，应当第一时间将会上总结讨论的成果，邮件发送在场的每一位，包括抄送给不在场的各个部门的负责人。一是同步结论和后续跟进计划，二是用最高效的方式告诉各位 leader 项目的进展。如果想进一步呈现个人价值，在邮件内容中可以附加上对项目的思考判断，对项目的进展和风险做一些评估与汇报。

针对会上各方提出的问题，将调整好的方案重新同步给相关人员，并告知大家修改内容。会议遗留问题要尽快想到解决办法后，与相关人员沟通，重新进行排期确认，预定下次评审时间。

结语

坦白来说，刚开始实习/工作时，我一度对设计评审感到恐慌，不知道如何阐述清楚设计方案、引导大家给出建议，经常出现语无伦次，沉默尴尬的情况，后来随着评审次数的增多逐渐好转。因此，本文整理总结了设计评审的前中后三个阶段需要准备的内容、注意的地方以及方法建议，也是给自己的一份指南/说明书。

当然不同公司、项目会有不同的处理方式，大家需要结合自己的实际情况来调整。总的来说，这些细小的环节，体现了设计师的专业性，能让设计师在项目组中更具影响力。 希望这篇文章能够帮助大家更顺利、更高效、更自信地通过 or 主导设计评审：）

欢迎关注「JellyDesign」的小程序：