谷歌在刚刚结束的开发者大会上发布了它的新设计语言-材料设计（Material Design）。当然，和其它新发布的设计语言一样，谷歌设计部的高官们不厌其烦地介绍这种设计语言的由来和各种好处。可是说实话，作为设计师来说，我从设计方面并没看出来这款所谓新鲜出炉的的设计语言有什么新意。无论是交互方式、视觉风格还是主体理念，材料把一些早已存在并流行了许久的方式和方法整合了起来，可以算是一个对已知产物的总结和归纳，并不是一个所谓的创新。

谷歌的设计高管详尽地介绍了整套材料设计语言的创造灵感和由来，特别把卡片式交互作为整套设计语言创作的核心，并以此为基础来设计和创作整套产品。不过卡片式设计并不是什么新的东西，早在WebOS时代就已经出道江湖，并一直在设计圈子里贡献着光和热。

在我看来，虽然谷歌声情并茂地讲述了各种背后的故事，但是所谓材料设计语言就是卡片式风格交互加各种过场和操作动画，和iOS7类似，属于新瓶装旧酒地重新包装，缺乏有建设性的创新。这类重新包装的设计语言都有一个共同的现象，那就是设计本身早已经了无新意，无法让使用者觉得有什么特别之处。无奈之下只能借助各式愈发趋向于精神层面的宣传、讲解和布道来让用户接受自己的设计语言。所以近期出现的几个设计语言都可以被看成是不同的设计，而无法被称为更好的设计。没办法，现阶段操作系统的设计已经相当成熟了，纵然像微软、谷歌或苹果这样的创意人才聚集地都很难在用户体验创新方面有什么实质性的重大突破，不得不转而进行细节的推敲和对已有设计进行归纳。其实这样的举动也是无可厚非的，毕竟下一步的突破需要对之前经验进行积累。

我本人对这种框架类型的设计语言还是欢迎的，毕竟大公司产品太多，有个基本设计框架来规范各类产品的基础交互和视觉识别对使用者来说确实可以提供一定程度的便利，也能让公司的产品们以一种比较有质量的方式来呈现给用户。但是大公司很多产品的平庸和难用确也正是因为受制于各种设计的框架和语言。以我个人的设计经历为例子，在惠普和思科都有着各种不同的设计规范和设计语言来保证产品的一致性。但是在项目操作层面，古板地使用公司的设计框架却会对产品本身确造成极大的伤害。

第一个伤害来之于设计框架本身的不稳定。组织架构庞大的公司业务也相对复杂，经常有好几个部门来参与制作设计语言或者设计框架，结果部门间的侧重点不同经常导致对于框架本身的设计就争议不断，就算最后设计出来了也往往是个毫无个性的妥协解决方案，实际使用效果并不好。

第二个伤害来之设计语言本身的发展进度太慢。理论上设计语言提供了一个规范，所以必须具有相当程度的权威性。相应地这个对设计架构本身的制作、核查和认证都需要花费时间精力。这导致了一款设计语言从开始计划到立项执行最后到出产品通常会花费相当长的一段时间。在网络和云的世界里，这段时间内，各种产品极有可能已经有了不同程度的发展，使用者的使用习惯和对产品的期望也随之改变。等设计语言出来的时候，很多当时非常流行的交互行为和视觉语言都已经进化或者改变了，于是按照设计语言规范生产的软件或产品不可避免地失去了新颖的概念而无法吸引到消费者。

最后一个伤害是设计语言自身的笨重。一个规范式的框架，无法避免地会遗漏很多细节元素。而各类产品为了最好的服务它的用户群体，必然会需要做很多细节上的调整和改变。这时候设计语言便无法满足不同项目组对产品细节的追求，但是却又因为要保持产品线的统一，制约着各个项目组的设计空间，让项目组花费大量时间和精力在反复沟通上，打击具体项目设计师的灵感和积极性。

我总觉得做产品就像在打仗，成功的产品必须对时间、地利和人和都加以利用。设计语言对产品的限制就像是前线进攻的装甲师发现了敌人防线的弱点，准备进攻的时候发现汽油不够用，于是和总部报告说部队可以就地找到所需要的汽油，要求立刻进攻。总部回答，你们就地找的汽油可能规格不符合也许会减少发动机寿命，你们还是等几天等我们发给你们符合规格的汽油再进攻吧。等官方汽油到了，防线的漏洞也被堵上了，于是本来可以以微小代价解决的问题，现在会消耗更多，最坏情况下也许这个消耗就导致了战役的失败。

所以成功使用设计语言的难处在于找到封闭和开发的平衡点。一个基本框架保证了产品线最大化的一致，同时又预留出足够多的空间给项目设计师因地制宜，为不同的小细节设计出足够灵动的解决方案。这对设计语言的制定者要求非常高，也对项目设计总监抓大放小的能力提出了新的要求。但是也只有这样，才能让一款设计语言充满生命力。