【评审流程】如何通过设计评审？来看这份深度总结

设计评审是产品设计流程中的重要一步，也是在众多设计团队里最有共识的一个环节。在《如何极致还原设计稿》中也提到过设计评审的重要性，设计评审如果做得好，会让你从每个人独特的优势受到启发、挑战、赋能。在评审中我们常常会碰到下面的问题：

尤其是在评审过程非缠着设计师要求解释验证每一项设计决策，那简直是心累不已。中其实优秀的设计评审是探索整个过程，找到亮点并发掘改进机会。我们团队在敏捷开发色过程中程序员、项目经理、产品经理及其他相关人员坐在一起反馈，你得明白如何应对他们，并且把事情迅速往你的期望方向引导，顺利通过评审。

1. 设计评审的定义

设计评审（Design review）为评价设计满足质量要求的能力，识别问题及提出解决办法。从可靠性的角度按事先确定的设计评审表进行。是一种可用性测查工具，目的是及时发现设计中潜在的缺陷，加速设计的成熟，降低决策风险。

2. 设计评审的三大方法

设计评审涉及到数种可用性测查方法，且每一种的方法的运用因评审成员而异、因评审目的而异。常见的设计评审方法有：

a. 启发式评估（Heuristic Evaluation）

启发式评估的标准是：设计方案需遵循一套设计原则，比如尼尔森十大可用性原则。

b. 独立设计准则（Standalone Design Critique）

独立设计准则是（通常以群组对话的形式）对进行中的设计加以分析，以决策设计方案是否达成目标、体验友好的一种评估方法。

c. 专家评审（Expert Review）

专家评审主要是进行充分的启发式评估，验证设计方案是否遵循设计准则，是否违反常见的可用性原则，是否违背认知心理学及人机交互等与可用性有关的原则，是否与评审专家在该领域的专业知识、工作经验相悖等。正因为要强调以往工作经验和专业知识，所以这一评审方法才被称为 “专家” 评审

在很多非设计专业同事的眼中，设计评审的意义就是确认现有的设计是否为大家接受，给设计挑挑毛病。这其实是一个非常错误的观念。正确的设计评审可以帮助团队实现产品目标，帮助设计师发现更优的设计思路。

设计评审真正的价值

• 设计评审可以帮助设计师确认当前设计思路是否能够实现产品目标，是否存在设计思路与产品目标偏离状况。

• 设计评审可以帮助设计师确认当前设计中哪些部分是非常有效的，哪些部分是有问题的和导致问题的原因。

• 设计评审中来自不同专业角度的反馈可以给设计师提供新的视野，帮助设计师发现更多更优的设计思路。

• 设计评审中的反馈还可以帮助设计师充分了解自己做的设计方案在后续的设计过还有那些潜力可以挖掘。

针对 UI 的设计评审应当在整个产品设计与研发过程中开展，或者至少以定期的方式，每周甚至每日开展。这么做可以让产品设计可控，尤其在设计需要进行多次迭代的敏捷或者精益产品流程中。在介绍全流程前，先明确下评审的原则。

1.设计评审的原则

在每次设计评审前建立清晰的原则 - 而不是 “规矩”- 至关重要。与规矩不同，原则不是教条式和限制式的，而是帮助每个人对焦期望，并允许进行自由形式的讨论。

基于以上原则的评审质量取决于参与者技能、目标和责任。不过一个优秀的设计评审通常都聚焦在核心问题本身，针对当前的方案进行透彻的探索。

2.确定设计评审参与人

设计工作大致可分为三个阶段：早期概念创作，中期原型创建，以及后期动工。

项目也分大中小型，对于不同难度的项目，评审人员也要有所不同。如果一个小项目也太多人参与项目评审，时间成本太高。对于改版或者大的功能模块的重新设计，需要经过多轮评审。

项目初期

一般是指项目完成了战略层、范围层阶段的工作后，所到达的框架层、结构层、表现层。评审展示可以是信息架构图、任务流程图、原型图、页面流程图、效果图为评审内容。

在初期这个时间段的设计评审，探讨更多的应是多种设计方向思路去实现产品的战略层方针，通过更多了解业务方向人员的参与，理解清晰产品目标。并为后期达到产品目标，打下牢牢的基础。只有通过更多的设计思路，对比、碰撞、摩擦才能找到更适合自己的产品设计方案。

建议参与设计评审人员：

• 推荐方案：设计专家（UE/UI/ID） + 业务专家 + 产品专家 + 技术专家

项目中期

一般是指项目到了开发阶段，在这个阶段已经有了确认的设计方案，要按照这个设计方案实施了。

所以，这一阶段的「设计审核」目标更多的重心是关于现有方案中的优点和欠缺（没有一个设计方案是完美无缺的）。

最好，在优点的方向是否还有更多延伸性和亮点，在欠缺方面虽然在定稿前就已经知晓，但是否在项目的建设中了解了更多现实开发情况下，能够有足够的时间把欠缺解决。总之，在这个阶段的审核，已经从多个设计方案思路的筛选，孤注到现有确定的设计方案中去开展设计思路的延伸，优胜略汰，使方案变得更有潜力。

建议参与设计评审人员：

• 推荐方案：设计负责人（UE/UI/ID） + 产品经理 + 业务经理 + 技术经理 + 前端负责人 + 后台负责人

项目后期

一般是指项目进入上线或者测试阶段，已完成了一个完整的项目排期工作。

此刻的「设计审核」更多面向的是精益求精，打磨产品细节，利用可用性原则或者遵循 SUS**系统可用性量表 **，去判断设计方案落地过程中是否存在可用性问题，并对各个设计方向（交互 & 视觉 & 体验）提出可迭代性建设性的迭代设计方案。

建议参与设计评审人员：

• 推荐方案：设计负责人（UE/UI/ID） + 设计师（UE/UI/ID）+ 产品经理

最后总结了一个张图给大家

确定好评审原则，我们就来说下评审方法，这里来自金山内部资料，看看大厂是什么方式来评审的

一般的评审方式有两种：

a. 内审流程

b. 外审流程

1.设计师演示

设计师简述设计需求，需求分析，用户画像，竞品分析，发现问题，解决思路，并开始展示设计方案。

2.评审团评审

• 检查需求

检查设计方案是否满足需求，是否完成了交互设计中覆盖的全部设计点。

• 检查规范

检查方案排版和对齐是否准确，产品设计要检查控件尺寸，字体字号是否符合设计规范，运营设计要检查字体字号是否符合运营设计规范。

• 阅读顺序

产品设计检查方案的使用顺序是否符合产品使用流程及用户预期，运营设计检查阅读顺序是否满足运营引导用户阅读的需求。

• 视觉表达

评估设计创意是否有服务于设计目标，视觉表达手法是否处理到位。

3. 内审标准

内审过程中，评审团针对上述四个方面考置设计方案的表现，并给出修改意见。设计师需要综合考虑设计需求，评审标准，以及设计计划做出后续的修改。需要注意的是设计师需要在这个阶段尽力维护设计计划，原则上不建议设计师频繁变更设计计划，这就需要设计师更好的沟通，更强的设计功底和更高的工作效率。

3.1 设计计划变更

当方案未能通过评审，设计师需要做出修改时，需要在会后评估工作量。当工作量控制在半天之内时，设计师需要自行消化当天工作量，积极组织下一轮评审，确保设计计划不受影响。当修改工作量大于半天，或多轮内审不通过，设计师需要与合作方以及设计总监沟通评估是否需要变更设计计划，延期完成。在没有特殊情况下不建议设计师延期。

外审给了整个项目团队从高保真原型的角度重新审视项目的机会，这个时候一些必要的调整能够大大降低产品投放市场后的风险。

但是需要注意的是，外审阶段原则上不讨论设计专业方面的问题，只检查方案是否符合产品设计需求。当产生设计修改和需求变更时，设计团队负责人需要把控设计计划井控制设计成本。

1.设计师演示

设计师简述设计需求，需求分析，用户画像，竞品分析，发现问题，解决思路，并开始展示设计方案。

2.评审团评审

外审人员会加入 1-2 前后端技术人员，市场，运营相关人员，审视整体的需求是否符合业务诉求。

3. 外审标准

外审过程中，评审团 (项目负责人，uec 设计经理，设计总监) 会根据高保真原型 (设计方案) 审视整个需求。评审团会对设计方案中不符合需求的部分给出反馈，会议结束后设计师收集反馈发送给参会人员并做出设计修改，发起第二轮外审。当评审团认为方案已符合产品设计预期时可结束外审，设计师着手准备设计文档和图像资源规范，交付研发 / 运营团队。

3.1 设计计划变更

当双方因沟通不到位产生需求理解误差，造成方案不能满足需求不符合产品设计预期，或因需求方在外审后决定做出需求变更时，双方需要评估工作量。当工作量可以控制在半天内完成设计并再次提交外审时，设计师需要自行安排加班消化工作量，以免项目计划产生延期。

当评估完毕工作量超过半天，或二次外审不通过时，设计师需要与产品经理以及设计总监沟通评估是否需要变更设计计划，延期完成。计划确定后，设计师按照新的计划组织新一轮外审。

4.不同时期的评审关注点

每个评审阶段分别对应着产品不同的关注点：问题、解决方案和实现。真正意义上的设计是奔着解决问题去的，它只是透过 UI 表达出来了而已。

要想顺利通过设计评审，必须得确定一个前提：你必须先清晰表达出你要解决的问题是什么，并和在场人员达成共识！这是整个评审的核心，因为当一天结束时，所有的设计方案都是必须围绕解决这个问题而产生的。

项目初期

在初期评审中，评审展示可以是信息架构图、任务流程图、原型图、页面流程图、效果图。团队在此阶段会塑造出产品雏形，并能广义地描述出用户使用场景、操作流程。产品经理在这个阶段可能会深度参与进来，还有工程师也会评估方案的可行性。此阶段的主要问题是：

项目中期

这个阶段可能是设计师最熟悉的：高保真视觉、短视频、可交互原型甚至内测 demo。产出物可以贴在墙上也可以投上大屏幕，或者干脆直接在手机上预览，以便让每人更清楚地看到细节。这个阶段旨在更细致地评估解决方案是否有效，当前的主要问题是：

项目后期

项目进入上线或者测试阶段，已完成了一个完整的项目排期工作。评审人员应在各个平台各个设备上对功能及数据进行全方位的审查。寻找出任何可能有损于用户体验的部分。这个阶段的主要问题是：

一个好产品应当通过设计展现品牌动人的一面，而且能传达出其缔造者的专业度和用心程度。解决效力应足够强大到覆盖所有目标用户。最终，其「核心问题」、「解决方案」以及「执行力」，都应该在这一款产品中，表现得淋漓尽致。

那了解了这么多设计评审相关的知识，如何能高效通过设计评审是关键，接下来就是顺利推进项目色一些方法，掌握这些方法，按时下班不是梦。

1. 评审前的思考

评审过程中为何他人会质问和反对？，主要矛盾在哪里？对评审期间会出现的疑问要有一个大概预期。可以按照流程先自己从脑子里过一遍。

大致总结可以从以下方面先自己演练一遍：

• 最后为什么考虑使用这个设计方案？
• 这个需求要解决什么问题？能不能一句话说清楚
• 之前已有的功能的数据是什么样的？
• 我们的竞争对手是怎么做？有没有同类型的设计？
• 这个新设计和我们之前设计不一样，是怎么考虑的？能不能沿用之前的控件？
• 这些元素没有对齐？是故意的还是粗心？
• 设计稿上面的内容是接近于真实的内容吗？如果不是可以改成真实的看效果
• 为什么使用这些颜色，在平台规范中没有出现过？

2.准备与沟通

预定好会议室，提前周知参会人员会议时间和地点。在评审会之前和产品经理预沟通设计稿可以先让你和产品经理达成一致，会让评审会高效，同时其他参与评审的同事有问题时，还可以让产品经理来一起解答（扛雷）。

3.编排评审顺序和评审资料整理

「编排评审顺序」

相当于把评审节奏控制在你的手中，一切根据你制定的顺序进行，一般情况下，可以这样编排：

• 讲解「设计思路」，让大家先和你的思路对接起来，避免直接看到设计稿时每个人都从自己的角度出发。
• 编排设计稿的讲解思路，展示「核心页面的设计稿」，因为评审人数众多，如果设计稿状态很多，涉及到设计稿比较多，可以先把「核心页面」贴出来，让大家理解后没有问题，再把余下状态作为补充展示出来。

「整理待评审资料」

有了思路和编排，也尝试了自问自答，还可以准备一些能够作为你背书的资料，能够帮助你在评审时，作为资料背书给大家展示，也可以供你快速查阅信息，方便回答问题，以下是清单

• 产品 PRD：当有疑问时可以拿出来给评审者查看
• 设计分析文档：用来沟通关于行业内对于同类型功能的设计优缺点的分析
• 数据分析文档：用来展示当前版本数据上的表现和问题，以及可以帮助进行下一步改善
• 功能逻辑图：复杂功能可以使用图形化表现功能逻辑，便于评审者理解
• 用户路径图：通过用户路径讲解全局性问题，结合交互设计稿进行具体说明
• 交互动效演示文档：用来解释一些比较复杂的交互过程
• 配色情绪版：用来解释如何选择当前配色的思路

1.**评审优先表 **

在这里我们主要讲的是评审可用性测试，基础评审可以放到内部评审里解决。

在评审过程中，专家可能需要用到设计原则（例尼尔森十大可用性原则）、行业领域竞品产品案例、前瞻性设计方向等建设性评估。书面文档建议内容尽力做到够详细，可以作为后续设计方案修改的参考性依据，可根据可用性问题的严重程度（高 / 中 / 低）排序。

• 这里评审优先表主要包括

用户体验问题记录表

没有上线的环境下我们会找不同部门的先定性内测，内测主要使用的是用户体验问题记录表

二十一条可用性原则

有了这 21 条，可以让任何没有用户体验知识的人参与到协作启发式评估中来了，一秒变专家了。当然，这 21 条可用性原则我们也会迭代优化，目的是做到更符合现今产品、更全面的可用性原则。

系统可用性量表（SUS）

最初是 Brooke 于 1986 年编制，量表由 10 个题目组成，包括奇数项的正面陈述和偶数项的反面陈述，要求参与者在使用系统或产品后对每个题目进行 5 点评分。

SUS 评分参考

从图中我们可以看出评分达到 70 分左右，就可以比市面上一半产品可用性要好，也就是说这个产品的用户体验算是合格了。

2. 讨论范围的把握

评审中当发现大家的讨论范围跑偏了，主持人要及时把主题拉回来，而不是任由大家发散。

同事要避免提意见者直接给答案。参与者将会带有强烈的解决问题欲望，而且会在评审中提出解决方案。然而，最佳方案往往不会在评审时产生。评审的关键是探索问题及讨论潜在的多个方案，帮助设计师拓宽思路并最终决策。

人物模型可以有效解决评审中，讨论范围的跑偏，在设计评审中规定好人物模型中参会者的发言时间和发言环节，引导大家去寻找更优设计方向和思路。

3. 合理表述

在您展示任何原型或条条框框之前，请从用户的角度讲一个简短的故事：在什么背景下，谁将使用这个的解决方案。

简明地抛出以下问题：

• 我们讨论的是什么类型的用户？
• 他们从哪里来的？
• 他们的心态是什么？
• 他们有什么强烈的情感吗？
• 他们想要达成什么目的？

在背景确定的前提下，现在是时候展示你的设计是如何解决这个问题了。在引导人们浏览流程图或原型时，无需说明显而易见的事情。最好保持安静，让他们沉浸在设计中；而不是指出为何决定将蓝色用作按钮颜色的，这些他们自己也能看懂。

对于模糊的修改意见，要善于发问，深挖提问者意见背后的真实原因。你深入问下去，最终原因原来是，他认为这里不需要放按钮。这就涉及到一些产品功能架构方面的问题了。

一些好问题的例子：

• 你认为这将如何影响（项目目标）？
• 为了确保我跟上了你的思路，你认为做（建议）可以如何解决（用户问题）？
• 你在（基于他们最喜欢的应用的建议）时提到自己喜欢它。你为什么喜欢他们的做法？
• 你认为这样做的利弊是什么？
• 是的，我知道你来自哪里。我同意（他们提到的问题）是个大问题。你认为为何可以通过（他们的建议）来解决这个问题？
• 不幸的是，由于我们不能同时做到这两者，因此你认为（解决方案 A）比执行（解决方案 B）更重要吗？
• 感谢你提出这个问题。你是否看到用户的任何反馈表明（问题）普遍存在？

回应、决定、继续推进 - 推动评审的关键‼️

听完并提出问题后，看看谈话的进展方向，随时准备将大家拉回来并推动讨论继续。

4. 多方案优中选优（拉开）

尝试多方案探索。学习 4A 公司的创意发散思维，你见过广告公司有一稿过的情况吗？与其做一次改一次，不妨预先考虑所有情况，做自己能做到的极致。当你拿出几个方案去说，经过多方探索，最后认为方案三是最优解时会比只拿一个方案三去评审更有说服力。或许真正评审时只需要提出你的最终方案，但敲定方案前的方案 ABC 还是必要的，它将让你进行设计阐述时更有底气。

我们以一些大厂的设计评审为例

• 一刻相册中为了提升用户的浏览体验及效率，**同时在视图方面也做了多种尝试，如下图：**
  
  最终选择原因: 基于用户使用诉求和对相册产品的调研，选择了保持相册内容的比例统一，但对可动的 livephoto 及视频内容进行突出放大展示，并默认进行播放，这样既满足了效率问题，又让浏览体验更有节奏感，同时也兼顾了开发成本。

• 飞猪的风格探索

• 网易公开课改版的评论区设计

展示形式上，这次的改版我们选择了平铺式，即不区分子母评论关系，无论是对动态、对评论的评论，都视为平级的评论。

5. 底层依据助力设计阐述

在你进行设计阐述时，不是依靠口才和随机应变来处理各种质疑和反对。而是用扎实的底层依据来让所有人闭嘴。何为底层依据，即你为产品中后期的设计而进行的前期调研，竞品分析，用户建模等一系列围绕产品目标产出的数据。言之有物，拿出证据让设计阐述有理有据。

6.筛选合理需求

我们必须了解评审的意义所在，即求同存异取优，曝光问题，吸取意见，完善产品。

求同是大方向，最终目的是选取一个对内符合团队成员预期和能力，对外能够解决用户实际问题的优秀设计方案。

存异是了解各个部门成员对于设计方案的疑问，了解并耐心听完才能收获真正对产品有价值的提议。取优则是要求我们作为设计师有一个筛选合理的需求的能力。

诸如，这里感觉怪怪的，那里有点不舒服等这种没有任何建设性的意见可以直接忽略。什么意见可以吸取呢？一种是考虑到自身资源不能完成的指标或者优先级较弱的需求——“这里的动效过于复杂，技术实现难度大，时间成本高。“另一种考虑到用户体验视觉效果但要求明确提出问题点——“这里字号过小，一眼看去很容易忽略掉。

1. 总结评审后意见反馈

会议评审过程中在讨论的同时也要收集意见，会议接近尾声将已达成共识的问题点记下来之后同步这些争议点，这样做一是让大家了解会议上我们有了这样的结论，是否有遗漏，另一个也可以体现我们的专业性。最后要预约下次评审时间，以便后续跟进。

2. 按照优先级优化

筛选后的需求进一步的确认和理解，以保证理解的需求和执行的优化结果不会因为歧义和误导而返工。可以对于提出需求者进行回访，通过邮件形式询问他的需求和你的理解是否一致。

对最终列出的需求单进行优先级排序，用ergency（紧急性）importance（重要性）作为 XY 轴选取右上角的部分优先完成。

因为每个团队都有自己产品侧重点，我就不过多的说了，想了解的可以最后留言！

1. 准备工作不足

没有对设计主题准备充分的依据或来源，为什么要这么做？这么做可以解决什么问题？评审过程中很容易被反问而答不上来，导致意见被驳回，只能改了。

2. 意见发散

说整体风格的时候容易扯到 icon，说 icon 扯到 button，说 button 扯到颜色，容易打乱评审节奏，提前纠结在一些细节上。

3. 评审者的主观意见

每个人都有自己客观的思维。而品味、联想和诠释这三点是主观的，经常会听到 “感觉不够上流“，” 没有眼前一亮的感觉 “，” 这个颜色我喜欢，不过能再调亮一点么”等等。每个人有每个人的审美观，萝卜青菜各有所爱。

4. 缺少会议总结

评审过程中的问题没有得到一个梳理，郁闷中收集了一堆的意见反馈，后面也没有一个问题点跟进，只是默默的改… 下次评审时间不确定，定稿时间遥遥无期…

5. 传达限制条件不完整

每个设计师负责的具体业务不一样，别人对这些限制条件的具体了解程度也不会有你来得深入，所以在评审会议上，他们可能会从更理想化的角度出发思考，给出和限制条件矛盾的思路、建议与解决方案。所以讲解自己的设计方案之前，也应当提前和项目组沟通清楚细节，把这些业务 / 技术上的冲突点清晰、全面地描述给团队其他设计师。

比如描述限制条件的根本原因，大家共同判断是否确实需要进行妥协，探讨是否有已经实现的现成案例来证明限制不存在，是否有能取得更好平衡的方案等。像技术限制，是组件改动困难（牵一发而动全身）？是实现成本过高（投入产出的性价比不够）？是影响速度等性能（实际用户体验不佳）？还是其他一些原因等；而如果只是简单说一句「前端 / 开发说这个做不了」的话，并不是那么令人信服。

6. 私下沟通跟进不到位

设计评审的会议时间最长也就几小时，在这么短的时间内得到的建议反馈，其实是有不少考虑不够周到全面之处的，而这些往往要到具体修改方案的环节才发现。所以除了发起评审之外，私下找其他熟悉业务的有经验设计师沟通探讨也很重要，这样得到的建议启发也更加成熟和思虑周全。

其实归根结底，做设计评审的主导者并不是让你学一些所谓的小技巧，阴谋诡计来躲避一些批评和反对。而是通过提高本身设计能力，提高设计方案的价值、核心竞争力（视觉或者交互、用研），提高自身的设计阐述能力，用有理有据的设计提案获得认可，助力产品设计，衔接产品设计的上下游，最终上线并为企业赚得利润价值。

要有一颗积极的、理性的心态来参与设计评审，否则很容易在评审过程中因为受到反驳而沉溺于消极状态！在大家对方案进行点评时也期待提出更好的建议和优化方案，大家的初衷还是最后能真的为用户解决掉一些问题，更多的还是有个更好的产品体验！
https://www.zcool.com.cn/article/ZMTE2MzYzMg==.html