从事软件开发和设计工作,我们往往需要提出一个完整的一次性解决方案。但有时我们是受到时间的限制,或者我们只是还没有确定一个清晰的发展方向。一次性的解决方案并不是说它不好,但是如果它不是建立在一个坚实的基础之上,最终我们会发现自己还是不得不回过头来偿还技术积累和设计这笔债。
视觉语言就像任何其他的语言一样。如果不被使用它的每个人共享并理解，那么使用这种语言沟通将很容易出现误解。随着产品或整个团队的壮大，这种模式带来的问题也会越来越突出。
设计一直都是系统最主要的构成部分，设计规范是一种使产品达到可扩展性和可重复性的方式。无论是潘通色卡还是飞利浦发明的十字槽螺钉，这些设计规范使我们能够避免混乱,从而创造更好的产品。最适合建立设计规范的可能就是数字化产品领域了。但它往往不被我们视为优先级的事项。
更好、更快是一个设计规范最基本的要素。更好是因为一致性的体验能让产品更易用；更快是因为它为设计师提供了一套协作的共同语言。
一、为什么需要设计规范
Airbnb这些年增长非常快速。目前我们的设计部门有十多个专职设计输出小组。我们越来越意识到我们需要更系统的设计方法用来指导和提升大家的工作效率。我相信对软件行业来说，这个问题更严重。
1、缺少限制
相比于其他设计领域，软件设计几乎没有物理限制。这就意味着任何一个问题都可能有多种解决方案，但这恰恰可能造成用户体验的不一致。因此作为产品所有者或设计师,我们必须创建并遵循自己的设计规范。
2、多人协作
软件通常是由一个团队设计出来的，有时甚至可能是很大的团队。这就意味着，创造一个连贯一致的用户体验的难度会随着团队成员的人数增加而呈指数增长。另外，无论团队协作多么一致或团队多小,不同的人总会有不同的解决方案或设计风格,很容易导致体验割裂。
3、多个平台
我们需要让产品应用于多种不同的平台和设备。为保证产品在多平台间的同步及体验的一致性，通常需要在不同平台上去做很多重复性的工作。
4、软件是连贯的
软件的另一个不同之处在于，虽然它可以被认为是一个产品，但他不会像传统的消费品那样真的磨损或被更换。即使公司和其产品本身发生了大的变化，多年前的代码和设计仍然会存在于产品的许多地方。这就要求不断的维护和升级。
二、马上开始
为了迅速解决我们前面提到的挑战，我们挑选了一些设计师和工程师组建了一个小组，把手头的工作全部放下，在公司外面找了一个工作室，专心于设计创建这套设计语言系统（DLS）。
我们为DLS设置的目标是创建一个更美观和通用性的设计语言。通过定义好的可复用的组件来提高效率。为了集中我们有限的精力,我们优先选定了客户端平台：Android和IOS。
我们开始重新审视和打印出我们以往的那些设计稿。然后将这些设计稿按照顺序依次粘贴在一个板子上，这样我们就能找出哪块的体验比较糟糕并提出优化方案。我们认为,创建一个设计规范最好的开始方式就是先把现有的难题处理掉。我们每个人都分别专注于那些需要重新设计的产品页面或是某些模块，很快我们就建立起了一套指导原则：
1、统一性
每个模块的设计都是整体的一部分,应该对整体的表现有正向的提升作用。不应该有单独的特性或风格。
2、通用性
Airbnb在全世界都被广泛地应用。我们的产品和视觉语言应该被所有用户认可并理解。
3、形象化
我们同时专注于功能设计和视觉设计，我们的产出物应该能清晰地引导用户的认知。
4、会话式
我们使用了动态呼吸式的表现手法让用户能够轻易地理解我们的产品。
三、奠定基础
在开始设计这个系统之前,我们已经创建了一个基本的风格指南,我们称为基础部分。这个基础简单地定义了我们的字体、颜色、图标、间距和信息结构。当设计师们在各自探索多样化的创意设计方案时，这个基础风格指南对于一个统一的设计规范来说是必不可少的。我们觉得自己都非常努力，因为我们在为共同的理想工作。回顾我们集体工作的每一天,我们开始看到这个系统模式渐渐浮现出来。我们会在必要时采取纠偏措施,开始定义标准化的组件。
四、创建组件
一般来说,许多风格指南定义组件都被作为“原子组件”,然后用于构建更复杂的“分子组件”。理论上，这种做法能很好的构建连贯灵活的系统。而在现实中，更可能的情况却是：这些可复用的组件被各种方式整合在一起，形成一个更复杂的“分子组件”。其结果往往是造成了各种杂乱脱节的体验，使系统难以维护。
为了避免依赖“原子组件”，我们转而开始考虑把组件作为一个活的有机体元素。它们有功能和特性,是由一组属性定义构成,可以与其他元素共存，也能单独起作用。
一个统一的设计语言不应该仅仅是一组静态规则和单个组件构成的，它应该是一个不断发展的生态系统。
例如,我们的用户头像元素可能最初是被一个风格指南定义的,但最终被用于各种平台上时可能要面临不同的排列或呈现方式,这会导致我们后续难以更新。所以我们必须要在做好适配的前提下解决这个问题。
每个组件都会定义一些必需的元素(如标题、文本、图标和图片),有时也可能包含其他可选元素。这些元素在Sketch文档和代码层都要被定义。不是让层独立于组件起作用,我们要求每个组件都有一个层,并能在视图逻辑上可见或隐藏。
构建组件库
我们在创建这些组件的同时，会把他们收集在一个叫做库的根文件，这种做法贯穿整个设计过程中。一两周后,我们开始看到通过在反复的设计中使用库文件所带来的生产力上巨大飞跃。某天,当最后的原型确定了之后,我们的团队已经能够使用我们的库文件提供的框架在短短几小时内创造近50张设计稿。
随着库文件的扩张,我们开始把各个功能相似的独立组件整理到一个画板中，做好分类。这些画板由一系列常规的分类组成：导航，移动文本，图片和特殊类。
我们创建了一组用于手机的组件(iOS和Android),并让他们适配平板电脑。平板电脑上的组件在很大程度上跟手机上的相同的，从技术层面上来说只需要一套代码，两套不同的样式而已。类似于为网页设计而生的响应式设计方案，这些系统组件在外观和位置上都可以不同。设计师可以使用常规组件设计一个版本，之后就可以很容易地适应IOS和Android下的不同屏幕尺寸。
对于平板电脑,我们创建了一个简单布局的概念，如焦点视图，它聚焦于页面内容，模态窗口和网格布局。
所有的组件和视图都是用我们自己的技术视图框架构建的，用来处理这些风格，状态和自适应性。
经验教训
我们知道这是一个具有挑战性的项目。这意味着要重新设计和重新构建应用程序中的大多数视图。我们尽最大的努力创建出一个视觉语言系统并于4月17日发布新应用程序。在以后的项目中,我们希望我们能够避免下面这些坑。
1、并不是所有的组件都是同等优先的
在大多数应用程序中都会有一套组件是经常重复使用的。对我们来讲，这些组件就像表格中的行元素。回想一下,我真希望我们花了更多的时间来考虑这些组件并产出一套强大的模式和组件库。事实上在最后，我们曾经被那些不一致的组件伤透了脑筋。
2、Sketch
我们最初试图在Sketch中用创建符号的方式来做这些组件，但最后导致一片混乱。即使是现在，我们的设计文件有时仍难以维护。下一步，我们能找到更好的办法来维护和创建新组件。
3、文档
这个项目要求我们在有限的时间内完成，导致我们忽视了一些文档记录的工作。文档的缺乏带来了一些本可以避免的混乱。像编程一样，创建良好的文档的至关重要的。对我们而言，这是一个迟早要做的事，以便让我们在做每个决定时有更清晰的思路和参考。
三、结论
这是一个里程碑式的任务，虽然这让很多产品团队成员付出了很多，但最终我们发现创建一个自己的设计语言系统是非常值得的，也是迈向未来的巨大一步。
自从设计语言和代码可以方便的共享以来，我们现在可以在所有客户端平台上大致同步的构建和发布功能。而开发进度也明显更快了,因为产品工程师可以将更多的注意力放在写功能逻辑而不是视觉代码上。此外，工程师和设计师现在也都是用同一个设计语言。
设计师们对这个系统特别兴奋。它让产品人员更加关注真实的需求和设计体验，而不是填充、颜色和类型的选择。这套设计语言让我们的视觉风格保持了很好的一致性，让整个系统更加的流畅。这个系统还使我们所有人能够更快的实现高保真原型和任何想法的呈现，而成本却更低。
我相信在这套系统的辅助下，我们可以将更多精力集中在关注实际的用户体验和我们想要传达给用户的概念和想法上。
-END-
作者：Karri Saarinen
译文来源：http://airbnb.design/building-a-visual-language/
原创文章，作者：ioued，如若转载，请注明出处：https://www.iamue.com/15919/
