在Airbnb新的设计系统的幕后建立一个视觉语言

在软件开发和设计方面,我们通常需要提供一次性解决方案。有时我们在时间限制内工作,有时候我们还没有就前进的道路达成一致。这些一次性解决方案本质上并不坏,但如果它们 […]

2018年4月12日

在软件开发和设计方面,我们通常需要提供一次性解决方案。有时我们在时间限制内工作,有时候我们还没有就前进的道路达成一致。这些一次性解决方案本质上并不坏,但如果它们不是建立在坚实的基础上,我们最终会发现自己不得不偿还已产生的技术和设计债务。

视觉语言就像任何其他语言一样。如果语言不被使用者共享和理解,则会产生误解。随着产品或团队的增长,这些模式中的挑战越来越复杂。

设计一直是主要针对系统的,以及如何创造出更具有柔性和可复现的产品。从Pantone颜色到飞利浦螺丝,这些系统使我们能够管理混乱并创造更好的产品。数字产品可能是实施这些系统最肥沃的基础,但它通常不被视为优先事项。

一个统一的设计系统对于更好更快地构建是至关重要的 更好,因为我们的用户更容易理解凝聚的体验,而且速度更快,因为它为我们提供了一种通用的语言。

 

为什么我们需要设计系统?

Airbnb已经经历了很多成长多年。目前,我们的设计部门由将近十二个职能部门和结果团队组成。很明显,我们需要更系统的方法来指导和影响我们的集体努力方向。虽然我们认识到了公司内部的这些挑战,但我认为它们仍旧是软件行业更大问题的征兆。

约束过少
软件设计与许多其他设计学科相比,几乎没有物理约束条件。这为任何挑战提供了多种解决方案,但也会将其打乱以使得用户体验脱节。作为产品所有者和设计师,我们必须创造并遵循我们自己的约束。

多个设计师和利益相关者
软件通常是由团队建立的—甚至是令人难以置信的庞大团队。随着更多人加入混合体系,创造连贯体验的挑战将呈指数级增长。同样,随着时间的推移,不管多么一致或者微弱的团队,不同的人会贡献新的解决方案和风格,导致经验分歧。

多种平台
我们需要在多种平台和设备上运作我们的产品。保持功能和设计同步需要花费大量精力,通常需要在所有这些平台上重复相同的工作。

软件作为一个连续体软件的
软件的另一个独特之处在于,虽然它可以被认为是一种产品,但它并没有像传统的消费产品那样被磨损并被取代。即使是在一家公司及其产品的格局发生重大转变之后,很多地方仍然存在许多代码和设计。这需要不断的维护和升级。

 

创业的初始

为了解决这些挑战并使我们的决策过程保持快速,我们组建了一个由设计师和工程师组成的团队。我们清理了日历,在Airbnb HQ外部预留了一个外部工作室,并致力于设计和构建设计语言系统(DLS)。

我们为DLS设定的目标是创建更美观,更易于使用的设计语言。我们的设计应该是统一的平台,通过定义明确的可重用组件的驱动来提高效率。为了集中我们的精力,我们首先将初始范围缩小到在本地平台(iOS和Android)上创建系统。

我们开始审核和印刷我们的许多设计,有新的也有旧的。将流程并排放置在一块木板上,我们可以根据经验看到在哪里需要突破,以及我们需要在哪里开始进行更改。我们认为最好的方法是开始解决问题。我们每个人都专注于要重新设计的屏幕或产品领域,并且我们建立了一些原则来指导我们使用这些单独的设计:

统一:每一件部分是一个更大的整体的一部分,应该在规模作出积极贡献的系统。不应该有孤立的特征或异常值。

通用:Airbnb是用于世界各地的广泛的全球社区。我们的产品和视觉语言应该是受欢迎和可访问的。

标志性的:我们重点着力于设计和功能方面。我们应该大胆和明确地阐述这一重点。

可交互式的设计:我们对手势的运用,给产品注入了活力,同时也让我们可以以更通俗易懂的方式与用户交流。

 

奠定基础

在开始这个设计冲刺之前,我们已经创建了一个基本的风格指南,我们称之为基础。这个基础松散地定义了我们的印刷术,颜色,图标,间距和信息架构。这一基础对于指导我们统一方向的工作至关重要,同时为我们提供空间探索创意设计解决方案。这样我们就觉得我们都在一起工作,朝着同样的想法走。在每天结束时回顾我们的集体工作,我们开始看到模式出现。我们在必要时纠正了错误,并开始定义我们的标准化组件。

创建组件

传统上,许多风格指南将组件定义为原子组件,然后用它们构建更复杂的分子。从理论上讲,这可以很好地创建连贯而灵活的系统。然而,在实践中,经常发生的是这些可重复使用的原子以多种不同的方式组合,从而允许创建各种分子。再次,这为各种脱节的经历打开了大门,并使系统难以维护。

我们不再依赖个别原子,而是开始将我们的组件视为活生物体的元素。他们具有功能和个性,由一系列属性定义,可以与他人共存并可以独立演变。统一的设计语言不应该只是一套静态规则和单个原子,而应该是一个不断发展的生态系统。

统一的设计语言不应该只是一套静态规则和单个原子; 它应该是一个不断发展的生态系统。

例如,我们用户虚拟化身的元素初始是由设计规范定义的。但当最终使用到平台上时,其可能会有数百上千种变形。这让我们将来的更新这些元素的工作变得困难。我们必须要确认,当我们修改他们中的任何一个,都不会影响到其他屏幕的排列显示。

每个组件都由其必需的元素(例如标题,文本,图标和图片)定义,并且有时可能包含可选元素。这些元素都在Sketch文档和代码中定义。我们不需要允许分隔线本身,而是要求每个组件都有一个分隔线,然后基于视图逻辑来对其进行可视或隐藏。

编译库

在创建这些组件时,我们将它们收集在一个名为库的主文件中,我们在整个设计过程中都会提到它。一两周后,我们开始看到在迭代设计时通过使用库来实现生产力的巨大飞跃。有一天,在整理最后一分钟的原型时,我们的团队通过使用我们的库提供的框架,能够在几个小时内创建近50个屏幕。

在编译库不断增长的同时,我们开始将各个组件组织成包含类似项目的画板。这些画板然后按照一般类别组织成:导航,标签,内容,图像和专业。

我们为手机(ios和Android)创建了一组这些组件,并从中调整了它们的平板尺寸。平板电脑组件大体上与手机组件相同,在技术层面上,代码只需要以两种不同的风格存在一次。有了这个系统,组件的外观和定位可能会有所不同,类似于响应式设计适用于网络的方式。然后设计师可以使用通用组件设计一个屏幕,并且可以轻松适应不同的屏幕尺寸以及ios和Android。

对于平板电脑,我们创建了几个简单的布局概念,例如Focus Views,它将内容集中在页面,模式和2列和网格布局上。

所有的组件和视图都是用我们自己的技术视图框架构建的,用它处理这些样式,状态和适应性。[2]

 

经验教训

我们知道这是一个具有挑战性的项目。这意味着需要重新设计和重建我们应用中的大部分视图。我们的目标是在4月17日创建这个系统并发布新的应用程序,就像许多项目一样,我们希望希望我们能采取不同的做法。

并非所有组件都是相同的 在大多数应用程序中都有一组经常重复的组件。对我们来说,这些组件是行(或表格单元格)。回顾一下,我希望我们花了更多时间思考这些行,并提出一套更强大的模式和组件。最后,我们以许多不同的方式解决了一些不一致的问题。

草图 我们最初尝试在草图中创建这些组件作为符号,导致一团糟。即使现在,我们的Sketch文件有时也很难维护。展望未来,我们希望找到更好的维护和创建新组件的方法。[3]

文档 这个项目需要我们在规定的时间内进行操作,这使我们忽略了一些文件处理过程。文件的缺失造成了一些本可以避免的混淆。就像编码一样,创建文档系统对于这个过程至关重要。它迟早要进行,并且在整个创建过程中进行记录可以使决策更顺利。

 

结论

虽然这是一项艰巨的任务,最终经过我们许多产品团队的努力,我们发现创建我们的设计语言系统是值得的投资和巨大的飞跃。

由于设计语言和代码经常是共享的,我们现在可以在相同的时间里在所有本地平台上构建和发布功能。开发速度通常更快,因为产品工程师可以更多地关注编写功能逻辑而不是视图代码。此外,工程师和设计师现在共享一种通用语言。

设计师也对这个系统感到兴奋。它使产品评论能够专注于设计的实际概念和体验,而不是填充,颜色和类型选择。DLS为我们提供了对视觉风格的共同理解,并简化了对单个系统的贡献。该系统还使我们所有人能够更快,更低成本地以高保真的方式进行原型设计和实验。

我相信借助这些系统,我们可以更多地关注我们想要在未来创建的实际用户体验和概念。

 

作者:Karri Saarinen
责编:王尚非
编辑:季佳宁
翻译:夏敏

发表评论

电子邮件地址不会被公开。 必填项已用*标注