我承认标题过分了，但大致意思没错。作为设计师的你参与设计评审是否提心吊胆，担心各种来自产品、技术、运营等项目组成员的质问，疑惑乃至反对。最终将设计方案扁得一文不值，不伦不类？如何在设计评审时强硬而有底气完成设计阐述，获得成员认可？

评审前的思考

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

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

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

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

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

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

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

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

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

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

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

视觉可用性

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

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

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

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

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

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

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

产品体验

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

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

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

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

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

评审中的技巧

筛选合理需求

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

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

多方案优中选优

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

底层依据助力设计阐述

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

正常的阐述逻辑是

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

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

了解产品背景和我们对于设计的预期，接下来展示最重要的设计方案。冷静的进行阐述，语速不宜过快，围绕方案前提到的设计依据展开，注意逻辑。

听取建议，筛选需求，解答疑问。

评审后的优化

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

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

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