前言
设计方案进入评审阶段 ，意味着前期的深专需求定义 、方案发散 、家样讲好计方原型设计已经基本结束 ，年资即将交付开发。深专设计评审是家样讲好计方连接前期构思和后期实施的关键环节 ，在需求的年资生命周期中有着里程牌式的意义。
然而 ，深专面对设计 leader 和专家讲述自己的家样讲好计方设计方案 ，无论对于萌新还是年资老鸟都是一种巨大挑战 。我们不仅容易心态上会犯怵，深专还可能遇到不知道怎么讲解方案 、家样讲好计方回应建议等诸多问题 。年资因此，深专这篇文章结合我自己 8 年作为评审人&被评审人的家样讲好计方经验教训 ，聊聊如何才能讲好自己的设计方案 。
需求规模不同 、所处阶段不同，评审的目的就可能不同 。按照目的来区分 ，工作中常见的设计评审，评审的类型大体有「方向评审」和「方案评审」两类 。
第 1 类 ：设计方向评审
图 1. 我在做正确的事吗
一些规模大 、复杂性高的设计需求 ，有必要在设计方案输出前进行一轮方向评审，目的在于确保“如何将事情做正确” 。评审的内容主要是基于需求背景的阐述 、设计目标和竞品方案的分析 ，草稿、线稿的绘制 ，确定大体的设计思路和方向 ，以确保在后续方案的设计中不要跑得太偏。
第 2 类 ：方案细节评审
图 2. 我将事情做正确了吗
这类评审在设计工作中最为常见 ，一般是在全部设计方案完成以后 ，目的在于确保“将事情做正确”。按照评审参与人的不同 ，评审的侧重点又可以额分为两种 。
①侧重评估方案合理性
主要由设计经理、其他设计师参与 ，一般会简单同步需求背景和设计依据 ，并将重点放在操作流程 、界面设计上，对比讨论不同方案的优缺点 、发现当前方案中的细节问题，通过评审的方式完善设计方案 。
②侧重评估方案可行性
一般由项目组的产品 、开发 、运营参与评审 。此类评审一般会简单同步设计分析过程 ，重点阐述方案设计细节 ，以帮助下游理解设计方案 ，在此基础上讨论方案可行性 、提前暴露后期实现风险，确保项目正常开展 。
评审的形式一般是开会 ，而大家参会是有时间成本的 ，因此做好评审前的准备工作 ，就是对他人的时间负责。当然 ，组织评审的前提是能解的问题已经解了、要做的方案已经做了 ，评审是就自己发现不了的问题或决策不了的方案进行讨论 。在此基础上 ，评审前一般需要进行如下准备 。
①背景信息的补充完善
参与评审的人并不一定会了解需求背景 ，比如有时我们在前期沟通需求的时候 ，是和产品经理口头聊的、有些数据资料我们是自己在报表中查的。因此评审前最好将这些材料简单整理并同步给大家 ，帮助大家更好地理解需求背景和约束条件 ，更加高效地决策 。
除了整理已有的资料外，有些需求的业务逻辑或交互流程非常复杂 ，当逐个去讲页面的时候大家容易可能不太容易理解。此类需求我们有必要简单梳理下流程图 ，以便参与评审的人能够快速了解需求的全貌 ，定位评审的重点 。
图 3. 用流程图帮助大家理解流程
②设计方案的自检
评审前首先需要确保的 ，就是不要存在很多“低级错误” 。比如是否有错别字 、该对齐的元素是否存在没对齐的问题、该和线上组件保持一致的地方是否有保持一致 、是否存在字号太小看不清的情况等等 。提前解决这些问题 ，不仅能提升评审的效率，而做不好，则不仅浪费大家的时间 、也容易给人造成设计草率的印象 。
③提前和上游同步方案
设计作为需求的承接者 ，评审的设计方案应该是要提前同步给上游的产品或运营人员 。一则是因为业务方的诉求和也是评审的考量因素，而是可以避免方案评审通过了 ，但上游产品人员不认可的问题 。
除了同步上游外 ，如果设计方案的难度大 、复杂度高 ，也需要提前知会开发同学，以了解是否可以实现或存在何种风险。如果自己不是项目的主设计师 ，还应该和主设计师对齐方案 ，避免让评审成为两个人的会议 。
④确定评审的时间节点
评审的时间节点一般在设计的后期 、策划定稿之前，不一定非得完全定稿再评。这是因为 ，一旦我们本着“这个方案定稿了”的态度去评审，就很难再接受他人的建议 ，从而将评审会变成宣讲会 ，参会的人也会有一种“既然你都定了还叫我来干嘛”的困惑 。
图 4. 评审的时间节点
⑤邀约评审人
任何会议中 ，让谁参与评审都是很重要的 。拉了不相关的人来评审 ，浪费了对方的时间还达不到评审的效果 。总体来说 ，评审要邀约的人 ，是对设计方案的整体 、或细节有决策权的人 。按照不同的评审目的 ，评审需要要求的人分为以下两类 ：
1. 讲解设计稿的整体思路
讲设计稿的时候，有的同学会一上来就讲我做了一个某某落地页 、页面头部有哪些元素 、点击某个按钮会打开某弹窗等 。除非在坐的所有人都对这个需求非常了解 ，且知道你的设计过程 ，否则 ，一上来就讲方案是一种典型的错误做法 。
在大部分情况下 ，参加评审的人可能对需求背景和设计过程并不了解。因此 ，讲解设计稿最好还是按照黄金圈法则去讲 ，即 ：为什么做这个需求 、要解决什么问题 ，再讲自己采用了何种设计方法 、具体怎么分析的 ，最后讲具体方案是什么（详细讲解过程见下文）。
图 5. 讲解遵循黄金圈法则
2. 讲解设计稿时的具体顺序
STEP1 需求背景介绍
这部分主要是在回答“为什么做”的问题 。一般可以从用户侧和业务侧两个方面来介绍 ，即“用户为什么会有这个需求”以及“满足这个需求能给产品带来什么”。
一种常犯的错误是 ，介绍背景的时候只讲上游的诉求 ，给人一种“我只是承接了个需求”的感觉 。相反 ，我们应该更多讲自己对需求的理解 ，从用户视角去讲解为什么用户有这个需求、典型的需求场景等 。
图 7. 以用户视角介绍项目背景
STEP2 简单讲解设计过程
实现需求的方案往往不会只有一种 ，设计最终给出的方案往往是根据设计目标 、数据表现 、规范约束 、实现成本等方面综合评估后的结果 。为了让评审的同学更快速地理解为什么是最终这个方案，有必要对设计的过程进行简单介绍 。当然 ，为了评审效率 ，我们没必要一上来就讲太多的过程 ，而是建议过程简单过一下 ，如果对方案有疑问 ，再回过头来补充讨论过程即可 。
STEP3 按照用户的行为路径讲解方案
设计不只是画几个界面，而是利用界面来帮助用户完成任务的过程 。有些同学在讲设计方案的时候容易忘记交代需求的具体场景，而是一上来就进入到 ：页面有哪些元素，点击哪些元素有什么反馈。这样可能会给大家一个困惑 ：用户怎么接触到这个页面的 ？要进来干吗 ？也就难以代入用户的需求和目标来评估方案 。因此 ，我们在讲的时候需要从用户的使用路径来，比如用户会在哪些地方接触到入口 、进入页面后的主要任务是什么 。
图 8. 按照用户行为路径讲解
在讲解任务流程时 ，注意最好先讲主要任务流程 ，再讲分支流程 。比如对于搜索来说其主要任务流程就是输入点击搜索 icon→输入搜索关键词→浏览搜索结果→查看结果详情 ，分支任务可能包括搜索历史词的管理 、无痕模式的开启等 。
3. 应对意见和建议的方法
评审的目的就是要让大家提出自己的见解 ，帮助我们发现自己方案中的问题和改进点，但我们面对他人的质疑都会本能地捍卫自己的方案 ，从而让评审变成一种宣讲。为了更好地应对他人的建议 ，我们可以训练自己按照以下的顺序来应对建议和意见 。
图 9. 应对设计建议的方法
此外 ，在设计方案中有意见分歧很正常 ，甚至会出现各抒己见而难以决策的问题 。如果出现这种情况 ，原则应该由在场的具有最高决策权的人拍板 ，或者会后进一步研究 ，避免在一个问题上浪费太多时间 。
1. 清楚说明评审的范围
UI 或视觉的设计 ，有些时候是针对页面上的某一部分做的优化 ，因此评审的时候最好提前说明清楚具体优化了哪些，避免大家讨论了半天 ，才发现不属于本次优化范围的情况发生 。
2. 避免成为“快嘴王”
评审时被一堆眼睛盯着 ，大家会习惯性地紧张 ，一紧张就容易语速加快 ，以至于大家想说话都插不上嘴 。但这样不仅违背了评审的目的，也会让参加评审的人无法或不敢提出想法 。因此 ，我们一定要养成在讲解中停顿的习惯 ，讲完一个模块稍作停顿 ，或征询下他人是否有建议再继续 。
3. 给大家一个可以讨论的“靶子”
有些需求比较复杂 、操作流程也比较，对每一个步骤逐一讨论没有必要 ，这时评审人最好能在讲的过程中强调下本次评审的重点或需要讨论的地方 。比如对比方案 A 和方案 B 的优缺点 、流程上的改动点等，以便大家能快速聚焦于关键问题 。
图 10. 需求待讨论点示例
4. 控制问题的讨论时间
评审组织者需要控制评审节奏以使评审尽量高效。一个具体的问题 ，讨论一般在 5 分钟内结束 ，比较重要的问题讨论也不要超过 10 分钟 。时间过长的讨论，不光已经提不出新的观点和论据 ，还容易让大家陷入情绪对峙 ，从而忽略了更重要的问题 。
5. 记录待解决的问题
需求规模越大，评审的意见就越多 ，因此我们要做好意见记录。记录时应善用在线协作工具（比如 figma 的评论） ，免得问题太多而被遗忘 。需要会后解决的重要事项 ，也应该在有结论以后给相关方及时回复 。
本文围绕着设计评审这一项目流程的重要环节 ，从如何做好评审前的准备工作 、到如何讲好设计方案 、以及如何应对日常评审中出现的常见问题给出了若干建议 ，希望对大家讲好设计方案有所帮助 。
最后，虽然「评审」两个字听起来像是一种让人压力山大的审核 ，但我们更多应该将其视为一种「评估」 ，一种对方案优劣势 、方案上线风险的前期评估 ，这样我们或许可以以更积极、更轻松的心态面对它 ，利用这种形式帮助我们更好地「做好设计」 。
作者 ：VMIC UED
