朱文俊AlexZ,乐品乐道联合创始人兼设计总监,
毕业于英国Warwick大学WMC工程学院,清华大学美术学院。超过15年行业经验。参与过上海世博会,北京奥运火炬等大型设计项目。
一门手艺入行的过程大概是一个学会“偷懒”的过程,设计也是这样:从学校出来的时候,我们满脑子黑格尔式的设计哲学,愿意花时间把项目做得更“完美”。慢慢的,我们发现黑格尔不是财神爷,甲方才是。他们要什么我们做什么,这样才能少花力气多赚钱。再后来,发现在大多数时候,财神爷其实也不确定自己在设计上想要什么,搞得我们改来改去也挺耽误时间。于是我们找上门去,不等财神爷出口,就告诉他,我可以帮你这么这么搞,可以帮你赚更多的钱。甲方说,好啊好啊,这事就这么办了。所以,随着我们渐渐清楚甲方要什么,我们就学会“偷懒”,开始入行了。
设计是了解问题,然后协调矛盾,拿出解决方案的过程。了解问题是设计的基础,也就是所谓的“审题”很重要。比如饭店要设计个自动配菜机,需求上也许写的是“外观设计”,但根本上他是要解决饭店排队长,翻台率低的问题。所以配菜能否更快,能否进一步减少后厨空间,才是饭店关心的问题。至于外观好不好看,就不如前两点重要。所以在设计和展示方案的时候,一定是围绕提高操作效率,降低维护难度和减少体积上来。在有限的设计调研时间里,我们应该重点了解员工的工作流程,研究他们的操作方式,而这些都不是需求单上写的“外观设计”。
同时,即然设计是为了解决问题,那也不应该局限于工业设计,平面设计,或者是哪种设计。我们提交给甲方的,是我们觉得能够达到甲方目的的解决方案,哪怕不是“设计”。
比如有个案子,甲方说,这条路太堵,你帮我设计得宽一些。如果我们如果按照甲方的思路走下去,给他提三个方案:
把绿化带去掉
把人行道去掉
把两侧的房子拆掉
这样问题是否解决了呢?其实甲方提出问题的本质是要解决堵,而不是把路修宽。问题的根本可能是周边没有别的商业区,大家逛街只能来这里;或者这里有个特别火的商场,停车场进不去,结果大家都堵在路上。据此,未来的提案可能是这样:
把绿化带去掉
修一条分流道路
在住宅区附近规划一些商业用地
所以,如果只是按甲方表面需求来做,可能并没有解决甲方的痛点。
很多新手设计师不重视“了解需求”这一点。他们以为听听立项会,看看需求文档就能了解一个项目。too young too naive。要知道,我们听到的问题,可能不是真的问题;而真正的需求,客户可能没有说;甚至,写需求的人并没完全理解他老板的意图!
一、听到的问题,可能不是真的问题——视觉有错觉,同样,其它认知也有错觉。
举例1:
用户:我觉得A电视的画质不如B电视好。
真正的问题:A电视的喇叭需要换个好一点的
真相:调查表明,电视音响的好坏会影响用户对画质的判断。用户觉得电视画质不好,有可能是音响太差。
延伸:甲方需求是不是完整?
举例2:
用户:我觉得A薯片不如B薯片脆
真正的问题:A薯片的包装要重新设计
真相:调查表明,包装材料直接影响到用户对食品的印象。软质材料包装薯片,用户就会觉得不够脆。
二、真正的需求,甲方可能没有说
甲方:我们是创业公司,这是一个全新产品,所以没有什么限制可以自由发挥。
现实:
没有限制的意思大致是,我还没有想清楚要什么。所以,我们一定会在你们做的过程中提出各种新的想法;
因为没有想清楚,
我们需要一个可以讲故事的设计,以便让投资人印象深刻,忽悠到钱;
为了让投资人看到漂亮的数据,我们希望软件产品能像病毒一样扩散到用户的手机上,如果能实现,就算真的是病毒我也会付钱;
好吧,我承认我们内部意见不统一,所以我不想让别人来主导这件事,只好请你们三方公司来做。换句话说,项目还没做,挑战你设计的人就已经准备好了。
甲方:我们是一家跨国公司,我们做事有完整的规范和流程,我们的需求非常清晰。
现实:
我们总部在美国,要么凌晨3点跟我们开会,要么邮件沟通;所以项目往往反馈慢,周期长。
我们美国老板喜欢白板板一片的简洁风,我们中国老板喜欢密密麻麻的丰富内容,你的设计方案要先给中国老板看,再到美国总部批,具体怎么搞你看着办;
我们在中国有5个分公司,我们在项目进行过程中,会有这5个分公司的反馈意见,你需要说服这5家公司都接受你的方案。
三、写需求的人并没完全理解他老板的意图!
举个例子就明白了:
董事长:我计划2年内把中国市场融入我们的全球供应链体系。
中国区CEO:为了与全球业务同步,我打算通过品牌营销来扩大我们的市场份额,市场预算20亿。
市场总监:为了建立品牌形象,我们要打造统一的VI系统,以规范各区滥用logo的行为。
商务专员:嘿,我们公司要设计一套VI,3个公司比价,你先给我出个竞标方案,需求在这里。。。什么,有没有内定?我们吃饭聊…
总结
设计要解决问题往往是多维度的,复合的,甚至是矛盾的。纸面需求只能体现出其中很少的一部分。在设计之前多花一些时间去了解清楚,可以有效避免后期的无效劳动。
(本文章