设计评审是困扰很多设计师的一个工作环节，我也是亲身经历总结出一套评审全流程，全文10020字，阅读时间21分钟。
设计评审是产品设计流程中的重要一步，也是在众多设计团队里最有共识的一个环节。设计评审如果做得好，会让你从团队里每个人独特的优势受到启发、挑战、赋能。
下面在评审中我们常常会碰到下面的问题：
1. 设计评审的定义
设计评审（Design review）为评价设计满足质量要求的能力，识别问题及提出解决办法。从可靠性的角度按事先确定的设计评审表进行。是一种可用性测查工具，目的是及时发现设计中潜在的缺陷，加速设计的成熟，降低决策风险。
2. 设计评审的三大方法
设计评审涉及到数种可用性测查方法，且每一种的方法的运用因评审成员而异、因评审目的而异。常见的设计评审方法有：
协助启发式评估（Heuristic Evaluation）
这里为什么是协作启发式评估而不是启发式评估？
因为启发式评估主要由几名交互专家以角色扮演的方式来完成设置的任务给出评估结果。优点是成本低、快捷，缺点也显而易见，一是交互专家团队中不一定有或者很少，二是可用性问题意见一致率很低，并不能很明确的指出为什么这是一个体验问题，有很多个人因素的主观见解。
协作启发式评估不需要交互专家，可以是用户、测试、设计、产品、运营、商务等等，只要愿意参与测试，就可以。协作启发式评估以小组为单位，根据整理的一套可用性原则表单来排查问题，能够很好的整合出更多的问题，而且更准确。
独立设计准则（Standalone Design Critique）
独立设计准则是（通常以群组对话的形式）对进行中的设计加以分析，以决策设计方案是否达成目标、体验友好的一种评估方法。
专家评审（Expert Review）
专家评审主要是进行充分的启发式评估，验证设计方案是否遵循设计准则，是否违反常见的可用性原则，是否违背认知心理学及人机交互等与可用性有关的原则，是否与评审专家在该领域的专业知识、工作经验相悖等。正因为要强调以往工作经验和专业知识，所以这一评审方法才被称为「专家」评审。
3. 设计评审的价值
在很多非设计专业同事的眼中，设计评审的意义就是确认现有的设计是否为大家接受，给设计挑毛病。这其实是一个非常错误的观念。正确的设计评审可以帮助团队实现产品目标，帮助设计师发现更优的设计思路。
总的来说设计评审的价值可以有四方面：审核设计目标、挖掘设计亮点、共享资源信息、激发灵感潜力。
审核设计目标
设计评审可以帮助设计师确认当前设计思路是否能够实现产品目标，是否存在设计思路与产品目标偏离状况。是否达标设计原则提升设计的质量
挖掘设计亮点
设计评审可以帮助设计师确认当前设计中哪些部分是非常有效的，哪些部分是有问题的和导致问题的原因。
共享资源信息
设计评审中来自不同专业角度的反馈可以给设计师提供新的视野，在一个设计问题中遇见瓶颈时可以求助其他成员，然后帮助设计师冲破设计中遇到的障碍，不限形式，从视觉、交互效果到品牌形象。保证团队整体设计的一致性。而且可以提升与不同职能的成员的协作性
激发灵感潜力
设计评审中的反馈还可以帮助设计师充分了解自己做的设计方案在后续的设计过还有那些潜力可以挖掘。 激发灵感，产生更多想法发现更多更优的设计思路。
首先想给大家明确一下，设计评审在产品研发各个环节中所处的位置。
一般的产品研发大致可以分为五个流程：项目启动、需求分析、产品设计、开发上线、版本迭代。
我们把流程分解后，我们今天主要说项目中期的设计评审，此环节在产品设计之后开发上线之前，属于一个很重要的环节，此环节是确定设计方案移交开发中间环节，一旦有设计或者需求疏漏，会产生严重bug和返工的情况。
因此一个看上去细小的一个环节，其实经常会困扰着我们，如果刚开始没有将产品开发环节进行整体的梳理，那么在你的设计过程中，评审出问题会导致整体项目的延期，为了让大家能够对设计评审有更深的理解，我将评审进行系统的拆解，结合实际案例，能够让大家掌握高效通过评审的流程。
在讲干货之前，想跟大家普及几个知识点。让评审经验少的同学可以更好消化后面的干货。
1. 设计评审的周期
针对UI的设计评审应当在整个产品设计与研发过程中开展，或者至少以定期的方式，每周甚至每日开展。这么做可以让产品设计可控，尤其在设计需要进行多次迭代的敏捷或者精益产品流程中。在介绍完周期后，先明确下评审的原则。
2. 设计评审的原则
在每次设计评审前建立清晰的原则，而不是「规矩」至关重要。与规矩不同，原则不是教条式和限制式的，而是帮助每个人对焦期望，并允许进行自由形式的讨论。
表示尊重
听起来很老套，但如果每个人都是在批评而不是尊重台面上的意见和他人的技能，那评审会迅速形成敌意。
理解需求
强调本次会议的需求，目标用户为了解决什么问题而来的。
合理表述
在跟听讲解设计时，记得提及项目背景，解决方案，设计媒介，用户体验的流程，演示产品。
固定范围
快速提醒每个人项目目标以及评审涉及的范围。确保整个评审集中在手头任务上，而不是东扯西扯，偏离话题。
得出方向
每次会议的结尾要总结，本次达成共识。保证会议是有效率。
UI设计评审经常在视觉细节上死磕，而忽视交互层面的更影响设计的内容。
基于以上原则的评审质量取决于参与者技能、目标和责任。不过一个优秀的设计评审通常都聚焦在核心问题本身，针对当前的方案进行透彻的探索。
确定好评审原则，我们就来说下评审方法，这里来自金山内部资料，看看大厂是什么方式来评审的。
一般的评审方式有两种：内审流程；外审流程
1. 内审流程
设计师演示
设计师简述设计需求，需求分析，用户画像，竞品分析，发现问题，解决思路，并开始展示设计方案。
评审团评审
检查需求。检查设计方案是否满足需求，是否完成了交互设计中覆盖的全部设计点。
检查规范。检查方案排版和对齐是否准确，产品设计要检查控件尺寸，字体字号是否符合设计规范，运营设计要检查字体字号是否符合运营设计规范。
阅读顺序。产品设计检查方案的使用顺序是否符合产品使用流程及用户预期，运营设计检查阅读顺序是否满足运营引导用户阅读的需求。
视觉表达。评估设计创意是否有服务于设计目标，视觉表达手法是否处理到位。
内审标准
内审过程中，评审团针对上述四个方面考置设计方案的表现，并给出修改意见。设计师需要综合考虑设计需求，评审标准，以及设计计划做出后续的修改。需要注意的是设计师需要在这个阶段尽力维护设计计划，原则上不建议设计师频繁变更设计计划，这就需要设计师更好的沟通，更强的设计功底和更高的工作效率。
设计计划变更。当方案未能通过评审，设计师需要做出修改时，需要在会后评估工作量。当工作量控制在半天之内时，设计师需要自行消化当天工作量，积极组织下一轮评审，确保设计计划不受影响。当修改工作量大于半天，或多轮内审不通过，设计师需要与合作方以及设计总监沟通评估是否需要变更设计计划，延期完成。在没有特殊情况下不建议设计师延期。
2. 外审流程
外审给了整个项目团队从高保真原型的角度重新审视项目的机会，这个时候一些必要的调整能够大大降低产品投放市场后的风险。
但是需要注意的是，外审阶段原则上不讨论设计专业方面的问题，只检查方案是否符合产品设计需求。当产生设计修改和需求变更时，设计团队负责人需要把控设计计划井控制设计成本。
设计师演示
设计师简述设计需求，需求分析，用户画像，竞品分析，发现问题，解决思路，并开始展示设计方案。
评审团评审
外审人员会加入1-2前后端技术人员，市场，运营相关人员，审视整体的需求是否符合业务诉求。
外审标准
外审过程中，评审团(项目负责人，uec设计经理，设计总监)会根据高保真原型(设计方案)审视整个需求。评审团会对设计方案中不符合需求的部分给出反馈，会议结束后设计师收集反馈发送给参会人员并做出设计修改，发起第二轮外审。当评审团认为方案已符合产品设计预期时可结束外审，设计师着手准备设计文档和图像资源规范，交付研发/运营团队。
设计计划变更。当双方因沟通不到位产生需求理解误差，造成方案不能满足需求不符合产品设计预期，或因需求方在外审后决定做出需求变更时，双方需要评估工作量。当工作量可以控制在半天内完成设计并再次提交外审时，设计师需要自行安排加班消化工作量，以免项目计划产生延期。
当评估完毕工作量超过半天，或二次外审不通过时，设计师需要与产品经理以及设计总监沟通评估是否需要变更设计计划，延期完成。计划确定后，设计师按照新的计划组织新一轮外审。
不同时期的评审关注点和参与人
项目也分大中小型，对于不同难度的项目，每个评审阶段分别对应着产品不同的关注点和参与人。
设计工作大致可分为三个阶段：早期概念创作，中期原型创建，以及后期动工。
要想顺利通过设计评审，必须得确定一个前提：你必须先清晰表达出你要解决的问题是什么，并和在场人员达成共识！这是整个评审的核心，因为当一天结束时，评审团必须围绕所有的设计方案对解决这个问题而产生的。
项目初期
- 项目情况：一般是指项目完成了战略层、范围层阶段的工作后，所到达的框架层、结构层、表现层。
- 评审展示：可以是信息架构图、任务流程图、原型图、页面流程图、效果图。
- 评审目的：团队在此阶段会塑造出产品雏形，并能广义地描述出用户使用场景、操作流程。评审更多的应是多种设计方向思路去实现产品的战略层方针，将更多了解业务人员的参与，理清产品目标。并为后期达到产品目标，打下牢牢的基础。
建议参与设计评审人员：
推荐方案：设计专家（UE/UI/ID） + 业务专家 + 产品专家 + 技术专家
此阶段的主要问题是：
项目中期
- 项目情况：一般是指项目到了开发阶段，在这个阶段已经有了确认的设计方案，要按照这个设计方案实施。
- 评审展示：高保真视觉、短视频、可交互原型
- 评审目的：是关于现有方案中的优点和欠缺的考量。
在优点的方向是否还有更多延伸性和亮点，在欠缺方面虽然在定稿前就已经知晓，但是否在项目的建设中了解了更多现实开发情况下，能够有足够的时间把欠缺解决。
总之，在这个阶段的审核，已经从多个设计方案思路的筛选，孤注到现有确定的设计方案中去开展设计思路的延伸，优胜略汰，使方案变得更有潜力。
建议参与设计评审人员：
推荐方案：设计负责人（UE/UI/ID） + 产品经理 + 业务经理 + 技术经理 + 前端负责人 + 后台负责人
此阶段的主要问题是：
项目后期
- 项目情况：一般是指项目进入上线或者测试阶段，已完成了一个完整的项目排期工作。
- 评审展示：移动端或者网页端测试环境。
- 评审目的：此刻的「设计审核」更多面向的是精益求精，打磨产品细节，利用可用性原则或者遵循SUS系统可用性量表，去判断设计方案落地过程中是否存在可用性问题，并对各个设计方向（交互&视觉&体验）提出可迭代性建设性的迭代设计方案。
项目进入上线或者测试阶段，已完成了一个完整的项目排期工作。评审人员应在各个平台各个设备上对功能及数据进行全方位的审查。寻找出任何可能有损于用户体验的部分。
建议参与设计评审人员：
推荐方案：设计负责人（UE/UI/ID） + 设计师（UE/UI/ID）+ 产品经理
这个阶段的主要问题是：
一个好产品应当通过设计展现品牌动人的一面，而且能传达出其缔造者的专业度和用心程度。解决效力应足够强大到覆盖所有目标用户。最终，其「核心问题」、「解决方案」以及「执行力」，都应该在这一款产品中，表现得淋漓尽致。
最后总结了一个人物模型帮助大家清晰的理解不同时期需要参与的评审人员。
那了解了这么多设计评审相关的知识，如何能高效通过设计评审是关键，接下来就是顺利推进项目的流程和方法，掌握这些方法，按时下班不是梦。
为了大家更清楚的理清评审流程，我会从评审前的准备、评审中演示、评审后总结反馈，三个大方向去叙述。
1. 评审前准备
评审前的思考
评审过程中为何他人会质问和反对？，主要矛盾在哪里？对评审期间会出现的疑问要有一个大概预期。可以按照流程先自己从脑子里过一遍。
大致总结可以从以下方面先自己演练一遍：
- 这个需求要解决什么问题？用户类型是什么样的？能不能一句话说清楚
- 之前已有的功能的数据是什么样的？
- 我们的竞争对手是怎么做？有没有同类型的设计？
- 这个新设计和我们之前设计风格不一样，是怎么考虑的？能不能沿用之前的控件？
- 设计稿上面的内容是接近于真实的内容吗？如果不是可以改成真实的看效果
- 为什么使用这些颜色，在平台规范中没有出现过？
- 最后为什么考虑使用这个设计方案？
编排评审顺序和评审资料整理
相当于把评审节奏控制在你的手中，一切根据你制定的顺序进行，一般情况下，可以这样编排：
讲解「设计思路」，让大家先和你的思路对接起来，避免直接看到设计稿时每个人都从自己的角度出发。
编排设计稿的讲解思路，展示「核心页面的设计稿」，因为评审人数众多，如果设计稿状态很多，涉及到设计稿比较多，可以先把「核心页面」贴出来，让大家理解后没有问题，再把余下状态作为补充展示出来。
「整理待评审资料」
有了思路和编排，也尝试了自问自答，还可以和产品经理一起准备一些能够作为你背书的资料，能够帮助你在评审时，作为资料背书给大家展示，也可以供你快速查阅信息，方便回答问题。
以下是清单：
- 产品PRD：当有疑问时可以拿出来给评审者查看
- 设计分析文档：用来沟通关于行业内对于同类型功能的设计优缺点的分析
- 数据分析文档：用来展示当前版本数据上的表现和问题，以及可以帮助进行下一步改善
- 功能逻辑图：复杂功能可以使用图形化表现功能逻辑，便于评审者理解
- 用户路径图：通过用户路径讲解全局性问题，结合交互设计稿进行具体说明
- 交互动效演示文档：用来解释一些比较复杂的交互过程
- 配色情绪版：用来解释如何选择当前配色的思路
- 评审优先表：这适用于大多没办法进专家评审的情况，可以协助启发可用性测试。
评审优先表
这个可用性测试是京东设计团队经常用的评估方式。在评审过程中，专家可能需要用到设计原则（例尼尔森十大可用性原则）、行业领域竞品产品案例、前瞻性设计方向等建设性评估。书面文档建议内容尽力做到够详细，可以作为后续设计方案修改的参考性依据，可根据可用性问题的严重程度（高/中/低）排序。
这里评审优先表主要包括：用户体验问题记录表、二十一条可用性原则、系统可用性量表（SUS）
用户体验问题记录表
没有上线的环境下我们会找不同部门的先定性内测，内测主要使用的是用户体验问题记录表。
二十一条可用性原则
有了这21条，可以让任何没有用户体验知识的人参与到协作启发式评估中来了，一秒变专家了。当然，这21条可用性原则我们也会迭代优化，目的是做到更符合现今产品、更全面的可用性原则。
系统可用性量表（SUS）
由来：最初是 Brooke 于1986年编制，量表由10个题目组成，包括奇数项的正面陈述和偶数项的反面陈述，要求参与者在使用系统或产品后对每个题目进行5点评分。
SUS评分参考
从图中我们可以看出评分达到70分左右，就可以比市面上一半产品可用性要好，也就是说这个产品的用户体验算是合格了。
2. 评审中演示
讨论范围的把握
评审的关键是探索问题及讨论潜在的多个方案，帮助设计师拓宽思路并最终决策。
作用：评审中当发现大家的讨论范围跑偏了，主持人要及时把主题拉回来，而不是任由大家发散。
同事要避免提意见者直接给答案。参与者将会带有强烈的解决问题欲望，而且会在评审中提出解决方案。然而，最佳方案往往不会在评审时产生。
人物模型可以有效解决评审中，讨论范围的跑偏，在设计评审中规定好人物模型中参会者的发言时间和发言环节，引导大家去寻找更优设计方向和思路。
合理表述
在展示任何原型或设计稿之前，请从用户的角度讲一个简短的故事：在什么背景下，谁将使用这个的解决方案。
简明地抛出以下问题：
- 我们讨论的是什么类型的用户？
- 他们从哪里来的？
- 他们的心态是什么？
- 他们有什么强烈的情感吗？
- 他们想要达成什么目的？
在背景确定的前提下，现在是时候展示你的设计是如何解决这个问题了。在引导人们浏览流程图或原型时，无需说明显而易见的事情。最好保持安静，让他们沉浸在设计中；而不是指出为何决定将蓝色用作按钮颜色的，这些他们自己也能看懂。
对于模糊的修改意见，要善于发问，深挖提问者意见背后的真实原因。
你深入问下去，最终原因原来是，他认为这里不需要放按钮。这就涉及到一些产品功能架构方面的问题了。
一些好问题的例子：
- 你认为这将如何影响（项目目标）？
- 为了确保我跟上了你的思路，你认为做（建议）可以如何解决（用户问题）？
- 你在（基于他们最喜欢的应用的建议）时提到自己喜欢它。你为什么喜欢他们的做法？
- 你认为这样做的利弊是什么？
是的，我知道你来自哪里。我同意（他们提到的问题）是个大问题。你认为为何可以通过（他们的建议）来解决这个问题？
不幸的是，由于我们不能同时做到这两者，因此你认为（解决方案A）比执行（解决方案B）更重要吗？
感谢你提出这个问题。你是否看到用户的任何反馈表明（问题）普遍存在？
回应、决定、继续推进-推动评审的关键‼️
听完并提出问题后，看看谈话的进展方向，随时准备将大家拉回来并推动讨论继续。
多方案优中选优
尝试多方案探索。当你拿出几个方案去说，经过多方探索，最后认为方案三是最优解时会比只拿一个方案三去评审更有说服力。或许真正评审时只需要提出你的最终方案，但敲定方案前的方案ABC还是必要的，它将让你进行设计阐述时更有底气。
我们以一些大厂的设计评审为例
一刻相册中为了提升用户的浏览体验及效率，同时在视图方面也做了多种尝试，如下图：
最终选择原因:基于用户使用诉求和对相册产品的调研，选择了保持相册内容的比例统一，但对可动的livephoto及视频内容进行突出放大展示，并默认进行播放，这样既满足了效率问题，又让浏览体验更有节奏感，同时也兼顾了开发成本。
飞猪的风格探索
从40个字体版（或者更多）本中找到最优一版。
网易公开课改版的评论区设计
展示形式上，这次的改版选择了平铺式，即不区分子母评论关系，无论是对动态、对评论的评论，都视为平级 的评论。
底层依据助力设计阐述
在你进行设计阐述时，不是依靠口才和随机应变来处理各种质疑和反对。而是用扎实的底层依据来让所有人闭嘴。何为底层依据，即你为产品中后期的设计而进行的前期调研，竞品分析，用户建模等一系列围绕产品目标产出的数据。言之有物，拿出证据让设计阐述有理有据。
这里建议设计师去多看一下人人都是产品经理、大厂的公众号。会学习到很多改版思路和话术。
筛选合理需求
我们必须了解评审的意义所在，即求同存异取优，曝光问题，吸取意见，完善产品。
求同是大方向，最终目的是选取一个对内符合团队成员预期和能力，对外能够解决用户实际问题的优秀设计方案。
存异是了解各个部门成员对于设计方案的疑问，了解并耐心听完才能收获真正对产品有价值的提议。取优则是要求我们作为设计师有一个筛选合理的需求的能力。
诸如，这里感觉怪怪的，那里有点不舒服等这种没有任何建设性的意见可以直接忽略。什么意见可以吸取呢？一种是考虑到自身资源不能完成的指标或者优先级较弱的需求——「这里的动效过于复杂，技术实现难度大，时间成本高。另一种考虑到用户体验视觉效果但要求明确提出问题点——「这里字号过小，一眼看去很容易忽略掉」。
3. 评审后总结反馈
总结评审后意见反馈
会议评审过程中在讨论的同时也要收集意见，会议接近尾声将已达成共识的问题点记下来之后同步这些争议点，这样做一是让大家了解会议上我们有了这样的结论，是否有遗漏，另一个也可以体现我们的专业性。最后要预约下次评审时间，以便后续跟进。
按照优先级优化
筛选后的需求进一步的确认和理解，以保证理解的需求和执行的优化结果不会因为歧义和误导而返工。可以对于提出需求者进行回访，通过邮件形式询问他的需求和你的理解是否一致。
对最终列出的需求单进行优先级排序，用ergency（紧急性）importance（重要性）作为XY轴选取右上角的部分优先完成。
因为每个团队都有自己产品侧重点，我就不过多的说了，想了解的可以最后留言！
1. 准备工作不足
没有对设计主题准备充分的依据或来源，为什么要这么做？这么做可以解决什么问题？评审过程中很容易被反问而答不上来，导致意见被驳回，只能改了。
2. 意见发散
说整体风格的时候容易扯到icon，说icon扯到button，说button扯到颜色，容易打乱评审节奏，提前纠结在一些细节上。
3. 评审者的主观意见
每个人都有自己客观的思维。而品味、联想和诠释这三点是主观的，经常会听到「感觉不够上流」，「没有眼前一亮的感觉」，「这个颜色我喜欢，不过能再调亮一点么」等等。每个人有每个人的审美观，萝卜青菜各有所爱。
4. 缺少会议总结
评审过程中的问题没有得到一个梳理，郁闷中收集了一堆的意见反馈，后面也没有一个问题点跟进，只是默默的改…下次评审时间不确定，定稿时间遥遥无期…
5. 传达限制条件不完整
每个设计师负责的具体业务不一样，别人对这些限制条件的具体了解程度也不会有你来得深入，所以在评审会议上，他们可能会从更理想化的角度出发思考，给出和限制条件矛盾的思路、建议与解决方案。所以讲解自己的设计方案之前，也应当提前和项目组沟通清楚细节，把这些业务/技术上的冲突点清晰、全面地描述给团队其他设计师。
比如描述限制条件的根本原因，大家共同判断是否确实需要进行妥协，探讨是否有已经实现的现成案例来证明限制不存在，是否有能取得更好平衡的方案等。像技术限制，是组件改动困难（牵一发而动全身）？是实现成本过高（投入产出的性价比不够）？是影响速度等性能（实际用户体验不佳）？还是其他一些原因等；而如果只是简单说一句「前端/开发说这个做不了」的话，并不是那么令人信服。
6. 私下沟通跟进不到位
设计评审的会议时间最长也就几小时，在这么短的时间内得到的建议反馈，其实是有不少考虑不够周到全面之处的，而这些往往要到具体修改方案的环节才发现。所以除了发起评审之外，私下找其他熟悉业务的有经验设计师沟通探讨也很重要，这样得到的建议启发也更加成熟和思虑周全。
其实归根结底，做设计评审的主导者并不是让你学一些所谓的小技巧，阴谋诡计来躲避一些批评和反对。而是通过提高本身设计能力，提高设计方案的价值、核心竞争力（视觉或者交互、用研），提高自身的设计阐述能力，用有理有据的设计提案获得认可，助力产品设计，衔接产品设计的上下游，最终上线并为企业赚得利润价值。
要有一颗积极的、理性的心态来参与设计评审，否则很容易在评审过程中因为受到反驳而沉溺于消极状态！在大家对方案进行点评时也期待提出更好的建议和优化方案，大家的初衷还是最后能真的为用户解决掉一些问题，更多的还是有个更好的产品体验！
更多设计评审经验：
参考文章：
复制本文链接 文章为作者独立观点不代表优设网立场，未经允许不得转载。
郝小七
42.7w人气 7文章
热评 修真者 · 雷震子