这是Airbnb 设计语言系统系列文章中的一篇。
在进行产品设计和开发的时候，我们常常被要求提供一次性的解决方案，这是因为我们有时候并没有就前进的方向达成一致，却需要在紧迫的时限下完成交付。我们不能说这种一次性的解决方案完全没有质量，但是如果他们没有建立在坚实的基础上，长此以往我们终究会发现自己背了一屁股的技术和设计债。
视觉语言和其他任何语言一样，误解的产生源于所有的使用者之间没有充分分享和理解。而随着团队和产品的成长，我们同样会面对复合模式形成的挑战。
设计的意义很大程度上在于创建一套系统，并且使用这套系统以可扩展和可复制的方式创建产品。从Pantonecolors到Philips screws，这些系统帮助我们解决混乱，创造更好的产品。数字类产品也许是证明这些系统的最肥沃的土地，但可惜的是这通常不被当作优先事项。
一个统一的设计系统对于更好更快地构建产品是必不可少的，更好源自于高度统一的体验能让用户更容易理解和使用产品，而更快是因为我们可以在同一种语言环境下工作。
为什么我们需要设计系统
多年来，Airbnb经历了高速的成长。目前我们的设计部门由十几个职能和交付团队组成。很明显，我们需要更系统的方法来指导和整合我们的团队力量。我们已经认识到了公司内部的这些挑战，但我相信它们更是大部分软件行业普遍存在的问题。
缺乏约束：与其他门类的设计相比，软件设计几乎没有物理约束。这能够让设计师用各种方法去应对给出的任务，但这也为用户体验的不一致埋下了隐患。作为产品责任人和设计师，我们需要制定和遵循自己的规范。
多设计师和多利益相关者：软件设计和开发通常是由团队完成的，有时甚至是巨大的团队。随着越来越多的人加入到这个组合中，创造一致体验的挑战成倍增加。同样，随着时间的推移，无论团队有多团结或有多小，不同的人都会贡献出新的解决方案和风格，最终导致体验的离散。
多平台：用户在多个平台和设备上使用我们的产品。保持功能和设计的同步需要很大的努力，通常需要在所有这些平台上重复相同的工作。
产品的连贯性：软件产品的另一个独特之处在于，虽然它可以被视为一种产品，但并不像传统的消费品那样会被真正地折旧和取代。多年前创建的代码和设计依然在很多地方存在，即使公司的格局及其产品发生了重大变化，仍然需要不断的对他们维护和升级。
起步
为了解决这些问题和保持决策的敏捷性，我们成立了一个由设计师和工程师组成的小团队。我们调整了自己的工作日程，在Airbnb总部以外找了个工作室，开始致力于设计和搭建我们的设计语言系统（DSL）。
我们为DSL设立的目标是创建一套更美观和更好用的设计语言，我们的设计应该是在统一的平台上，通过定义清晰和可重复使用的组件来达成高效。为了集中精力，我们从一开始就确定了工作范围，先在native平台(iOS和安卓)创建系统。
我们认为最好的开始方法是直面问题，所以我们的工作从打印和审阅大量的新老设计开始。将流程排列放置在一块板上，这样可以让我们看到在哪里需要和如何打破这些体验，以及在哪方面需要做出改变。我们每个人都专注于某屏页面或某个产品领域进行重新设计，我们建立了一些原则来指导我们进行这些个性化设计：
统一性：每一元素都是更大整体的一部分，应该在不同规模上对系统作出积极贡献，不应该有孤立的特征或异常值。
通用性：Airbnb产品在世界各地，被广泛的全球社区使用。我们的产品和视觉语言应该是友好的和易用的
标志性：我们专注于设计和功能。我们的工作应该大胆而清晰地表明这个重点。
可对话：我们的行动让产品焕然一新，让我们能够以易于理解的方式与用户进行沟通。
奠基
在开始这个设计冲刺项目前，我们已经创建了一个基本的规范，我们称之为基石。这个基石宽泛地定义了我们的排版、颜色、图标、间距和信息架构。基石的存在证明了用统一的方向指导我们工作的必要性，也为我们探索个性化的创意设计解决方案提供了空间。 我们感受到大家在一起工作，朝着同一个方向努力。每天结束时候回顾我们一天的合作，我们渐渐看到了模块的雏形。需要的时候，我们也会调整方向，并开始定义我们的标准化组件。
创建组件
传统上，许多设计规范是把组件作为原子，然后用来搭建更复杂的分子。从理论上讲，这对于创建连贯和灵活的系统很有效。然而，在实践中经常发生的情况是，这些可重复使用的原子以许多不同的方式被使用，允许各种各样的分子被创造出来。同样，这为各种脱序的体验打开了大门，使系统更难维护。
不再依赖单个的原子，我们考虑把我们的组件看作一个有生命的有机体中的元素。他们有各自的功能和个性，由一套属性来定义，可以与其他元素共存，可以独立进化。统一的设计语言不应该只是一套固定的规则和独立的原子，而是一个不断进化的生态系统。
统一的设计语言不应该只是一套固定的规则和独立的原子，而是一个不断进化的生态系统。
例如，我们的用户角色元素也许初始时是遵循某个设计规范创建的，但最终在平台上使用的时候可能有上百种排列方式，这使得我们想要更新这个元素的时候非常困难。但在新的设计语言系统中，如果我们想更新其中的任何一个，我们可以确保不会破坏其他的页面。
每个组件都由其必需的元素（如标题、文本、图标和图片）定义，有时可能包含可选元素。这些元素既在Sketch文档中定义，也通过代码进行定义。我们不允许设计师自行添加分割线，而是给每个组件加上一个分割线，然后根据视图逻辑显示或隐藏该分割线。
编制设计库
在创建这些组件时，我们把他们归集到一个主文档中，并将这个贯串所有设计流程的文档命名为设计库。一两周之后，我们就通过使用设计库使我们的迭代设计效率有了飞跃的提升。有一天，团队成员发现在出最终原型稿的时候，可以通过使用设计库中的框架在短短几小时中产出50几个页面。
随着设计库的不断成长，我们开始把各个组件组合成包含相似内容的页面（artboards），这些页面被按一般分类整理成：导航，滚动效果，内容, 图片和专用。
我们为手机(iOS 和安卓)页面创建了这样一套组件，并在此基础上调整尺寸适应平板电脑。平板电脑的组件与手机端的基本相同。从技术层面，只需要用一套代码以不同的形式展现即可。使用这套系统与在web端使用响应式设计系统一样，组件的外观和位置可以有所不同。设计师只需要用通用组件设计一个页面，它可以很容易地适应不同的屏幕大小以及iOS和安卓。
我们为平板电脑创建了一些简单的布局概念，比如将内容集中在页面，弹窗，两列式和网格式布局上的焦点视图。
所有的组件和视图都是在我们自己的技术视图框架中构建的，这个框架同时可以解决样式、状态和适应性的问题。
踩过的坑
我们知道这是个充满挑战的项目。这等于重新设计和搭建了我们App上的大部分页面。我们的目标是在4月17日创建系统并同时发布新的App。和任何项目一样，我们希望我们做的事情与众不同。
组件的设计上要有侧重点：在大多数App中，都有一组经常被重复使用的组件。对于我们来说，这些组件是行（或表单）。我们应该花更多时间来考虑这个问题，并提出一组更强大的模块和组件。实际是，我们总结许多不同的类型，但存在一些不一致问题。
Sketch：我们最初尝试在Sketch中创建这些组件作为标记，结果却导致了混乱。即使现在，我们的Sketch文件有时也很难维护。展望未来，我们希望找到更好的维护和创建新组件的方法。[注]
文档化：这个项目时间紧任务重，这导致我们在项目过程中忽略了一些文档的建立。由于文档不够完整，造成了一些本可避免的混乱。就像编程一样，在项目开始阶段就创建文档系统对整个流程至关重要。它早晚都必须完成，并且在整个项目过程中文档可以使决策更加顺利。
结论
虽然这是个艰巨的任务，需要我们很多产品团队的参与和贡献，但我们发现创建DSL是值得投入资源的，也是一个巨大的飞跃。
由于设计语言和代码经常是共享的，我们现在可以很大程度上在所有native平台上同时构建和发布功能。开发速度通常更快，因为产品工程师可以更专注于功能的实现，而不是视觉代码。同时，工程师和设计师可以使用同一种通用语言。
设计师们同样对系统的上线兴奋不已，从此以后，对产品设计质量的评价将更加集中在设计概念和用户体验上，而不是纠结于填充，色彩和类型的选择。DLS赋予我们对视觉风格的共享理解，并简化了对单个系统的贡献。这个系统还可以让我们用更快的速度和更低的成本出高保真原型和进行试验。
我相信在整个系统的帮助下，未来我们可以更专注于用户的实际体验和我们想要建立的概念。
注：
在我们的用例中，我们想让大家可以更改标签的大小（比如你需要在标签里加入更多文字）。如果你有意或无意地修改了某个标签的尺寸，Sketch(<3.5)会自动更改每个标签的尺寸。这会让你的Sketch死机几分钟，甚至有可能会永久弄乱你的文件（有时候回退不起作用），最后我们只能把组件放在LayerGroups里面，让大家去复制黏贴。
我们还使用git/github来简化文件更新过程。我们手动创建新组件并将其Sketch文件添加到主设计库中，然后使用更改日志提交抓取请求，将生成的记录更改为PNG格式导出。之后，Sketch文件最终进入一个共享文件夹，该文件夹链接到Sketch模板，使每个人都可以立即访问新组件。
Karri Saarinen 是Airbnb的主设计师。本文摘自Airbnb Design网站，点击“阅读原文”可查看英文版原文，所有版权归原作者所有。
本篇文章来源于微信公众号: TripDesign
