本文作者复盘了自己的一次设计评审会的经历,梳理分析了评审会过程中遇到的问题,并对注意事项进行了总结。

复盘:设计评审会需要注意的几点问题

最近进行了一次设计方案评审,中间过程比较纠结,所以有必要复盘总结一下。

先说一下结果,我的主推方案未通过,需要按照运营方提供的设计修改。因为运营方强调“他们是业务指标承担者,要以他们的需求为准”。加之他们领导的鼎力支持,于是设计方认怂。

不过也并不是没有一些好的苗头,素来强势运营方开始解释他们的一些想法(或许仅仅是我个人的自我安慰)。

本篇文章反思内容主要包括:

    评审会前的准备参会人员级别匹配会议中的应变能力和情绪把控设计师话语权思考

先说下项目背景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. 未能找到有力的方案支持者

在正式评审前,仅仅与运营方和产品经理(都是底层)进行了方案沟通,没有与产品方关键角色进行提前沟通,导致在评审会上,只有底层产品经理支持我的设计方案(人微言轻),其他更高层级的产品人员都选择了沉默。

五、个人思考

很多时候,设计师都在说自己缺少话语权,设计过程很被动,创意想法无法落地。其实最关键的问题是设计分析能否有力的支撑起设计方案,让对方更好地接受你的想法,无法轻视你的存在。

当你有能力完成精彩的设计方案后,就需要借助设计评审会去建立设计话语权。这个过程可能会比较漫长,需要通过一个个项目去积累。而设计评审的目标也不是设计方案获得所有人的一致认可,而是需要通过通过一轮一轮的评审和多个设计评审过程中的思想碰撞,输出你的设计分析、设计理念、设计方案,逐步提升设计的地位。

希望以后我可以做的更棒….

#专栏作家#

子牧先生。公众号:子牧设计笔谈(HelloDesign),人人都是产品经理专栏作家。用户体验设计师。产品从B端到C端,横跨信息通信、电力、证券、电商等多个领域。擅长设计方法论和交互设计研究。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议




阻力设计在产品中的应用

阻力设计在产品中的应用

阻力是指物体在流体中相对运动所产生与运动方向相反的力,不仅在自然间中常见,在互联网中也广泛存在。本文作者从五个角度,深入分析阻力设计在产品中的应用,希望对你...

2020-06-18
如何成为一个合格的数据架构师?

如何成为一个合格的数据架构师?

数据架构师在互联网行业中是个很重要的职位,是企业数据资产最重要的“奠基者”。那么,如何成为一个合格的数据架构师呢?本文作者基于自身经历,从三个方面展开介绍,推...

2020-06-18
倒推“抖音短视频”APP产品需求文档

倒推“抖音短视频”APP产品需求文档

文章是倒推“抖音短视频”APP产品需求文档,但由于作者是第一次写需求文档,所以仅对核心需求进行了需求分析与说明。一起来看看~ 目录: 一、文档综述 1.1文档属性 1.2产...

2020-06-18
微信“拍一拍”,真的是一个没什么用的功能吗?

微信“拍一拍”,真的是一个没什么用的功能吗?

昨天微信上线了“拍一拍”功能,用户点击2次头像,会产生头像抖动,震动反馈,且在聊天框中显示“XX拍了拍XX”。 这个功能推出后,很多微信群都在疯狂拍一拍,引起了一波拍...

2020-06-18
数据大屏设计师,我不信你没有这些困惑(上)

数据大屏设计师,我不信你没有这些困惑(上)

从事互联网行业的人,每天都在接收新知识,时常也会有迷惑的时候,尤其是数据大屏这样比较少有人踏足的领域。本文作者以自身经历出发,对数据大屏设计提出了自己的一点...

2020-06-18
客户关系管理的15个模型总结(下)

客户关系管理的15个模型总结(下)

对于ToB产品,仅仅基于用户需求来设计产品架构是远远不够的。B端产品服务的是有着几年,甚至几十年管理积淀的企业,必须依靠一定的理论知识来支撑系统的设计规划。本文...

2020-06-18
B端产品设计:价值主张与需求对应的价值

B端产品设计:价值主张与需求对应的价值

B端产品的需求来源于场景,产品经理通过满足客户需求从而产生价值。因此,SaaS产品经理面对扑面而来的需求时,应当更清晰理解并评判需求的价值。 01 2008年,著名商业...

2020-06-18
以知乎为例,探讨未来产品设计的几大变化

以知乎为例,探讨未来产品设计的几大变化

知乎作为一个典型的问答社区,它本身反映了内容社区产品的很多典型问题。本文以知乎为例,探讨社区类产品未来发展的一些变化,对内容社区感兴趣的童鞋不要错过。 前段...

2020-06-18
如何用产品思维打造线上课程?

如何用产品思维打造线上课程?

如何用产品思维来给自己打造一个线上课程呢?本文从市场调研、课程开发、运营推广、成交这几个方面分享如何打造自己的课程,希望对大家有所帮助~ “地摊经济”重出江湖,...

2020-06-18
「武侠连载」营销中心设计——优惠券

「武侠连载」营销中心设计——优惠券

优惠券是常见的一种营销推广的方式,但是你真的了解它吗?本文作者以武侠故事的形式,对优惠券展开了生动的分析,对优惠券感兴趣的童鞋不要错过哦。 (武侠情节接上文“...

2020-06-18
金融支付财务融合业务-实践分享1:订单、账单、交易流水、账套知识解构、原理解析

金融支付财务融合业务-实践分享1:订单、账单、交易流水、账套知识解构、原理解析

本文作者从实际工作实践出发,结合案例等分享了电商金融支付财务融合中的基本概念和相关原理解析,包括:订单、账单、交易流水和账知识解构,供大家一同参考和学习。 ...

2020-06-18
关于卡片设计的分析与思考

关于卡片设计的分析与思考

卡片是APP常见的设计形式,它既有好处也有弊端,因此需要根据场景和内容确定展现形式。本文从四个方面对卡片设计展开分析,推荐给对卡片设计感兴趣的童鞋阅读。 卡片是...

2020-06-17
内容型产品中,付费会员功能如何设计?

内容型产品中,付费会员功能如何设计?

付费会员制度让用户预付会员费,将钱留在平台,那么未来一定会有消费行为,那么会员制度要如何设计,才能激励用户付费呢? 01 为什么要做付费会员? 讨论这个问题之前...

2020-06-16
文字社区是否可以拥有弹幕?

文字社区是否可以拥有弹幕?

从社区产品的角度来思考,弹幕功能对于内容生产方,内容消费方以及平台方而言各自有什么意义?图文内容社区是否有机会拥有弹幕呢?如果可以发弹幕,用怎样的形式呢?本...

2020-06-16
FMS财务系统收支结算总结

FMS财务系统收支结算总结

本文按照FMS收支结算划分,结算流程分类及各系统交互,财务系统内部结算基础能力,收支结算整体结构的顺序来依次介绍,总结财务系统收支结算的结构,和一些作者的个人思...

2020-06-16
如何迅速提升用户好评?试试这三种方法

如何迅速提升用户好评?试试这三种方法

小编推荐:如何提高一个产品的用户评分,改变大家对这个产品的印象呢?本文作者给大家介绍了三个概念:用户体验地图、峰终定律和服务蓝图,并详细解释了该如何使用这三...

2020-06-16
对工具型产品易学习与易使用的思考

对工具型产品易学习与易使用的思考

小编推荐:易学习是指怎么让新用户的学习成本降低,能够很快地掌握产品的使用,它的前提是足够简单和容易理解。而易使用是指,如何让用户快速、高效地完成一项任务,达...

2020-06-16
比对象还懂你!推荐算法为啥这么准?

比对象还懂你!推荐算法为啥这么准?

信息过度和广告过多的社会中,推荐算法的使用也就显得理所当然,但是它是如何做到了解用户的呢?本文从用户画像的定义和设计出发,结合实际案例,深入浅出地阐述了基于...

2020-06-15
B端平台产品需要培养的4种意识

B端平台产品需要培养的4种意识

对于许多刚入行不久的产品经理来说,B端平台产品是比较有难度的一项工作。本文作者基于自己的工作经历,提出了四点关于B端平台产品需要培养的4种意识,希望对你有帮助。...

2020-06-15
广告系列:保留价

广告系列:保留价

在一次拍卖中如果所有买家的报价均小于卖家的估价时,则拍卖品不出售由卖家保留,此时卖家的估价就是保留价,也叫底价,全称市场保留价。对于卖家来说,保留价的设置保...

2020-06-15