一个完整的设计评审流程是怎样的？来看这篇总结！

一个完整的设计流程应该是怎样的？有哪些方法可以帮你做好设计评审？来看这篇干货！

一、「设计评审」的定义

「设计评审」在不同人眼里可能理解都有不同，有些人认为设计评审是以一种可用性审测工具，有些人认为设计评审是项目展现问题并给出解决方案的文本模式，有些人认为是项目工作流程中的一个协调性环节去协调项目中各个环节的痛点。对以上「设计评审」的定义总结，我们并不做深究，或者换另外一种说法我们认可设计评审都起到了这些作用。

那「设计评审」到底怎样定义才算最完整的，现在我们就用最传统的拆分理解的方法理解一下设计评审的意思。「设计评审」在汉语中是比较典型的名动&名名结构短语，其中的「设计」是一个名词，可以代表一切经过设计的事项，可以是设计过的原型，也可以是设计过的效果图，也可以是设计过的交互原型效果图，它都代表了一个经过设计过程后的产物。接下来重点是「评审」，可以是名词，也可以是动词。在名词的时候代表了一种以书面形式形成的总结性文稿，在动词的时候代表了一种修正动作状态。

所以，在这里我们对于「设计评审」的定义为，它会是一个工作流程中的一环工作状态，也可以是一个总结报告。它评审的内容包含了交互设计，界面设计， 用户体验设计。

结合「设计评审」中的名动&名名格式的变化，看成项目过程中的不同状态，那也就意味着「设计评审”应该在项目初期，中期，后期都会需要，是否每个环节都做应该是和项目的需求&体量挂钩。在不同项目阶段中的「设计评审」，应该对参与的设计评审人员设定也会有所变化。

接下来，我们就详细说一下日常在项目中的「设计评审」。

二、「设计评审」的时间&人员

项目初期一般是指项目完成了战略层、范围层阶段的工作后，所到达的框架层、结构层、表现层。如同定义中所概述的可以是信息架构图、任务流程图、原型图、页面流程图、效果图为评审内容。在初期这个时间段的设计评审，探讨更多的应是多种设计方向思路去实现产品的战略层方针，通过更多了解业务方向人员的参与，理解清晰产品目标。并为后期达到产品目标，打下牢牢的基础。只有通过更多的设计思路，对比、碰撞、摩擦才能找到更适合自己的产品设计方案。

建议参与设计评审人员：

• 方案1（推荐方案）：设计专家（UE/UI/ID） + 业务专家 + 产品专家 + 技术专家
• 方案2：设计负责人（UE/UI/ID） + 产品经理 + 业务经理 + 技术经理 + 前端负责人 + 后台负责人
• 案3：负责（UE/UI/ID） + （UE/UI/ID）

项目中期一般是指项目到了开发阶段，在前端和后台完成了主要功能页面的阶段。在这个阶段已经有了确认的设计方案，并按照这个设计方案实施了。所以，这一阶段的「设计审核」目标更多的重心是关于现有方案中的优点和欠缺（没有一个设计方案是完美无缺的）。最好，在优点的方向是否还有更多延伸性亮点，在欠缺方面虽然在定稿前就已经知晓，但是否在项目的建设中了解了更多现实开发情况下，能够有足够的时间把欠缺解决。总之，在这个阶段的审核，已经从多个设计方案思路的筛选，孤注到现有确定的设计方案中去开展设计思路的延伸，优胜略汰，使方案变得更有潜力。

议参审：

• 方案1（推荐方案）：设计负责人（UE/UI/ID） + 产品经理 + 业务经理 + 技术经理 + 前端负责人 + 后台负责人
• 案2：（UE/UI/ID） +  +  + 
• 方案3：设计负责人（UE/UI/ID） + 设计师（UE/UI/ID）

项目指项目或者测阶，已项目。此刻「审核」益求，磨细节，则判断案落程否存问题，并各（互&视&验）迭迭案。

建议参与设计评审人员：

• 案1（案）：负责（UE/UI/ID） + （UE/UI/ID）
• 方案2：设计负责人（UE/UI/ID） + 产品经理 + 业务经理 + 技术经理 + 前端负责人 + 后台负责人
• 方案3：设计专家（UE/UI/ID） + 业务专家 + 产品专家 + 技术专家

三、「设计评审」的方法

1. 专家评审

「专家评审」一般会作为在项目初期和项目后期中出现，经由各个专业方向（业务/产品/技术）组成，旨在通过专家丰富的专业领域的案例&技术经验，通过对项目的设计方案的评审，为项目带来启发性的引导。提供更多的设计延展思路，并能够简短的做出总结性的利弊说明。相比其他的方法，专家评审会更希望通过评审人员所在行业领域的专业知识、工作经验、行业前瞻性思维去带动项目在设计方案的多样性、项目开发中的优先级、与产品目标是否达成一致性、是否违反了常见的可用性原则&认知心理学等。所以，这一评审的方法才叫做「专家评审」。

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

审模：《户验升模》

2. 基础标准评审

「基础标准评审」内容更偏重于界面视觉设计，所以在项目设计方案 UI 视觉稿已经有关键页设计方案后进行，焦点专注于表现层设计较多。对产品的 UI 质量进行细致的检查，希望设计方案能有更多的规范性、交互性、复用性、完整性。力争在界面视觉设计上做到尽善尽美。

：界，基户习惯规范。 VI ，黑&宋，英衬衬。需注界 UI 展，越越细节，仅需注、距，需注、版阅读舒。

颜色：对于颜色的设定一直是设计方案中占比最高的评估对象，我们经常会看到同行业的竞品用的颜色都基本固定在三个颜色中，很难看到差距感。原因在于首先颜色本身在用户区别产品中起到了很大的作用。在这里，我们省略一下颜色中的基本知识，三原色的构成、冷暖色调的分别、中间色的高级感等，希望大家更关注情绪板的作用。情绪板本身是从平面设计中的设计方法，在界面设计中得以利用，从中获取颜色的灵感。

编者注：情绪板学习指南 → https://www.uisdc.com/find-customers-like-the-visual-style

图标：图标在界面中的地位是不可忽视的，就像驾车途中的指示牌，清晰的为用户指出下一个路口，还能够成为沿路风景中的一景。从最初的拟实图标，到后期的正形图标、负形图标、扁平图标、轻拟物图标、2.5D图标等。图标的设计风格随着界面设计风格的多变也随之改变着。可能以前的界面设计，图标基本都只有一种风格类型，但随着 APP 的功能多样性，现在在一个产品中，也可以有不同风格的图标用以区分功能属性的不同。

图标自检和优化指南：

1. 《腾讯设计师总结的图标设计五维自检法》
2. 《顶尖设计师分享的6个图标设计优化指南（上）》
3. 《顶尖享6图标优指（）》

图片：图片风格和颜色风格设定都可以使用情绪板的设计方法去设定，图片的设定往往最直观的让用户感受产品所希望带给用户的感官体验。图片设计从图片的风格、大小比例、排版出发，围绕着产品业务属性，不断的提示用户产品具象信息。

空：空，距&版，，界互（例弹框、模框、项卡）。善界互空，增页呈，兼顾页结构。

组件化：组件化设计思维核心是为了提升设计效能，通过对业务功能需求的分析与设计元素的结合，形成可复用规范化的组件。可能有些人会质疑组件化会不会带来设计太单调的视觉结果，回答肯定是否定的。组件化的目的是为了让设计保持一致性，并通过同样规范的组件拆分合并，从而也能形成新的组件、新的页面。组件化的设计应从统一性、扩展性、逻辑性出发打造产品专属组件，以结合自身产品业务功能需求，达到好的用户体验。

组件化设计指南 → 《进阶必读！可能是最全面的组件化开发与设计指南》

用户体验：好的产品应有好的用户体验，好的用户体验最重要的就是易用性与易懂性。易用性在于用户是否能快速发现交互方式的方法，交互之间不会有互相矛盾的地方。易懂性在于用户在完成一连串交互任务后，想去查询反馈结果时，也能在产品中得以体现。交互体验的评审首先得注重于可用性，其后可关注于转化率、PV、UV 之间的关系，制定产品目标，通过反馈数据&测试用户（专业&非专业）的反馈，进行迭代。

3. 系统可用性量表

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

为什么使用 SUS（系统可用性量表）？

• 量表公开免费。
• 整个量表题目陈述简单，只需参与者打分，实施起来很快。
• 测量结果是介于0-100之间的分数，容易理解。
• 测户界，页、、。

△ SUS（系统可用性量表）

注意：在使用 SUS 的过程中，可以对题目的词语进行替换，这些替换对最后的测量结果都没有影响。比如「system」可替换成网站、产品或者自己产品的名称等。

SUS（系统可用性量表）分数

当参与者做完一系列任务后，就可以快速对 SUS 进行打分。然后就需要对每个题目的分值进行转换，奇数项计分采用「原始得分-1」，偶数项计分采用「5-原始得分」。由于是5点量表，每个题目的得分范围记为0~4（最大值为40），而 SUS 的范围在0~100，故需要把所有项的转换分相加，最终再乘以2.5，即可获得 SUS分数。将 SUS分数换算成百分等级来解释，百分等级的意思是指测量的产品或系统相对于总数据库里其他产品或系统的可用性程度。

△ SUS评分参考

从图70左右，半，户验。

注，数据库 Jeff Sauro（2011）446研究，5000户 SUS 反馈数据库。从企研究，沉淀往研究，立企或系统 SUS数据库，从获身基准数据。，基准数据。

三种设计评审的方法，对应的项目体量，项目周期各有不同，也适应于不同评审人员，从中我们可以看出，设计评审围绕的核心因素还是用户体验设计出发，以用户体验为核心展开评估工作，并对其可用性、标准型、规范化做出相应合理的提升报告，高效的完整设计评审工作，使产品设计能够和产品目标保持一致。

四、「设计评审」的延伸

设计评审作为一个项目设计阶段性成果评估结果的体现，所以评审人员也会有所要求。接下来，让我们另外说一下参与设计评审工作需要的一些横向能力。

作为设计评审中的成员，首先得所有人必须都清楚了解产品目标。以围绕着实现产品目标展开讨论，并给到好的建议。

产品相关设计人员，一定在设计项目之前，需要有一个比较好的前期竞品分析的过程。我们正在做的产品，能够带给用户什么样的服务？服务的类型是什么？是什么业务功能导致了用户需要用我们的产品？在这一过程中，可能考验我们的并不是视觉设计的能力，更多是对不同业务的理解反应速度、强烈的产品发现意识、用户体验、流行趋势等。

业务逻辑往往会被界面设计所忽视，有过一定设计经验的设计师，应该清楚。好的设计师往往对于业务逻辑会有很深的认可，业务可以驱动设计变得更好。同样的业务在不同的交互设计、界面设计中所让用户感知的业务强弱也会不同。只有深刻了解了业务才能够既保证实际业务操作规范化的同时，在用户交互上做到最简单直接。

，往往流程（例注册/登录/改密码）纠结，流，例首页引流终订系，弱，融财、险、贷，游俗习惯导致住优先序。，，互视，从细节户，户领域，往往户。

所以，在启动项目会议中，了解了产品业务类型、用户群体，应马不停蹄的开始调研竞品。竞品的选择，如没有得到很明确的竞品清单，可通过在 APP STORE 中的分类寻找同分类的竞品，还可以找一些临近行业的 APP 排名靠前的产品做分析。

竞品分析方法  → 《如何做竞品分析？来看这份超全面的指南！》

前端实现是很多项目在实施过程中，会碰到比较棘手的问题，往往会碰到设计稿和前端实现后的效果不符，大于百分之十的差异，我们基本可以称作为事故了。解决这个老大难的问题，一方面我们尽可能通过前端技术去实现设计效果图，另一方面这里对设计师的要求，可能设计师不需要会写前端代码，但前端实现的原理及时下前端流程语言框架，UI组件的了解度要够。在做设计的同时，也不要给前端实现人员留坑，导致项目进度影响与页面交互的混乱。

举例，我们可以不会做水泥，不会造房子，但最起码知道造房子需要经过挖基坑基槽做基础，做主体，做装修，屋面的流程。前端也是如此，图片过大会引起页面加载过慢，背景的自适应屏幕大小问题，标注的单位随着屏幕硬件越来越好，也需要改变等。

视稿落法 → 《决13问题，99.9%稿》

A/B test 是产品在迭代过程中，遇到不可预估的迭代结果，导流目标用户给到两个入口进行数据测试，以查看哪个设计方案更佳。为什么在这里提到 A/B test，一方面给到评估工作出现的不可预测结果的两个方案的解决方法，另一方面也鼓励所有设计人员抱着科学包容的态度去提升产品的设计，让用户的体验提升自身产品的不足。

最后，「设计评审」往往在实际的项目中，出现过于主观评审或过去简单的处理，那只能满足于垄断行业的产品。如果随着产品行业的竞争越来越激烈，对于设计工作越来越先进的方法论&工作流，设计评审更应该是打磨产品中必不缺少的设计工序，希望设计师们能够体会到。

欢迎添加作者微信：