关于设计评审的一些思考

” Your ">design isn’t a work of art. It’s a business solution. Practice being critiqued.—Matthew Smith”

上述话是美国互联网公司Zaarly设计总监Matthew Smith的设计箴言,意思是说你的设计是一个商业解决方案,而不是一件艺术品,因此必须为设计评审做好准备。现实生活中,有很多设计师对设计评审多有抱怨,因为设计评审中存在很多的不确定性,不同的人会有不同的审美偏好和价值偏好,一个设计方案不可能满足所有人的偏好。因此,有的时候一个思路比较完整的设计方案,在设计评审中会因部分人的个人偏好而被改的面目全非;还有的时候,设计评审变成了集体决策时间,少许改动也要全员同意,严重影响了项目的节奏和进度。笔者通过参与项目设计评审工作,形成了个人的一些浅见,在这里与大家分享。

为什么需要设计评审?

在很多非设计专业同事的眼中,设计评审的意义就是确认现有的设计是否为大家接受,给设计挑挑毛病。这其实是一个非常错误的观念。这不仅是因为众口难调,更为重要的是,如果设计仅仅是为了让所有人普遍接受,那就不可避免地使设计陷入平庸和毫无个性。设计评审的真正价值在于:

a. 设计评审可以帮助设计师确认当前设计思路是否能够实现产品目标,是否存在设计思路与产品目标偏离状况。

b. 设计评审可以帮助设计师确认当前设计中哪些部分是非常有效的,哪些部分是有问题的和导致问题的原因。

c. 设计评审中来自不同专业角度的反馈可以给设计师提供新的视野,帮助设计师发现更多更优的设计思路。

d. 设计评审中的反馈还可以帮助设计师充分了解自己做的设计方案在后续的设计过程还有那些潜力可以挖掘。

正如上述图文所示,真正意义的设计评审可以帮助设计师改进方案,为设计和产品指引方向,而不好的设计评审会给设计带来很多困扰,甚至还不如不做设计评审。

如何做一个有意义的设计评审?

设计评审有两大种,一种是设计师的评审(参与人员全是设计师),另一种是项目组的设计评审。前者的评审人员因为拥有相同的知识背景,沟通起来一般不存在太多问题。本文重点讲项目组内的设计评审。在项目组设计评审中与会人员最好保持在4-8人左右,这是一个高效会议原则。人员背景最好来自不同专业,这样可以给项目评审带来更多不同的视野。至于如何进行设计评审,个人认为可以分为三个阶段。如下图所示:

项目初期,设计评审中应该抛开工程上的和设计上细节实现的种种限制,探讨尽可能多的设计方向和设计思路去实现产品的目标。评审话题应该是启发式的,如“是否还有其他的方法去实现”。通过来自不同专业视野的反馈,以便激发出更多的设计思路。因为没有哪一种设计方案是完美的,只有通过获取更多的方法和思路,才能评价哪一种设计方案在实现产品目标是最优的。

项目中期,设计评审则更多的是讨论不同方案中优势的部分和劣势的部分,不仅要考虑方案当前优劣,还要指出方案在未来继续设计可能具有什么样的潜力和优劣。通过权衡方案优劣后,确定出最有潜力的设计方案继续进行深化。

项目后期,设计评审的重点在于面向设计细节。需要以可用性原则去判断设计方案中的细节是否存在可用性的问题,同时也需要发现设计中细节比较粗糙的地方,留给后续打磨。

设计评审容易出现什么问题?

1. 评审人员的主观意见

关于这一点不少设计师都深有感触,很多参与设计评审的人员尤其是产品经理,经常会提出一些诸如“这个界面使用黄色感觉不太舒服”、“这个标题的字应该调的更紧凑一些“,“我觉得这个设计不够大气”等等的意见。上述意见更多地反映了个人喜好,而无法达到设计评审帮助设计师寻找更优设计方案,指引设计方向的作用。

2. 评审意见模糊

因为参与设计评审人员来自不同专业背景,有不少人对设计过程和设计本身缺乏足够的理解,因此评审意见模糊的情况在设计评审中也经常出现。意见模糊造成两种结果,一是设计师无法得到有效反馈,二是无法激发评审人员的有效讨论。

3. 项目中前期过于纠结细节

细节打磨是提高设计品质的必经途径,这项工作一般在设计方案确定后进行。但设计评审中经常遇见过于纠结细节的评审人员。如下图所示,在项目初期评审中针对某个细节反复争执(并非所有细节都影响用户体验,需要反复推敲。)。过早地纠结细节,容易使设计只停留在一个方案上,而失去寻找更好的方向和思路的机会。

4. 持续的挑战

有些参与设计评审人员在评审中会持续地挑战设计方案,他们经常会问这样的问题:“为什么要按照A设计”、“为什么按照B设计”。挑战设计本身不存在任何问题,很多情况下是可以激发大家去寻找新的更优的思路。但在挑战下,人的本能就是去捍卫自己的观点。设计师也不例外,持续的挑战,让设计师会思考如何捍卫当前方案或改进当前方案。虽然说这一定程度上,也促进了设计方案的优化,但弊端也显而易见,设计师和参与评审人员的思维都被限制在当前方案上,偏离了寻找“更多”和“更优”的设计思路的初衷。这就像人们经常说的,“为了一棵树,放弃了整片森林”。

设计师应如何应对设计评审中出现的问题?

A. 准备充分,否则推迟评审时间

如下图所示,设计师在设计评审中提案就像冰山露在海面上的部分一样,其实只是一小部分,而设计过的方案可能就像海面下更大部分。因为设计本身是一个发散和创造的过程,会有很多种方法达到产品目标。而设计师的工作就是在众多方法中寻找到最优的方案并呈现出来。如果在设计评审前没有把诸多方案想透的话就参加评审,评审中很容易出现方案被质疑的状况,被质疑后方案可能还需要重新做,浪费了时间也浪费人力。因此,在设计评审前一定要尽可能探索所有可能的方案,否则不如推迟评审时间。

B. 讲方案前,要明确设计目标。

如上图所示,讲述方案前要把设计要解决的问题,要带给用户什么样的体验(这需要和产品经理和整个团队达成一致)和支撑设计的数据和经验判断先明确出来。

见过很多设计评审中,为某个细节讨论不休, 各说各话,没有在一个层面上讨论。 如果明确了设计目标的时候,设计师在讨论混乱的时候,可以回顾设计目标,把大家拉回正确的方向。而支撑设计的数据和经验判断,则起到了两方面作用;首先帮助设计师讲述方案时显得有理有据,其次让讨论更加有效,评审人员可以更加明确的讨论是数据和经验判断有问题,还是设计表现上的有问题。

C. 引导大家去寻找更优设计方向和思路

引导大家寻找更优设计方向和思路,在设计评审中至关重要,可以说是精髓所在。有很多人错误的认为,设计评审的不过是评审一个设计方案,如果感觉不错就开始开发,如果感觉不行就打回去修改。作为设计师,应该明白设计评审可以给自己带来的帮助,在评审过程中要引导大家去寻找更优设计思路,这里需要注意是思路而不是方案。正如前文所述,评审的意义在于寻找更多的更好的方向,最后由设计师根据反馈改进提出一个最优的方案。如果在评审中提出了解决方法,这种在短时间思考出来的方法,很可能因为思考不周全而存在这样或那样的缺陷。同时也失去了让设计师去思考更优方案的机会。

D. 设计方案得到认同时,引导大家讨论方案中风险点

如果讲述完设计方案,大家都十分认同, 而且也找不到任何更优的设计思路,在这种情况下,设计师应该把讨论转向现有方案在可用性上是否有潜在问题,项目在后期实现和运营中是否存在风险的话题上。如此一来,来自不同专业背景的人员,便可以提供一些专业意见帮助改进现有方案。

E. 设计师需要主导整个设计评审

在设计评审讨论中,设计师一定要主导整个设计评审工作,只有设计师最了解自己方案中哪些地方是强壮和薄弱的。在设计评审中设计师应该起到主导设计评审的作用。此外,设计师在设计评审中接收大家反馈信息,吸收有效的信息改进设计方案,最后方案如何改进应该由设计师来确定。

设计师如何主导设计评审 ?

如上图所示分了三个阶段,首先要在设计评审前做充分的准备,评审中组织讨论和评审后跟进。每个阶段下都列举了一些小方法,这些方法使用时要因地制宜。总体来说,设计师要想主导设计评审,需要在评审前对每个环节都进行充分准备,这些细小的环节,会让设计师在项目组中更具影响力,最后达到推动设计评审高效进行,体现设计师专业性的最终目的。

参与评审的人如何给出有价值意见 ?

1 先听后说,拒绝持续挑战方案

这是一个非常浅显的道理,但知易行难。先听后说可以避免在没有理解对方意图下加以评论并把讨论引入错误的方向。拒绝持续挑战方案则能够避免在持续挑战下,失去了讨论更多和更优方案的机会。

2 在表达个人喜好时一定要提前声明

对此可能很多设计师都深有感触,很多参与设计评审的人员尤其是产品经理,经常会提出一些像“我觉得这个设计不够大气”,“这个标题的字应该调的更紧凑一些“,“现在颜色感觉有点太朴素了”等等的评论。上述评论更多反映的是个人喜好,但千人千面,不同的人会有不同的喜好,很难全部满足。当然这里并不是全盘否定上述评论,只不过在上述评论中一定要提前声明这是个人喜好。这样既可以让设计师了解到评审人员的直观感受,又避免了上述评论成为评审中讨论的重点。

3 以问题开始,按重要程度排序,关键的问题优先提问

这种提出问题的方式最理想的状态就是每一个问题都可以让讨论更向前推进一步,一开始最重要的提问可以使用“你是否尝试过使用B方式….”的句式开头,这样的提问会给设计师一个表白的机会,“我之前思考过B方式,没有使用是因为…”。然后讨论就被引向了理性,讨论是否有更优的方案,而不是细节的个人喜好。

4 找出当前设计方案中的精华部分

这是在设计评审中很容易被忽略的地方。找出设计方案中做得好的部分,一方面是对设计师所做工作的肯定,另一方面明确了哪些部分是比较好的,需要保留并可以继续探索。

5 找出问题、指出设计师可能遗漏的方向,避免直接给出解决方法

正如前文所说,找出设计中存在的问题,寻找更好的设计方向是设计评审中重要环节。不过要避免直接给出解决方案,让设计师失去了继续优化方案的机会。

此篇文章已经收录在2012 UPA文集行业类文章,文中部分图文参考了以下文章,感兴趣的话可以点击以下链接进行扩展阅读。

Design Criticism and the creative process, C. McDaniel
Become a design leader, Frog Design

(本文出自Tencent CDC Blog,转载时请注明出处)

时间: 2024-07-31 12:11:16

关于设计评审的一些思考的相关文章

艾伟也谈项目管理,个人管理:从昨天的一个设计评审来谈如何与人交流你的设计思路

昨天项目组进行了一个设计评审,主要是对OpenExpressApp的AutoUI部分进行重构,我相当于评审人.大家也可以把这个评审过程当做与人交流你的设计思路的一个过程,以下从我评审的一些要素来谈谈与人交流设计思路时需要考虑的内容,也许对大家在实际工作中的架构.设计和沟通都有所帮助. 评审并不是审判,你直接说出结果之后,然后等着判官下笔,评审一定是基于特定主题进行的,所讨论的东西都围绕这个主题,那么如何让人先清晰你的这个主题是需要考虑的.对于不同人来说,每个人关注视角不一样,所以还需要针对这个主

DDD实践问题之 - 关于论坛的帖子回复统计信息的更新的思考

之前,在用ENode开发forum案例时,遇到了关于如何实现论坛帖子的回复的统计信息如何更新的问题.后来找到了自己认为比较合理的解决方案,分享给大家.也希望能和大家交流,擦出更多的火花. 论坛核心领域问题分析 论坛领域的核心概念是:帖子.回复.大家都知道,一个帖子可以有零个或多个回复.对同一个帖子,不同的人可以并行发表回复.回复发表后,查看帖子详情时,可以根据回复的发表时间排序显示:此外,我们还关心某个帖子的最新发表的回复.最新回复的作者.最新回复时间,以及总回复数. 我们设计的系统,应该在实现

分享我对代码命名的一点思考和理解

一个软件最后都会落实到代码.而代码,其背后的架构设计或设计思想或模式固然重要,但我觉得更重要的东西则是良好的命名.混乱或错误的命名不仅让我们对代码难以理解,更糟糕的是,会误导我们的思维,导致对代码的理解完全错误.相反,良好的命名,则可以让我们的代码非常容易读懂,也能向读者正确表达事物以及逻辑的本质,从而使得代码的可维护性就大大增强,读命名好的文章是非常流畅的,会有一种享受的感觉. 另外一点也许大家还没感受到,那就是良好的命名,以及良好的命名习惯,由于我们总是对每个概念的名称要求非常苛刻,我们会思

科陆电子首席架构师李标:智慧能源的核心是让数据会思考

深圳市科陆电子科技股份有限公司成立于1996年,是为智慧能源和能源互联网提供核心技术与系统解决方案的上市公司,国家重点高新技术企业.当前科陆已经从传统硬件制造商成功转型为中国能源服务商,并且正在努力打造智慧能源云平台,向着世界级能源服务商的目标进发.在刚刚结束的2017年云栖大会·广东分会上,科陆作为阿里云行业领军客户做客企业云上转型实践专场,科陆首席架构师李标先生现场分享了科陆在打造智慧能源云生态过程中对业务.技术.数据以及自身价值的思考. 什么是智慧能源? 李标给出的答案是莎士比亚的一句话-

缓存技术方案改造思考

这是我对一个正在进行的重构项目,缓存技术方案改造点之一的一个想法: rc现有的实时缓存(其实也是准实时,失效时间的存在)设计: 存在的问题:现有的实时缓存方案(也并非真正意义上的实时,缓存失效时间的存在),与上游核心系统耦合度较高,核心系统强依赖下游欠核心系统,而且目前的查询服务性能也存在问题,比如区域销售豆腐块接口返回的数据量大,并且从tair->rc,rc->delivery需要经过两次网络传输,这之间网络传输及序列化.反序列化消耗大,而且出现问题时,由于排查链路和时间周期都长: 升级方案

计算机-关于754标准浮点数表示的一些思考

问题描述 关于754标准浮点数表示的一些思考 大家好,最近在啃南大袁春风老师的<计算机组成与系统结构>这本书,书中一句话不解:""因为原码是对称的,所以浮点数的范围关于原点对称.""大家都知道浮点数表示为X=(-1)^s*M*R^E浮点数的正负由符号位s控制,s取1就是负,s取0就是正,关原码M什么事啊!由于有符号位s控制浮点数的正负,那原码M就应该只表示正的定点小数啊!请各路大神帮俺释疑解惑!!! 解决方案 说的是范围,比如-2^8~2^8,原点不动的

对无线电商动态化方案的思考(一)

如题,接下里的一段时间里,我会从无线电商动态化的角度谈一谈自己的理解和思考 无线电商动态化 无线 首先要谈的是无线,或者说移动.手机和传统桌面端计算机有着非常大的不同,首先是随时随地,这样它就需要同时也可以拥有更多的传感器,比如镜头.体感.定位.蓝牙.NFC 等等,当然也包括多点触摸屏,人们的操作和交互方式也发生了很大的变化:其次它的屏幕尺寸和电脑完全不同,也由此产生了完全不同的阅读体验和阅读方式:再有就是能耗和稳定性变得非常非常关键,如何流畅的展示复杂界面和大数据,如何有效控制由于资源问题而导

对LMAX架构以及Event Sourcing模式的一些新思考和问题的记录

最近又学习了一下LMAX架构,让我对该架构以及event sourcing模式又有了很多新的认识和疑问. 注:如果不知道什么是lmax架构和event sourcing模式的看官可以自己先去查查资料: LMAX可以看看martin写的一篇文章:http://martinfowler.com/articles/lmax.html Event Sourcing的资料比较多,随便google一下即可. 当然,我的博客里也有大量关于这两个方面的笔记,有兴趣的可以看看. 下面是我的一些最新的想法. LMA

独立思考能力从哪里来?

20080924 郑昀@玩聚     一位高人(是真的水平很高)在< 上中学的时候被老师"雷"到的一件事情  >中写道:"教科书上说某地早在几百年以前就被我们天朝的军队占领过,因此,证明该地自古以来就是我国的领土.这老师很不屑的说了一句:按这个道理,是不是日本人占了我们的地盘,1000年以后就可以说,1000年以前日本就占领过这里,所以这里自古以来就是日本的领土?我当时就被"雷"到了,思维简直就像受了地震.这是不再人云亦云,学着独立思考的开始.