10 个品牌设计系统清单:从 Nord 到奥迪,哪些做法值得设计师直接抄

设计师建设计系统最容易踩的坑:做完了没人用。Smashing Magazine 整理了 Nord、Gusto、奥迪、奥运等 10 个品牌设计系统清单,涵盖命名规范、无障碍、动效、Figma 工具包与 ROI 计算,可直接参考借鉴。

看完这篇,你会知道:

1. 哪 6 个设计系统的做法最值得设计师直接参考

2. 为什么命名规范是设计系统能不能真正落地的关键

3. 怎么从中提取对自己项目有用的部分

—

# 设计系统:真实案例与资源清单

设计师做设计系统,最常遇到的情况是这样的:组件库越来越厚,文档写了上百页,设计师和开发者却还是各用各的,最后设计系统变成了一个「存了好看」的文件柜。

问题出在哪?

Smashing Magazine 的编辑 Cosima Mielke 整理了一份真实设计系统清单,覆盖 Nord、Gusto、奥迪、奥运、Deutsche Bahn 等 10 个品牌,每个都有具体做法和参考链接。这篇文章把清单里的精华提炼出来,告诉你哪些可以直接抄、哪些要绕开。

—

Workbench:做得好不好,要看有没有「现场示例」

Gusto 是一家服务超过 20 万家企业的薪资与 HR 软件公司。他们的设计系统叫 Workbench。

Workbench 的做法值得看,因为它真正解决了「组件库和实际工作」之间的脱节。它包含:设计哲学、设计令牌、创意资产、React 组件、工具函数,以及把这些串起来的文档。

最值得注意的一点:它有详细的现场示例(live examples),解释每个组件在什么场景下该怎么用、什么场景下不该用。视觉化的 do’s and don’ts,配上实现细节,设计师和开发者都能直接上手。

还有一个彩蛋:Gusto 提供 VS Code 插件,内置常用 UI 组件代码片段。开发者在写代码的时候,不用离开编辑器就能参考设计系统的规范。

这对设计师的启示:你的设计系统里,有没有给开发者的「现场代码示例」?还是只有截图和设计稿?

—

Nord:无障碍不是附加项,是设计系统的默认项

Nord 是北欧医疗科技公司 Nordhealth 的设计系统。因为面向医疗场景,它的设计系统从一开始就把无障碍(Accessibility)作为核心,而不是后来补上的功能。

Nord 提供:丰富的定制选项、多套主题、完整的 CSS 框架,以及针对命名规范(naming conventions)和本地化(localization)的专项指南。

设计系统做好无障碍,不是「给残障人士用的」这么简单。Nord 的思路是:如果一个界面对认知障碍用户足够友好,它对所有用户都会更友好。减少认知负荷,让所有人都能用,这是无障碍设计的底层逻辑。

Nord 的 Figma Toolkit 目前还没有开源,但 CSS 框架和文档是公开的,可以直接参考。

—

奥迪:用「正面和反面」来定义组件使用规范

奥迪的设计系统,最有参考价值的部分不是组件本身,而是它的「视觉对照」。

它提供了大量组件的正面和反面使用示例——这个按钮应该用在什么场景?什么场景下不该用?颜色、尺寸、层级关系,全部用真实的界面截图对比说明。

奥迪的产品横跨网站、App、车载界面,每个平台的组件使用规范都有对应的 Figma UI Kit 和 Sketch UI 库。设计师在工具里就能直接用到最新的组件和图标,不用靠手动维护版本。

这对设计师的启示:你的设计系统里的组件规范,有没有说明「什么情况下不该用」?

—

奥运品牌系统:多语言、跨文化的品牌一致性

奥运可能是全球认知度最高的品牌之一,横跨 125 年、无数个主办国和项目。奥运品牌系统面临的核心挑战是:如何在如此复杂的体系里保持一致性,同时还能适应多语言和跨文化的传播场景。

奥运品牌系统没有把「一致性」理解为「所有地方一模一样」。它平衡了「一致性」和「灵活性」的关系:核心识别元素不变,具体实现形式可以因地制宜。

这个思路对设计师的参考价值:在做多语言或多品牌的设计系统时,区分什么是「不可变的核心」,什么是「可以本地化的部分」,是设计系统架构里最重要的一步。

—

命名规范:设计系统能不能活起来的关键

这份清单里几乎所有设计系统都在强调一件事:命名规范。

为什么这么重要?

因为设计系统最终要被团队里所有人使用——设计师、开发者、内容编辑、项目经理。如果每个人对同一个组件的叫法不一样,系统就变成了一个「需要翻译才能使用」的工具。

Nord 的设计系统专门提供了 naming conventions 指南,不是给组件起个名字那么简单,而是建立一套团队所有人都能理解的命名规则——从颜色、文本样式到组件状态,全部有统一的命名约定。

Smashing Magazine 推荐的三个资源帮你把这块做好:

• Ardena Gonzalez Flahavin 的文章,讲为什么要在意命名以及怎么做
• Shayna Hodkin 的实践指南,覆盖颜色、文本样式、图层样式和组件命名
• Jules Mahe 的方法,讲如何在「清晰度」「可搜索性」和「一致性」之间找到平衡

这三个资源组合起来,就是一套可以直接用到自己项目里的命名规则制定流程。

—

动效:把「动效规范」做成组件的一部分

Salesforce 的设计系统里,有一个独立的动效语言系统,叫 Kinetics System。它的核心思路是:让动效成为组件的默认属性,而不是后期加上去的装饰。

也就是说,当你使用一个组件的时候,这个组件的动效已经是预置好的——滑入、淡出、悬停反馈,全部是设计系统的一部分,设计师和开发者不需要每次都重新定义。

这对设计师的参考价值:在做设计系统的时候,动效不是「做完设计再想」的事情,而是应该在设计组件的时候就把动效规则写进去。

—

Figma 工具包:从这些开始建立自己的资源库

如果你在建自己的设计系统,或者想参考大厂怎么做 Figma 组件库,这两个资源值得收藏:

Design Systems for Figma(designsystemsforfigma.com):Atlassian、Uber、Shopify、Slack 等知名公司的设计系统 Figma 工具包,全部免费,按品牌分类,可搜索。

GOV.UK Design System Figma Kit:专门针对复杂用户旅程和网页表单场景,来自英国政府数字化服务(GDS)的设计系统,质量相当高。

这两个工具包不只可以用来参考,还可以直接导入自己的 Figma 项目作为起点。

—

ROI:怎么证明设计系统值这个投入

很多设计系统在立项的时候就被问倒:「这个系统做出来,能带来什么价值?」

Jules Mahe 的文章专门讲怎么给设计系统算 ROI。他提出了几个关键步骤:

第一步:定义 KPI。你的设计系统要解决什么问题?效率提升?一致性提升?减少设计稿返工?指标要提前定好。

第二步:收集定量数据。组件使用频率、设计稿从概念到交付的时间、跨平台一致性违规次数,这些数字会说话。

第三步:加上定性数据。用访谈和问卷,让使用者描述设计系统对实际工作的影响。有具体故事的 ROI 数字,比单纯的百分比更有说服力。

第四步:把数据用起来。数据不是为了证明你做了正确的事,而是为了告诉你下一步该做什么。

—

设计师怎么从这份清单里提取对自己有用的部分

看完整份清单,设计师最容易犯的错是:看到好的案例就全套照搬,结果做了半年,发现和自己的项目完全对不上。

更高效的做法是按这个顺序来:

第一步:找到和你项目规模最接近的案例。如果是中大型团队,Workbench 的文档结构和命名规范做法最值得参考。如果是初创团队,先看 GOV.UK 的 Figma 工具包,从已经验证过的组件库起步。

第二步:把命名规范作为第一个要做的事情,不是最后一个。Nord 的案例已经证明,命名规范没有做好,后面所有的组件和文档都会慢慢失效。

第三步:把动效和无障碍作为设计系统的默认层,而不是附加功能。Salesforce 和 Carbon 的做法已经说明,把这些功能做进底层,比后期打补丁效率高三倍不止。

—

关于这个话题,我还有一些想聊的,但今天先到这里。

如果你在做设计系统,或者正在经历「设计系统做好了没人用」的困境,欢迎在评论区给我留言,咱们一起讨论。

也欢迎告诉我你最想看哪类内容,我来安排。

—

> 关注公众号「设计师邱兴」,回复「资料」,可免费领取 UI 及 AI 相关的素材及资料!

—