您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
协作的精髓!FACEBOOK设计团队是如何开设计评论会的
 
作者:陈子木 来源:产品中国 发布于:2016-4-8
   次浏览      
 

在设计流程中,设计评论是一个重要的环节。无论是在独立的设计团队,还是流动性、多远的设计群组中,它都是整个设计过程中,无法忽略的部分。通过团队的设计评论,在不同成员的审视、评论中得到反馈,让你站在自己以外的角度来看待之前的设计作品,这样可以更好地做设计决策,克服障碍,提升作品也提升自我。

当我刚刚加入Facebook的时候,我其实非常担心每周一次为期2小时的设计评论的环节会被浪费——想必大家对此都能理解,因为在许多设计团队内,设计评论往往会陷入两种状况:

为了不打击士气而不敢太深入批评他们的设计项目

团队成员并没有清楚理解设计评论的目的,而陷入无目的的吐槽,让整个环节彻底沦为浪费时间

但是在Facebook,设计评论起到的作用和其他的团队想必,略有不同。每次这样的会议,团队成员面对每个设计项目能做到真正意义上的“评论”而不是以挑刺为主的“批评”,也不会出现糊弄人的和稀泥的状况。

在做设计评论这件事情上,我们的思路主要源自于Jared M. Spool 的那篇文章《从批评性审视转向评论》。Spool 在这篇文章中对于评论的界定让我对于设计评论的理解有巨大的影响,而这种理解的价值在Facebook的团队中显得尤为重要,这也使得我们的团队每周2小时的设计评论变得尤其有价值。

接下来,我为你展示一下Facebook的团队是如何做设计评论的。

1、建立清晰的角色和定位

在设计评论的环节中,每个人都有有一个必须扮演的角色,而通常所有人都的角色都可以划分为三类:主讲人、观众和协调者。

主讲人就是设计项目的分享者,他的主要任务是:

简要的描述正在试图解决的问题(或者是正在探索中的想法)

展示当前的设计或者想到的解决方案的内容

主讲人的任务并不是全程展示他的设计,或者向团队“兜售”一个设计想法。主讲人应该提前一天为每个协调者预留出15~30分钟的时间来沟通,让他们对次日要展示的设计项目有清晰的了解,而非设计评论会议前一秒再行沟通。

而观众则是整个设计评论中不参与展示的这一部分人,观众主要做下面的这些事情:

了解这个设计和项目所处的状态和背景

提出一系列的问题

观众这个角色最重要的功用就是提出大量的问题,这些问题应当尽量揭示设计相关的思路,或者有助于引导设计师或者设计团队来做决策。

在这个环节,提出正确的问题比为特定问题找到正确的答案更重要。举个例子,对问题范畴提出质疑,可以让主讲人和设计团队重新审视整个设计的视觉语言、推动创新的设计,并最终影响整个团队的决策。

接下来是协调者这个角色的作用:

提前为每个主讲人的内容、展示时长、观众评论时长制定时间表

确保整个会议中所有人都能依照时间表来运作

为每一轮展示和评论都做好记录或者笔记

对每一个主讲人提出问题:“推动设计进行的下一个关键步骤是什么”,并针对相应的回复做好记录

协调者最重要的作用是确保会议中每个角色都是在他们设定的范畴内发挥作用,让观众不要陷入无目的地质疑、提出无针对性的问题或者影响整个流程,让主讲人专注于勾勒设计思路、提出解决方案。

在我的团队中,会预先指定一位协调者来管理每周的设计评论会议,如果没有事先制定也可以让某个主讲人来承担这个任务。

2、确保每个人都能理解并认同要解决的问题

设计评论会议中,在展示任何设计方案和项目之前,先重申有待解决的问题是非常有帮助的。

预先声明设计项目要解决的问题和背景以及为什么要解决这个问题,这可以帮助在场的观众对项目有更深入的了解,并且可以更加高效地获得用户反馈。而这种预先声明可以以下面的样式来呈现:

我将要展示一个【前期/中期/已完成】的设计项目

【想要解决的问题】是这样的

由于【什么样的原因】这个问题需要我们来解决

而我想搜集【关于这方面的反馈】来帮我完成设计

主讲人应该明确说明他所寻求的反馈是集中在哪个部分,有针对性地进行说明。举个例子,主讲人可以这么声明:“这次展示我暂时不需要解决在设计细节和美感上的问题,我想知道怎样设计过渡动效以营造出更具有凝聚力的用户体验。”

一旦设计问题被清楚地提出来了,那么应当确保现场的观众都能清楚地理解它。而此时,主讲人和协调者则应当同观众针对预先提出的问题进行沟通:

“预先提出的这个设计问题似乎是有效的,那么它的表述是否清晰,是否有不完整的地方?我们是否都同意,需要解决的就是这个问题?”

当所有人都同意了之后,主讲人就可以开始展示他的设计项目或者解决方案了。

3、专注于提出反馈而非一味批评

接下来,搞清楚有用的反馈和无效的批评之间的区别。

值得一提的是,Jared Spool 的文章让评论的价值体现了出来,而我的设计团队中还引入了作家Judy Reeves 的一些思想。Judy 在他的书《Writing Alone, Writing Together》也探讨了类似的问题,而我们团队中的设计师 Greg Lindley 常常会引用这本书中的观点:

“以问题的方式来阐述观点,让设计师能够放下防御的姿态来陈述他们设计的原因。如果有某个特定的角度未曾被考虑到,他们可以用笔记记录下来,定位问题,然后在下一次迭代中解决它。”

除了搜集这些以问题的形式而存在的反馈之外,我们还鼓励观众在评论环节提出他们对这个设计或者方案喜爱的地方。

为了确保反馈是真正有帮助的——真正的是提出评论而非批评——Reeves 还提出了一个界定两者区别的大纲:

批评直接给出判断,而评论则是提出问题

批评直接找差错,而评论揭示机会

批评往往主观,而评论更加客观

批评容易含糊,而评论更加具体

批评倾向于推倒,而评论旨在构建

批评以自我为中心,而评论则是利他的

批评是对抗性的,而评论倾向于合作

批评容易诋毁设计,而评论可以提升设计

如果评论的目的是要推动解决方案,强化设计团队,那么反馈信息则应该具有探索性和指导性,具有建设性,并且提升整个设计项目,注入合作和协同的工作观念,而不是对抗性地去批判主讲人。

4、让电脑和手机保持关机

设计评论这个环节旨在探索问题,开拓思路,提升团队协同,而实现这些主要还是通过提问和倾听。如果在这个过程中你需要经常查看电脑或者用手机刷Facebook状态,就很难专注了。

当然,作为主讲人必须通过电脑或者手机来展示,而协调者需要实时记录会议笔记,这两者是例外。而其他人,也就是观众则应当关闭电脑和手机。

结语

最后,我们还总结了七个问题,来帮你反思你的团队和设计评论的会议本身。这些问题能帮你更好地发挥它的价值:

对于将要展示的设计项目,有没有系统的时间表和议程?

每个环节的角色界定是否清晰?

主讲人是否有将设计项目所面临问题的全貌展示出来?

主讲人有没有让整个环节都保持高度的专注?

会议室内的所有人是否都明确了问题框架,并且每个观众都是否做好了提问的准备?

反馈信息的形式是否都是问题,而非批评?

整个设计评论会议是否让人觉得是在试图提升设计、勾勒问题?

设计评论是一整个团队的努力,而非个人的表演,要充分利用它的价值,需要整个团队所有人都有意识地协作、探索并建立起来完整的设计和沟通流程。

   
次浏览       
     
 
相关文章

中台产品面面观
如何在互联网产品中建立中台?
什么是产品生命周期管理?
产品设计之前,如何分析业务需求和用户痛点?
 
相关文档

产品经理是怎样炼成的
APP产品规划方法
产品经理培训文档
产品生命周期管理PLM
 
相关课程

产品经理与产品管理
卓越产品经理训练营
产品需求分析与管理
基于用户体验的产品设计
最新活动计划
LLM大模型应用与项目构建 12-26[特惠]
QT应用开发 11-21[线上]
C++高级编程 11-27[北京]
业务建模&领域驱动设计 11-15[北京]
用户研究与用户建模 11-21[北京]
SysML和EA进行系统设计建模 11-28[北京]

正视研发管理才是高水平竞争
需求是如何变成产品原型的
产品经理能力模型解说—把控
产品经理的正确定位
谁是合格的产品经理?
产品管理与产品营销的区别
更多...   


统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行


某博彩企业 产品经理与产品管理
面向产品的需求分析与管理
中国民航 产品经理关键技能
深圳 产品经理与产品管理
某通信企业 基于互联网的产品创新
某知名互联网企业 产品管理
世纪高通 创新创造突破性产品
更多...