复盘：设计评审会需要注意的几点问题
最近进行了一次设计方案评审，中间过程比较纠结，所以有必要复盘总结一下。
先说一下结果，我的主推方案未通过，需要按照运营方提供的设计修改。因为运营方强调“他们是业务指标承担者，要以他们的需求为准”。加之他们领导的鼎力支持，于是设计方认怂。
不过也并不是没有一些好的苗头，素来强势运营方开始解释他们的一些想法（或许仅仅是我个人的自我安慰）。
本篇文章反思内容主要包括：
- 评审会前的准备
- 参会人员级别匹配
- 会议中的应变能力和情绪把控
- 设计师话语权思考
先说下项目背景
1. 需求提出
需求自上而下发起，运营方提出改版需求，首先收集了运营内部，产品经理，设计三方意见，总体来说大家的改版方向比较一致。后来运营组织了沟通会，通过一份线框图介绍了需求内容。会后又提供了一份更加详细但不标准的线框图。
2. 流程及场景补齐
根据运营方提供的需求和线框图，产品经理进行了一定的优化和补充，包括增加了部分规格说明以及购买支付流程。但是整体上维持了运营方的设计方案。
3. UED设计输出
根据产品经理整理的需求内容，UED正式启动方案设计。综合前期的调研和设计分析，UED在方案设计时，对运营方案进行了优化调整。为了避免评审中运营方产生激烈的反应，UED团队最终输出AB两套方案，A方案为UED优化方案，B方案为运营方为主的设计方案。然后就组织了方案评审会，会议结果已在文章开头做出了说明。
下面我就总结反思下会议的整个过程。
一、会议前的准备
1. 应急预案准备
作为设计师，通常都会对自己的设计方案比较有信心。特别是经过深入分析后的设计方案。更多的是希望在评审会上尽情阐述自己的设计想法，获得参会人员的认可。
实际上，你面对的是形形色色的评审人员，每个人的岗位职责是不同的，他们只会从自己的工作利益点出发，对你的方案进行评价。这就需要设计师在会议前尽可能的做好应急预案，站在参会人的角度重新审视下你的设计方案。特别是商业性设计，里面会融入很多的运营营销场景，所有人都希望拿到更好的业绩数据，达成自己的业务目标。
当然应急预案需要长时间的工作中积累总结，但是我觉得这是很有必要的，可以让设计师更加全面的考虑到各种影响因素，从而提升自己的设计掌控能力。
例如，如果设计方案中弱化了商品曝光，避免对用户开卡流程造成干扰，分散用户的注意力。然而运营人员要求将广告资源位前置，这时候你该怎么准备应急预案呢？最有说服力的就是用户数据，通过数据说服对方。
2. 寻找设计方案支持者
通常我们在正式评审前需要拉动产品经理、业务方、设计部门内部进行1~2轮沟通，目的在于确认设计方向是否准确，有没有大的业务场景缺失。因为作为底层设计师是无法驱动其他业务团队中高层参与会前沟通的，会前沟通也不可能覆盖所有参会人员的意见。所以希望会前的沟通能够保证会上达成一致本身就是不现实的。
但是会前有必要的是找到方案的支持力量，最好的人选就是产品经理。因为设计师和产品经理是绑定关系，平时接触最多，也最容易达成一致。在会议之前需要通过多种方式，尽可能的拉通各级别的产品人员对设计方案达成一致，包括设计、技术实现等层面。当会议出现争执不下的情况时，让自己可以获得更多的设计支持。
二、参会人员级别匹配
以前我对这方面不太注意，大家都是同一部门或者同一体系的员工，会议形式比较灵活，大家都会畅所欲言的表达自己的想法。但是遇到需求方来自别的系统时，我才意识到这里面其实是有差别的。
当需求方参会的是中心级经理、运营总监，而产品方和设计方仅仅是底层员工时，这可能就是一个很难把控的评审会议。当方案产生争议时，考虑到额外的因素，你可能很难做到去据理力争。或者当你努力表达自己的设计思路和想法时，别人可能会选择沉默或者冷眼旁观，这也是会议中的风险点。因此无论是需求评审会或者方案评审会，都要争取让各方同一级别的人员参与其中，保证关键时刻对话层级的匹配度。
三、会议中应变能力和情绪把控
1. 应变能力
其实所谓的应变能力，更多的是依靠会前的准备，包括对业务需求的熟悉程度，思考分析的过程等等。
对于你不熟悉的内容，不要轻易做出判断和解释，可以让产品经理配合回答。如果在会上无人可以解决，可以先记录下来即可，不要强行回答，否则可能会让你的专业能力受到质疑，甚至让会议偏离主要的议题。
2. 情绪把控
正常情况下，设计方案评审会目标是收集各方意见，对修改内容达成一致，推进项目继续前行。在沟通过程中，不要轻易被对方激怒，会议的目的是要推销你的设计方案，你的任务是有理有据的表达自己的设计内容即可。
但是如果有人一上来就开始对设计分析表现的很不在意。认为没必要讲。这时你该怎么办？
控制好情绪，不要理会，因为你不是跟他一个人在开会，而是要面向大多数参会人员。你的方案是要争取大多数人的同意，只要你认为有必要，就可以将设计分析清晰传递给每个参会人员，为你的方案讲解做好铺垫。
3. 抓大放小
抓大放小就是在大是大非上要据理力争，可以通过数据、用户调研、行为路径分析等强有力的证据，准确的表达自己的设计想法。即使对方不接受，起码让他知道你是经过思考的，而不仅仅是一个画图工具。
而对一些设计细节，例如广告位的样式、尺寸等，直接告诉他这仅仅是原型方案，可以会后再完善，或者在视觉阶段确认，不需要在小的设计点上做过多停留，影响整个会议的流程。
四、自我反思
反思一下，在整个过程中我应该犯了4个错误。
1. 对项目的重视程度
这应该算是中心重点项目，在需求评审阶段，运营总监、产品总监悉数到场，而设计方仅仅是我一个底层设计师参会，需求无法直达设计管理层，造成后期设计内部会出现不同的声音，在会议过程中无法获得有力的支持。
2. 应急方案准备不足
对运营方的设计方案认识不足，由于在设计中UED团队耗费了很大的精力去分析竞品和研究用户，因此更多的是希望推动UED主导的设计方案。如果碰到善于倾听的需求方，可能还好。但是如果对方比较强势，形势可能就不乐观了。
3. 数据分析不充分
过度依赖用户分析及调研信息，没有与产品经理深入交流，缺少数据支撑，对现有页面内容缺乏深入分析。
4. 未能找到有力的方案支持者
在正式评审前，仅仅与运营方和产品经理（都是底层）进行了方案沟通，没有与产品方关键角色进行提前沟通，导致在评审会上，只有底层产品经理支持我的设计方案（人微言轻），其他更高层级的产品人员都选择了沉默。
五、个人思考
很多时候，设计师都在说自己缺少话语权，设计过程很被动，创意想法无法落地。其实最关键的问题是设计分析能否有力的支撑起设计方案，让对方更好地接受你的想法，无法轻视你的存在。
当你有能力完成精彩的设计方案后，就需要借助设计评审会去建立设计话语权。这个过程可能会比较漫长，需要通过一个个项目去积累。而设计评审的目标也不是设计方案获得所有人的一致认可，而是需要通过通过一轮一轮的评审和多个设计评审过程中的思想碰撞，输出你的设计分析、设计理念、设计方案，逐步提升设计的地位。
希望以后我可以做的更棒….
#作者#
子牧先生。公众号：子牧UXD（HelloDesign）。产品体验设计师。8年互联网行业经验，擅长体验设计思维、设计方法论、交互设计研究。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
