如何避免让设计评审会变成撕逼大会?
2016-02-12 00:00
405 查看
编者按:Tanner Christensen 是 Facebook
的产品设计主管。他在本文中就产品设计评审会分享了自己的一些看法。很多人认为每周两个小时的产品设计例行评审会是纯属浪费时间,因为很多的评审会最后都陷入无谓的争吵与辩论,最后成了一个撕逼大会,毫无效率和成果可言。Christensen
在这篇文章里就如何高效开展产品设计评审分享了自己的几点经验。
不管你在团队中工作,还是自己独立工作,设计评审对任何产品设计流程而言都是非常重要的一部分。在正式的产品设计评审中,你可以通过获得的很多反馈来跳出自我的思维限制,从而做出更好的决策,突破更多阻碍,提升自己的产品设计技能。
在我刚刚加入 Facebook
的时候,我很担心公司制定的每周两个小时的产品设计例行评审会是纯属浪费时间,因为我们本可以将这部分时间用在设计产品工作上。我之所以会有这个担心,是因为根据我之前的工作经验,产品设计评审往往会产生两种负面效果:
(1)团队成员太害怕在评审中被批评,导致他们不想展示他们正在做的东西。(2)团队成员对设计评审的目标没有清晰认识,最后只会陷入无谓的争吵辩论中,这纯属浪费时间。
我在 Facebook 的时候,产品设计评审是有点不同的,整个产品设计评审主要是基于事实进行评审的,而很少直接去进行批评或是对评审议程施压。
我们采用的很多产品设计评审的方法来自 Jared M. Spool 的 “Moving from Critical Review to
Critique”。Spool 对于产品设计评审的看法让我对评审有了更加深入的理解,知道了设计评审是值得花时间去做的一件事情,在 Facebook
工作后更是如此。所以现在,我开始拥抱这一理念并坚信,每周花几个小时进行产品设计评审对每个参会人员都是非常有价值的事情。 我的团队在 Facebook
是这样进行产品设计评审的:
(1)确定明确的角色
在产品设计评审的过程中,每个人都要有明确的角色。我们现在有三个角色:报告人、听众、促成者。
报告人是分享和展示产品设计工作的个人,他们的角色职责有以下两点:
简明扼要地描述正在解决的问题、或是正在探索的想法。
展示他们拿出的产品设计或内容解决方案。
要记住,报告人的工作不是仅仅用一张张的 PPT
去展示自己的想法,或向团队显摆自己的工作成果。每个报告人在展示的前一天都需要和评审促成者进行沟通,确定自己有一整块的时间用于报告(一般在 15 分钟至 30
分钟之间)。
听众没有专门的展示分享时间,他们的主要的工作任务是:
理解展示者所陈述的问题,以及问题的背景和前因后果。
问各种各样的问题。
听众最强大的工具就是他们所问的问题,通过问问题去揭示相关的想法,或是帮助引导决定。事实上,能问出正确的问题比找到特定的预先知道的问题的答案要有效得多。例如,提问初始问题的范围,能够帮助报告人或者团队对问题的轻重缓急进行区分,而询问确认刚刚达成的共识与决定则能够让整个团队的语言保持在一个理解水平下,同时能为推动整个团队做出更具创新性的设计决策。
而促成者的主要工作是:
提前为每次设计评审确定议程时间表,包括谁将报告什么内容,具体安排在什么时间?
确保所有要参会人员都能按时参会。
在设计评审的时候做好评审会议记录。
询问报告人这个问题:“你将采取哪些关键步骤将这项工作向前推进”,将报告人的回答记录下来。
作为评审的促成者,他们最重要的工作任务就是确保每个人都能在自己的角色范围内进行陈述,这就意味着听众的主要工作就是去问各种问题,而报告人的主要工作内容就是在展示工作解决方案时弄清他们目前的问题或是挑战。
在我的团队里,我们通常有一个固定的促成者来管理每周的产品设计评审会议。如果没有合适的人员来担当这个角色(比如产品经理或项目经理),那么参加会议的任何一人都可以充当促成者的角色。促成者的人选也是可以每周轮换一次的,这可以根据你的需要来确定。
(2)确保每个评审人员都能理解和同意评审所要解决的问题
在产品设计评审开始之前,重新确认需要解决的问题是非常重要且有帮助的。讲清楚这个问题的背景和前因后果:为什么这个问题或想法是值得在第一时间得到处理的。通过这种方式可以获得更多有效的信息反馈。陈述问题可以按以下这种方式来:
我正在展示的是【早期 / 中期 / 后期】阶段的工作进展。
我要展示的是【具体哪方面的问题】
为什么这会是一个问题?
我正在寻求【具体哪方面】的反馈。
在产品设计评审过程中,报告人应该明确说出他 /
她在评审中不关注哪些反馈,以及主要关注哪些反馈。例如,“我所追求的并不是项目细节审美方面的反馈,我追求的是如何通过动画过度让用户的产品体验黏性更强”。
在问题陈述完之后,要确保所有的参会人员都能理解它,这一点很重要。为了确保每个人都充分理解了这个问题,报告人或促成者可以问所有参加评审的人员下面这些问题:
这个问题听起来是一个有效的问题吗?
所陈述的问题是否会让人感到困惑不解?
还有什么可能被漏掉的东西吗?
大家都同意这个是我们目前就要解决的问题吗?
如果所有人都理解和同意了陈述的问题,接下来就该报告人去分享产品设计的解决方案或探索方案了。
(3)要注重反馈,而不是批评
一定要弄清有价值的反馈和无用的批评之间的区别,这一点非常重要。
我带领的产品设计团队从 Judy Reeves 那里获得许多关于评审的见解,他在自己写的一本书里分享了一些非常有价值的看法,“Writing
Alone, Writing Together; A Guide for Writers and Writing Groups”。
“以问题的形式来提出想法,这样设计师就不会去进行防御性的辩解,相反,他们会进行客观地推理论证。如果没有想到一个特别的角度,他们就会先记录下来,并在下次的产品迭代中考虑进去。”
除了要注重以问题的方式进行反馈,我们还鼓励设计评审团队成员发现设计方案里比较好的地方,并首先就这些地方进行反馈。例如:“我喜欢你处理这一部分设计的方式,那么你打算如何将这种设计方式应用到其他部分呢?”
为了确保反馈的有效性,我们需要知道什么样的反馈才算有价值的评审,而不是单纯的批评,下面有一个简单的叙述来判断二者的不同:
批评做审判,评审提问题。
批评找毛病,评审找机会。
批评是主观的,评审是客观的。
批评是非常模糊的,评审是很具体的。
批评是在拆毁,评审是在建立。
批评以自我为中心,评审是利他的。
批评是对抗性的,评审是合作性的。
批评会贬低设计,评审则会改善设计。
如果评审的目标是为了推进产品设计的解决方案并对团队进行授权,那么就应该以探索性问题和引导性问题的形式提出反馈,大家都应该抱着改善产品设计工作的目的和团队合作的态度,而不是要去指责和批评报告人。设计评审工作不应服务于助长任何人的自负或自私自利行径。
(4)产品设计评审时,要将手机、电脑都关了
进行产品设计评审的目的是为了要发现问题,提炼想法和发展团队,而这些主要是通过问问题和听问题的方式来实现。如果在评审的过程中不断地查看手机或电脑,你是不可能有效完成产品设计的评审目标的。不过这里有两个例外的情况:
一是促成者在产品设计评审中是可以打开并使用电脑的,因为他们需要对设计评审会做会议记录。
二是报告人在展示工作的时候,也是可以打开病使用电脑的。
除了上述两种角色的特殊要求外,其他人在产品设计评审的过程中都禁止使用手机和电脑。
总之,在产品设计评审过程中,推荐你将下面这七个问题拿来问你和你的团队。这些问题的答案有助于让产品设计评审更有价值和效率:
对于要评审的内容,有确定的评审日程方案吗?
在每次的产品设计评审会中,有明确的角色分工吗?
促成者有没有让大家的评审讨论一直按照评审议程来?
报告人有没有明确说明问题的范围?
参加评审会议的每一个人都深入了解了所要评审的问题了吗,他们是否能在针对性地提出问题?
参会人员的反馈是以提问题的方式进行,还是批评的方式进行的?
整个评审是大家合作共同努力解决问题、改善产品设计方案的吗?
产品设计评审是一项团队协作性质的工作,而不是一场个人秀。只有当所有参会人员一起,基于一个共识,以求达到探索和推进产品设计工作的目的时,产品设计评审才会变得真正有价值。
相关文章推荐
- yii_1_1_17_8(模型规则与标签设置开启前台验证-2016-2-11)
- yii_1_1_17_9(修改动作与设置成功提示信息-2016-2-11)
- yii_1_1_17_10(AR类的增删改查-2016-2-12)
- yii_1_1_17_11(后台添加文章小物件创建radio和select-2016-2-12)
- yii_1_1_17_12(上传类与如何扩展第三方类与缩略图类的使用-2016-2-12)
- 断言 NSAssert
- 用Javascript和jQuery分别完成侧边栏固定滑动
- Redis首页
- Redis文档
- Redis社区
- Redis下载
- Redis支持
- 移动的精灵,示例 SDL2 的图片分割、键盘消息
- 周易零基础入门教程
- 金函玉镜奇门遁甲秘笈全书
- 六十四卦图文详解
- ORM选型
- 微信调试类
- 微信(1)
- 微信自定义菜单生成器