设计师如何主导设计评审

一 评审前

设计师在设计评审中提案就像冰山露在海面上的部分一样，其实只是一小部分，而设计过的方案可能就像海面下更大部分。因为设计本身是一个发散和创造的过程，会有很多种方法达到产品目标。而设计师的工作就是在众多方法中寻找到最优的方案并呈现出来。如果在设计评审前没有把诸多方案想透的话就参加评审，评审中很容易出现方案被质疑的状况，被质疑后方案可能还需要重新做，浪费了时间也浪费人力。因此，在设计评审前一定要尽可能探索所有可能的方案，否则不如推迟评审时间。

1. 方案自茶

1.1 视觉可用性

视觉可用性可以大致分为 布局可用性、图标可用性、颜色可用性。

以布局为例有三角构图、均衡构图、对角线构图、网格、栅格化系统布局、斐波那契数列等。而图标断点，圆角，粗细是否统一，如何在图标设计中融入品牌风格又是另一个考虑方向。产品主色调和辅色的选取，单色系还是多色系，分割线的灰度，按钮三个状态的颜色划分（选中、未选中、不可选）等等。

无论是布局、图标还是颜色，我们都应该考虑这三个方向。

操作：视觉上可点／不可点的状态设计存在误导，致使用户进行误操作，按钮像按钮，字段是字段。

知觉：重要文字或图标过小，用户难以察觉或直接忽略，可以参考ios11的设计理念，head1、head2字号放大并加粗，强化视觉层级。

认知：对图标图形的理解出现歧异，有悖设计初衷，不要为icon添加过多细节，尽可能的简洁符合用户认知，参考同行业的竞品或iconfont网站，保证icon传达正确的语意。

视觉可用性这一概念或者说方法论涵盖内容领域很广，包括各类专业性测试方法，推推荐进行系统的学习。

1.2 产品体验

集中在信息架构、交互逻辑上的梳理。

设计方案还未开发成为实际可操作的产品，此时设计师（针对交互设计师）手里可能是低保真草图或者高保真的交互稿，上层对接的是产品经理的需求文档。

此时待验证的第一部分是：作为交互设计师对于产品经理的需求文档甚至原型（部分公司PM出原型交互只负责优化和完善）的优化部分。作为设计师的职责不是完成产品经理的需求，需求是个人的，我们的任务是完成产品目标而不是某个人的需求，换言之产品经理的需求并不是完美的不是最终要去执行的。作为设计师要有自己对产品设计见解，这个见解要贯穿整个产品设计流程包括产品经理负责的部分，因此，有什么疑问或者优化的方案，大胆的提出吧。可以选择评审前和产品经理单独沟通来确认方案可行性，也可以在总体方案评审时拿出来接受审核。

待验证的第二部分当然就是对接的产品的需求，这是你们达成共识一起决定的产品设计的方向，大方向获得认可的基础上待验证的就是一些细节部分，设计细节，交互逻辑，界面跳转等等，同时也能收到来自团队其他部门诸如运营技术的意见，来确定方案的其他未注意的细节和需要完善的地方。必要的话可以拿出之前所做的内容模型，故事版，用户画像等用研调查来进一步阐述设计方案。

值得一提的是，交互方案上对于成熟竞品的借鉴不是丢脸的事情。竟品3步完成支付流程的交互方案，明显优于你的四步五步，那没理由不去“抄”。一切围绕产品设计，围绕优秀体验，其他都是虚的。

2. 思考与沟通

评审过程中为何他人会质问和反对？，主要矛盾在哪里？对评审期间会出现的疑问要有一个大概预期。

2.1项目组成员角度（同事反对不利于其自身的设计）

如果与会者各种反对意见，问题出在哪里？你的设计真的无用（真的那无话可说）还是其他人员故意刁难？第一点，作为同一项目组成员，大家努力方向一致，为了优秀的用户体验，为了极致的产品设计而努力，没有人闲的没事找你麻烦。问题是，多数人更加在意的是自己负责的工作部分，自己业绩的来源，自己遭问责的来源。产品会考虑产品上线节点是否和许诺给老板的一致；运营会担心是否有足够的广告位投放广告来保证曝光率；技术考虑实现难度等等。

尊重和认可是互相的，你的设计没有充分考虑产品闭环中的其他介入人员，没有为运营提供足够的产品曝光机会，没有考虑技术开发的难度、实现的可能性。其他人员也就没必要尊重你自以为是的设计，没必要碍于你的面子而不提出对于产品设计方案的异议。

这是第一个维度，即产品开发纬度。一个产品创意再优秀也需要开发出来才可以上线盈利，才可以被认可为优秀的设计并服务于一批人，同时让团队公司生存下去。我们的设计在服务用户之前，首先要根据本公司的资源、能力得出可行的实施方案。这要求我们对团队成员的能力、真实需求有足够的了解，通过沟通提问可以很好的解决这一问题。

因此，在设计之前，团队各个部门成员一起开会商讨是很有必要的，如果难以调动小组会议可以采取群发邮件的方式探寻各部门成员的需求和对本次设计的预期。得来的需求和一些特殊要求要用心的融入产品设计中而不是走形式的去询问。

最终进行设计阐述时，我们会说：运营同学提到之后需要足够多的广告位来曝光产品，因此我们选择了界面的这个部分提供给运营同学投放相关广告banner。或者这样：我们充分考虑到技术开发的难度及有限的时间，因此选择了所有方案中最节省开发人力，保证上线时间的方案三。如果你是对方，会不会有点小感动。

2.2 服务用户角度（设计方案有没有良好的视觉效果或用户体验）

当然，即便你再为同事着想，结果设计产出本身巨丑无比或者体验极差，对不起，该骂还是骂，恕我直言，垃圾。

这便是第二个维度，即用户拿到的产品如何，视觉效果是否及格，用户体验是否优秀。设计评审时，你的视觉或者交互做到离行业平均水平还要低，团队成员首先被恶心到了，打死也不想去开发这样的产品。作为设计师的本职工作没有做好，评审铁定不过。

不同公司评审设计的方法也不同，有不专业的情感化评审，经验化评审。也有大厂沉淀后的专业评审方法。但不外乎就是两个维度：视觉可用性，产品体验（交互和用户体验方向）。

3. 其他

3.1 避免与评审者感知脱节。

先找产品经理再次确定目标，与产品达成一致会让评审高效，有问题产品可以代为回答。如果可以也找前端确认实现成本等问题。会议前的各个角色的沟通越多，评审越高效。

3.2 编排制作评审展示顺序与整理设计思路。

先讲解思路让大家与你对接起来，避免各从个人角度触发。然后展示核心页面，理解或达成一致之后在展示各状态页面与补充页面。设计思路尽量做到理性合理。

3.3 预先考虑评审者提出等问题

• 为什么最后考虑使用这个设计方案。
  
• 这个需求解决了什么问题，能一句话说清楚吗
  
• 之前已有的功能的数据是什么样子的
  
• 我们的竞品是怎么做的，有没有同类型设计
  
• 新设计与之前的不一样是怎么考虑的，能不能沿用之前的控件
  
• 元素对齐是粗心还是有意为之
  
• 为什么使用这些颜色？
  

3.4 整理待审资料

产品PRD / 设计分析文档 / 数据分析文档 / 功能逻辑文档 / 用户路径图 / 配色情绪版 。。。

二 评审中

1 . 明确问题与设计目标

如上图所示，讲述方案前要把设计要解决的问题，要带给用户什么样的体验（这需要和产品经理和整个团队达成一致）和支撑设计的数据和经验判断先明确出来。

见过很多设计评审中，为某个细节讨论不休， 各说各话，没有在一个层面上讨论。 如果明确了设计目标的时候，设计师在讨论混乱的时候，可以回顾设计目标，把大家拉回正确的方向。而支撑设计的数据和经验判断，则起到了两方面作用；首先帮助设计师讲述方案时显得有理有据，其次让讨论更加有效，评审人员可以更加明确的讨论是数据和经验判断有问题，还是设计表现上的有问题。

2 . 一些技巧

2.1 筛选合理需求

我们必须了解评审的意义所在，即求同存异取优，曝光问题，吸取意见，完善产品。求同是大方向，最终目的是选取一个对内符合团队成员预期和能力，对外能够解决用户实际问题的优秀设计方案。这要方案获得所有人的认可，才能为一个共同目标努力。

存异是了解各个部门成员对于设计方案的疑问，了解并耐心听完才能收获真正对产品有价值的提议。取优则是要求我们作为设计师有一个筛选合理的需求的能力。诸如，这里感觉怪怪的，那里有点不舒服等这种没有任何建设性的意见可以直接忽略。什么意见可以吸取呢？一种是考虑到自身资源不能完成的指标或者优先级较弱的需求——“这里的动效过于复杂，技术实现难度大，时间成本高。“另一种考虑到用户体验视觉效果但要求明确提出问题点——“这里字号过小，一眼看去很容易忽略掉。

2.2多方案优中选优

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

2.3 底层依据助力设计阐述

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

2.4 正常的阐述逻辑是

首先展示等有助于理解产品背景，产品目标的数据信息。帮助大家理解我们的整体设计目标，提供一个大方向的引导，带动大家融入接下来进行阐述的语境。

接下来展示对我们产品设计的分析，诸如用研结果、竞品分析，用户画像等可以支撑我们的产品设计为之提供指导的所有数据都是值得分析和借鉴的。

2.5 引导大家去寻找更优设计方向和思路

　　引导大家寻找更优设计方向和思路，在设计评审中至关重要，可以说是精髓所在。有很多人错误的认为，设计评审的不过是评审一个设计方案，如果感觉不错就开始开发，如果感觉不行就打回去修改。作为设计师，应该明白设计评审可以给自己带来的帮助，在评审过程中要引导大家去寻找更优设计思路，这里需要注意是思路而不是方案。正如前文所述，评审的意义在于寻找更多的更好的方向，最后由设计师根据反馈改进提出一个最优的方案。如果在评审中提出了解决方法，这种在短时间思考出来的方法，很可能因为思考不周全而存在这样或那样的缺陷。同时也失去了让设计师去思考更优方案的机会。

2.6 识别好的反馈和坏的反馈

接收反馈的第一步就是过滤掉糟糕的、无价值的或者破坏性的反馈。 不良反馈的一些特点:

坏的反馈集中在解决方案上, 而不是问题本身。类似”你应该使用汉堡菜单”这样的评论可能会过快地跳入一个解决方案。 向人们询问他们看到的问题, 而不是他们想象的解决方案

不好的反馈包括个人喜好和厌恶。主观性应该远离意见采纳范围以内。 每当你开始听到”我喜欢”和”我不喜欢”这样的话题时, 把讨论带回到你试图解决的问题上来

糟糕的反馈是针对设计师的, 而不是设计的。如果你开始听到诸如”你的布局”或者”你选择的颜色”而不是”布局”和”颜色的选择”, 那么有些事情是很奇怪的。 摆脱这种情况并避免有害的直接反馈的最好方法是让其他人参与到谈话中来, 看看他们是否都同意他们说的话

一个防止不良反馈出现的好方法就是在每次会议开始的时候都要回顾一下设计目标。 我们在这里试图达到什么目的？ 我们在这个过程中处于什么位置？ 我们希望今天讨论的反馈是什么？

2.7 讨论你收到的反馈

当你得到良好的, 或相关的反馈, 下一步是确保你与你的同伴讨论它。 年轻的设计师倾向于直接把反馈作为立即行动动机, 而没有进行适当的讨论。 这就是团队最常用的循环方式: 立即处理那些没有得到适当讨论、思考和同意的反馈。

多听少讲， 这是收到反馈的第一条原则。 确保你全心全意地倾听和关注你的同事或客户所说的话

清晰了解问题。 当你收到的反馈意见忽略了正确的基本原理时, 问一些能够消除模棱两可和怀疑的问题。 “你对这个菜单有什么特别不满意的地方, 是不是还有一种你更喜欢的菜？ 是什么让你更喜欢那个?”

把反馈写下来。 这不仅表达了你对你得到的反馈的欣赏, 而且还帮助你记住第二天的细节。 确保你收集了所有你需要行动的细节

创建场景。当讨论变得过于私人化时, 提出真正的用例可以使会议回到正轨。 “让我们考虑一下我们的角色,, 想象他们来到这里, 试图找到我们的产品。 你认为他们会在哪里点击?”

推动达成共识。 两个人占据设计评审会议时间来讨论一个特定的观点是很常见的, 但是对于设计师来说, 确保其他参与者也同意正在讨论的内容是很重要的。

2.8 设计方案得到认同时，引导大家讨论方案中风险点

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

三 评审后

1.将会议记录汇总并以邮件形式发送给各位，需要谁确认或执行的，最好标明到具体责任人。特别是产品经理。一方面，防止会上确认的内容被遗忘，也便于后期在制作交互稿的时候，进行参考；另一方面，立字为证，防止需求的随意变更。

2.筛选后的改进需求进一步的确认和理解，以保证理解的需求和执行的优化结果不会因为歧义和误导而返工。可以对于提出改进建议者进行回访，通过邮件形式询问他的需求和你的理解是否一致。对最终列出的需求单进行优先级排序，用ergency（紧急性）importance（重要性）作为XY轴选取右上角的部分优先完成。

3.针对会上问题将调整好的设计文档重新上传并告知大家修改内容。预设下次评审时间