尽管目标有所不同，但所有的设计语言系统都拥有一些共同点：为了让团队成员更便于拓展和使用。

但如果我们把时间都花在设计产品组件上，那我们会忽视一些隐形的组件——团队与设计系统之间的整体关系。

这个设计系统终究是服务于人的，因为设计师和工程师才是它的使用者，所以当下我们需要搞清楚一个问题：

如何将这个设计语言系统（DLS）融入我们的日常工作中，并更好地帮助我们建立成功的团队？

以下将分享，Airbnb是如何让设计语言系统（DLS）更具有包容性、并让整个团队成员能够参与到这个系统中。

带一点历史

早在2016年，我们团队的工程师和设计师共同创建了Airbnb第一个设计语言系统（DLS）。

因为当时公司逐渐壮大、团队发展迅速，所以我们希望通过这个系统，打造一致的产品体验并保持跨平台设计的统一性。

自那之后，我们的设计团队也取得了长足的发展。虽然这个设计语言系统确实很有价值、使用频率很高，但我们面临一个很棘手的问题就是——它无法满足不断增加的新需求：

许多需求里的新组件设计出来但没有及时放进系统里；各种文件在团队间共享但没有统一的命名…

当时团队发展非常迅猛，Airbnb已经从单一的App，快速发展成为支持多种业务的平台，所以这其中的跨业务协同显得非常重要，毕竟我们不希望在用户界面上也呈现出背后团队的这种混乱状态。

因此，我们创建了一个循环反馈机制，将团队中的所有人连结一起。

重塑协同关系

去年我们尝试通过评审会（critique model）的形式，让整个Airbnb的设计师可以聚在一起分享对产品的反馈和系统性思考，同时我们将这种循环反馈也作为设计语言系统（DLS）建设的一部分。

虽然这是一个良好的开端，不过当团队里的人越来越忙，参加评审会的人也越来越少。当我们问到他们为何不再参加评审会时，他们说起初参加是出于自身的热情，但这似乎对团队的工作并没什么必要性。

显然，设计师们虽然希望有更多的时间参与其中，但也希望他们的参与能带来一定的成效。

但当时这种评审会看起来只是在占用设计师们额外的时间，因此我们从以下几个关键点着手，来建立我们评审会对整个团队的协同关系：

1.明确价值

问题：设计师们不确定各自团队的管理者们是否支持我们跨业务团队的合作

解决方式：我们寻求了管理者的支持，并确保得到他们的认可

2.任务分配

问题：尽管得到了许多反馈建议，但设计师并不清楚哪些反馈需要被执行，以及执行的优先级是怎么样的

解决方式：我们制定了具体可行的目标并持续跟进，让设计师确切知道当下该关注什么

3.合作共享

问题：设计师渴望合作，并将他们的成果与其他业务团队分享交流

解决方式：我们提供更多机会让设计师们能够分享、交流他们的项目经验并互相学习

启动设计小组

虽然设计师们的合作是关键，但管理者的意见会最终决定这个设计小组的成败。

所以在启动这个计划之前，我们让管理者们亲自任命自己团队中的一两名设计师参与到设计小组当中。同时为了让整个任命更正式，我们为这些设计师举行了小型庆祝活动，庆祝他们在团队中获得的新角色。

随着越来越多的设计师加入到这项计划当中，我们成为一个横跨整个Airbnb业务部门的设计小组；从会议邮件、平台到内部系统等，我们设计了大大小小无数组件模版。

同时我们会在每个季度为参与设计小组的设计师们提供绩效评价，让他们各自团队的管理者们了解到他们在这个计划中做出的贡献。

拓展小组事物

我们的设计小组定期会举办评审会，请设计师们针对“如何改进设计系统”发表自己的想法并就此进行投票（例如，建立模式库或研究产品主题），这个过程也让每个设计师更加明确需要改进的方向。

同时为了让设计师们聚在一起能够更有效的相互学习、将系统性思维应用于实际项目中，我们的评审会包含了以下几个部分：收集问题-开放讨论-提出方案-设计产出-落地项目-反馈。

 除了评审会，我们还开展了设计短跑项目：

在两周内，产品设计师和系统设计师共同完成一个新的边栏筛选设计，让用户能够更容易的找到合适的住所与体验。

当时我们在第一周完成设计后，便交由产品研发团队并快速进行了用户测试。这使设计师们可以快速接收到近乎实时的反馈，并让他们的设计能够保持前进的步伐。

在第二周，产品设计师和系统设计师在他们各自团队中汇报了这个项目，也得到了团队中许多研发、数据分析和内容策划等方面的建议。

最后这个设计短跑项目得益于各团队的支持，已经落地到我们实际的产品当中，并作为我们设计系统里的模版，供所有团队使用。

是时候检验成果了

追踪设计的成效有助于我们验证设计小组的价值。

比如Airbnb支付业务团队的设计师Lesar Stepputat，在他们业务团队中一直致力于改善下拉选择状态的设计。

通过我们的设计小组，他让下拉选择状态成为设计系统里的模版并应用到各个团队中，改善了整个Airbnb的产品体验。

另外，评审会的出勤率也是检验我们设计小组是否成功的指标之一。

虽然一开始只有少数人参加，但经过我们长期的努力，现在平均有60-70%的成员会定期参加评审会。

不过我们也有需要改进的地方，比如设计师们希望团队在建立设计系统的时候，能够同时开放反馈机制，并在设计过程中就对这些反馈做出及时的回应与调整。

当下，我们也在不断的改进。

回顾

在这个过程中我们也认识到，保持包容的思维方式可以在团队间达成良性的沟通，才能建立起取得实际成效的协作关系。

当我们营造出可持续的团队文化，我们的设计语言系统才能与团队更紧密的联系。

公司需要具有更包容的团队文化，让成员们能够共同完善设计系统，才能让这个系统更有效地服务于我们的日常工作。

否则，设计师们只会觉得这个设计系统限制了他们的创作。毕竟我们建立设计系统的初衷，还是在于为团队建立可持续的设计协同支持。

有机的设计语言系统

就像种一棵树，团队创建的设计语言系统也需要维护，才能获得更好的成效。

我们的设计系统的种子已经种下，现在我们的团队正在共同维护和发展它。在这种新工作模式下，让团队成员们能够获得认可、增进信任并在彼此间建立牢固的协作关系。

通过团队里的相互学习与实践应用，也让我们能够为整个Airbnb社区提供更好的体验。

如果你想了解「设计语言系统」具体需要包含什么内容&规范，请点击此处，查看我们之前分享的另一篇文章。

+++++

本文由 SDL艺术实验室 公众号原创，如需转载，请在下方联系公众号后台

原文链接：https://mp.weixin.qq.com/s/jBsN20OIwMD8i3C0IdmVBw

Powered by Froala Editor