Airbnb首席设计师：如何创建一套自己的设计规范

注：本文是Airbnb新的设计语言的一部分，由Airbnb首席设计师Karri Saarinen发布于airbnb.design。

从事软件开发和设计工作,我们往往需要提出一个完整的一次性解决方案。但有时我们是受到时间的限制,或者我们只是还没有确定一个清晰的发展方向。一次性的解决方案并不是说它不好,但是如果它不是建立在一个坚实的基础之上,最终我们会发现自己还是不得不回过头来偿还技术积累和设计这笔债。

视觉语言就像任何其他的语言一样。如果不被使用它的每个人共享并理解，那么使用这种语言沟通将很容易出现误解。随着产品或整个团队的壮大，这种模式带来的问题也会越来越突出。

设计一直都是系统最主要的构成部分，设计规范是一种使产品达到可扩展性和可重复性的方式。无论是潘通色卡还是飞利浦发明的十字槽螺钉，这些设计规范使我们能够避免混乱,从而创造更好的产品。最适合建立设计规范的可能就是数字化产品领域了。但它往往不被我们视为优先级的事项。

更好、更快是一个设计规范最基本的要素。更好是因为一致性的体验能让产品更易用；更快是因为它为设计师提供了一套协作的共同语言。

一、为什么需要设计规范

Airbnb这些年增长非常快速。目前我们的设计部门有十多个专职设计输出小组。我们越来越意识到我们需要更系统的设计方法用来指导和提升大家的工作效率。我相信对软件行业来说，这个问题更严重。

1、缺少限制
相比于其他设计领域，软件设计几乎没有物理限制。这就意味着任何一个问题都可能有多种解决方案，但这恰恰可能造成用户体验的不一致。因此作为产品所有者或设计师,我们必须创建并遵循自己的设计规范。

2、多人协作
软件通常是由一个团队设计出来的，有时甚至可能是很大的团队。这就意味着，创造一个连贯一致的用户体验的难度会随着团队成员的人数增加而呈指数增长。另外，无论团队协作多么一致或团队多小,不同的人总会有不同的解决方案或设计风格,很容易导致体验割裂。

3、多个平台
我们需要让产品应用于多种不同的平台和设备。为保证产品在多平台间的同步及体验的一致性，通常需要在不同平台上去做很多重复性的工作。

4、软件是连贯的
软件的另一个不同之处在于，虽然它可以被认为是一个产品，但他不会像传统的消费品那样真的磨损或被更换。即使公司和其产品本身发生了大的变化，多年前的代码和设计仍然会存在于产品的许多地方。这就要求不断的维护和升级。

二、马上开始

为了迅速解决我们前面提到的挑战，我们挑选了一些设计师和工程师组建了一个小组，把手头的工作全部放下，在公司外面找了一个工作室，专心于设计创建这套设计语言系统（DLS）。

我们为DLS设置的目标是创建一个更美观和通用性的设计语言。通过定义好的可复用的组件来提高效率。为了集中我们有限的精力,我们优先选定了客户端平台：Android和IOS。

我们开始重新审视和打印出我们以往的那些设计稿。然后将这些设计稿按照顺序依次粘贴在一个板子上，这样我们就能找出哪块的体验比较糟糕并提出优化方案。我们认为,创建一个设计规范最好的开始方式就是先把现有的难题处理掉。我们每个人都分别专注于那些需要重新设计的产品页面或是某些模块，很快我们就建立起了一套指导原则：

1、统一性
每个模块的设计都是整体的一部分,应该对整体的表现有正向的提升作用。不应该有单独的特性或风格。

2、通用性
Airbnb在全世界都被广泛地应用。我们的产品和视觉语言应该被所有用户认可并理解。

3、形象化
我们同时专注于功能设计和视觉设计，我们的产出物应该能清晰地引导用户的认知。

4、会话式
我们使用了动态呼吸式的表现手法让用户能够轻易地理解我们的产品。

三、奠定基础

在开始设计这个系统之前,我们已经创建了一个基本的风格指南,我们称为基础部分。这个基础简单地定义了我们的字体、颜色、图标、间距和信息结构。当设计师们在各自探索多样化的创意设计方案时，这个基础风格指南对于一个统一的设计规范来说是必不可少的。我们觉得自己都非常努力，因为我们在为共同的理想工作。回顾我们集体工作的每一天,我们开始看到这个系统模式渐渐浮现出来。我们会在必要时采取纠偏措施,开始定义标准化的组件。

四、创建组件

一般来说,许多风格指南定义组件都被作为“原子组件”,然后用于构建更复杂的“分子组件”。理论上，这种做法能很好的构建连贯灵活的系统。而在现实中，更可能的情况却是：这些可复用的组件被各种方式整合在一起，形成一个更复杂的“分子组件”。其结果往往是造成了各种杂乱脱节的体验，使系统难以维护。

为了避免依赖“原子组件”，我们转而开始考虑把组件作为一个活的有机体元素。它们有功能和特性,是由一组属性定义构成,可以与其他元素共存，也能单独起作用。

一个统一的设计语言不应该仅仅是一组静态规则和单个组件构成的，它应该是一个不断发展的生态系统。

例如,我们的用户头像元素可能最初是被一个风格指南定义的,但最终被用于各种平台上时可能要面临不同的排列或呈现方式,这会导致我们后续难以更新。所以我们必须要在做好适配的前提下解决这个问题。

每个组件都会定义一些必需的元素(如标题、文本、图标和图片),有时也可能包含其他可选元素。这些元素在Sketch文档和代码层都要被定义。不是让层独立于组件起作用,我们要求每个组件都有一个层,并能在视图逻辑上可见或隐藏。

构建组件库

我们在创建这些组件的同时，会把他们收集在一个叫做库的根文件，这种做法贯穿整个设计过程中。一两周后,我们开始看到通过在反复的设计中使用库文件所带来的生产力上巨大飞跃。某天,当最后的原型确定了之后,我们的团队已经能够使用我们的库文件提供的框架在短短几小时内创造近50张设计稿。

随着库文件的扩张,我们开始把各个功能相似的独立组件整理到一个画板中，做好分类。这些画板由一系列常规的分类组成：导航，移动文本，图片和特殊类。

我们创建了一组用于手机的组件(iOS和Android),并让他们适配平板电脑。平板电脑上的组件在很大程度上跟手机上的相同的，从技术层面上来说只需要一套代码，两套不同的样式而已。类似于为网页设计而生的响应式设计方案，这些系统组件在外观和位置上都可以不同。设计师可以使用常规组件设计一个版本，之后就可以很容易地适应IOS和Android下的不同屏幕尺寸。

对于平板电脑,我们创建了一个简单布局的概念，如焦点视图，它聚焦于页面内容，模态窗口和网格布局。