第 8 章设计系统与设计语言（旗舰章）

这是第二篇的最后一个旗舰章,也是把前面几章串起来的一章。

第六章讲一致性是 ToB 交互的第一原则,第七章讲视觉秩序要靠规范来维持。这些"一致""规范""沉淀",最终都要落到一个东西上,那就是设计系统。设计系统,是 ToB 设计从"手工作坊"走向"工业化生产"的标志,是支撑大型复杂产品保持质量和一致的基础设施。对体量庞大、模块众多、还常常多团队协作的 ToB 产品来说,它几乎是不可或缺的。

但设计系统这件事,做起来特别容易走样。我见过太多团队,兴致勃勃地做了一套漂亮的组件库,发布会开得热热闹闹,半年后却发现:它没人用、跟代码对不上、各业务线又开始各画各的、慢慢就烂掉了。投入了大量人力,最后变成一个没人维护的"数字遗迹"。

所以这一章,我不只讲设计系统"是什么",更要讲它"怎么才能活下去",因为后者才是真正的难点,也是大多数设计系统失败的地方。

8.1 把设计系统当"产品"运营

关于设计系统,我想先纠正一个最普遍、也最致命的误解:设计系统不是一套静态的"交付物",而是一个需要长期运营的"产品"。

很多团队把设计系统理解成一个一次性的项目:集中花几个月,做出一套组件库、一份规范文档,然后宣布"设计系统建好了",大功告成,团队解散,各回各的业务线。这种理解,几乎注定失败。因为产品在演进,业务在变化,技术在更新,一套静态的设计系统,做出来的那一刻就开始过时,如果没有持续的维护和迭代,它会迅速腐化,最终被团队抛弃。

正确的姿势,是把设计系统当成一个有生命的产品来运营。这意味着什么?

它意味着设计系统有自己的"用户",使用它的设计师和工程师。你要像对待真实用户一样去理解他们:他们用起来顺不顺?组件好不好查、好不好用?文档看不看得懂?他们愿不愿意用,还是宁愿自己造轮子?一个没人愿意用的设计系统,无论做得多"完备",都是失败的。这里要做一次小小的"用户研究",研究你的设计师和工程师同事。

它意味着设计系统有自己的"路线图"。要规划接下来做什么、先做什么、怎么演进,而不是被动地等需求、哪个业务线喊得响就先满足谁。

它意味着设计系统有自己的"贡献模型"。明确别的团队想新增或修改一个组件时,该走什么流程、怎么提议、谁来评审、如何纳入。一个健康的设计系统,应该让贡献变得容易,而不是把自己变成一个只有核心团队能碰的封闭堡垒。

它意味着设计系统需要专门的"投入和角色"。它不是某个人的业余项目、不是"有空就维护一下"的边角料,而需要明确的负责人和持续的资源。

把设计系统当产品运营,是它能不能活下去的根本前提。这个观念转变,比任何具体的组件设计技巧都重要。记住:设计系统的成败,七分在运营,三分在设计本身。一个设计平平但运营得当、持续健康的系统,远胜过一个惊艳一时却很快腐化的系统。

8.2 设计令牌:语义化分层与主题化

讲完了运营哲学,我们深入设计系统的技术核心:设计令牌(Design Tokens)。这一节会稍微"技术"一点,但它是设计师该懂的技术,请耐心读完,它会改变你对设计系统的理解。

设计令牌,是把设计中的各种基础决策(颜色、间距、字号、圆角、阴影等)抽象成一个个有名字的"变量",作为设计和代码共同的、唯一的来源。比如,不再到处写"这个蓝色是 #1677FF",而是定义一个叫 color-primary 的令牌,所有该用主色的地方都引用它。这样,当主色要改时,改一处令牌,全产品自动生效。

令牌真正的威力,在于"分层"。一套成熟的令牌体系,通常分成几层,这个分层是设计系统能否优雅扩展的关键。

最底层,是原始值令牌(也叫基础令牌)。它们是一组不带语义的、纯粹的值,比如 blue-500 = #1677FF、gray-900 = #1F1F1F。这一层是调色板,是原材料。它只回答"我们有哪些颜色值",不回答"这些颜色用在哪"。

中间层,是语义令牌。这是最关键的一层。语义令牌不直接是值,而是"指向"底层的值,并且它的名字描述的是"用途"而非"外观"。比如 color-text-primary(主要文字色)指向 gray-900,color-bg-danger(危险背景色)指向 red-500,color-border-default(默认边框色)指向 gray-300。

为什么语义这一层如此重要?因为它支撑了主题化,让系统从第一天起就具备灵活适配的能力。

设想你要做深色模式。如果你当初到处直接用的是 gray-900 这种原始值,比如正文文字直接写死了 gray-900,那做深色模式就是一场灾难:你得满世界去找所有用了 gray-900 的地方,一个个判断"这个在深色下该变成什么",改到崩溃,还容易漏。

但如果你用的是语义令牌 color-text-primary,事情就优雅多了:你只需让 color-text-primary 在深色主题下指向一个浅色值(比如 gray-100),而所有引用了 color-text-primary 的地方,自动就适配了深色模式,你一个组件都不用改。同理,要支持多品牌、多客户的定制(这家客户要换个主色),也全靠这一层语义令牌的灵活指向。

业界有一句话点破了其中的关键:用语义令牌(如 color.text.primary)而不是原始值(如 gray-900),你的系统从第一天起就支持主题化。这句话值得每个做设计系统的人贴在墙上。语义化分层,不是为了显得专业的额外功夫,而是决定系统未来灵活性的根本架构选择。很多设计系统后来在多主题、多品牌上举步维艰,根子就是早期偷懒,跳过了语义层,直接用了原始值。

最上层,有时还有组件令牌。针对特定组件的更细粒度的令牌,比如 button-primary-bg(主按钮背景),它再指向语义层。这一层让组件级的精细调整成为可能,但不是所有体系都需要它,视复杂度而定,小一点的系统,两层就够,别为了"完整"而过度设计。

令牌体系的这种"原始值、语义、组件"的分层指向,本质上是一种解耦的架构思想:它把"值是什么"和"值用在哪"分开,从而让两者可以独立变化。这其实又是一种工程智慧在设计中的体现,呼应了全书"用工程的严谨支撑设计"的主线。一个理解令牌分层的设计师,思维方式已经和工程师接轨了。

8.3 治理机制:防止系统漂移

现在到了这一章、甚至是整个设计系统话题里最关键、却最常被忽视的部分:治理。

设计系统最大的敌人,不是"没建好",而是"建好后慢慢烂掉"。这个烂掉的过程,有一个专门的词,叫"漂移(drift)":设计和代码逐渐脱节、规范被各种"例外"侵蚀、同一个东西出现越来越多的变体、令牌冗余失效没人清理。漂移是渐进的、悄无声息的,等你发现时,设计系统已经形同虚设了。

我举一个业界经典的、几乎每个大团队都经历过的窘境:一次审计发现,某个本该统一的"品牌蓝",在产品里实际存在着十一种不同的十六进制色值。没有人是故意的,只是在日复一日的快速交付中,这个设计师赶工期顺手调了一点(觉得"这里深一点更好看")、那个工程师临时写死了一个值(懒得去查令牌)、又一个新人不知道有令牌这回事自己取了个色,日积月累,统一性就这么被蚕食殆尽了。这,就是漂移的真实样貌:它不是一次灾难,而是一千次微小的将就累积成的灾难。

对抗漂移,靠的不是一次性的努力,而是持续的治理机制。治理,是设计系统作为"产品"运营的核心内容。它包括几件事。

明确的角色与责任。漂移最常见的根源是"无人负责",没人知道谁该为设计系统的健康负责,于是它就成了没人管的公地,被逐渐荒废(经济学上叫"公地悲剧")。健康的治理,要有明确的角色:谁是设计语言的负责人、谁来管令牌、谁来评审新增的贡献。责任清楚了,系统才有人守护,哪怕是兼职的、轮值的,也比"人人有责等于人人无责"强。

严格的命名规范与贡献流程。令牌和组件的命名要有清晰、一致的规范(比如统一的"类别-用途-状态"命名结构),新增和修改要走明确的评审流程。这里有一个微妙的平衡:既要让贡献足够容易,否则大家会绕过系统自己造轮子,而这本身就是漂移的源头;又要有适当的把关,否则什么都往里塞,系统会迅速膨胀失控,变成一个谁也理不清的大杂烩。这个平衡是治理的艺术。一个常见的失败模式,是评审流程做得太重、太慢:提一个组件要走一周的审批,逼得业务团队为了赶进度而绕过设计系统、自己临时造一个。所以,贡献流程的设计,本身也要遵循第一章的"效率"原则,流程要轻到大家愿意走,又要严到能挡住垃圾。

版本管理与变更日志。设计系统的每一次更新,都该像软件发版一样,有版本号、有变更日志(changelog),清楚地记录改了什么、为什么改、影响是什么、使用方需要做什么适配。这让使用者能跟上系统的演进(而不是某天发现组件突然变了样却不知道为什么),也让整个系统的变化是可追溯、可管理的。

定期审计。定期回头检查:哪些令牌过时了、哪些组件被滥用了、哪些地方偏离了规范、出现了多少本不该有的变体。上面那个"十一种蓝色"的问题,就是靠审计才能发现和纠正。审计是给设计系统做的体检,定期做(比如每季度一次),才能在漂移失控前把它拉回来。审计可以借助工具(扫描代码里硬编码的颜色值、检测未使用令牌的地方),让它不那么费人力。

我想再强调一遍,因为它太容易被忽视:设计系统的长期成败,主要不取决于它建得多漂亮,而取决于它治理得多扎实。当你向老板申请投入做设计系统时,请务必把治理的持续投入也算进去、说清楚,否则,你建的不是基础设施,而是一个迟早要荒废的形象工程。一个没有治理预算的设计系统立项,从一开始就埋下了失败的种子。

8.4 设计与研发协同与设计资产管理

设计系统的价值,最终要在设计和研发的协同中兑现。一套设计系统,如果设计端和研发端是两套各自维护、对不上的东西,它的意义就大打折扣:设计师在设计工具里改了组件,代码里没跟着改,两边越走越远,这又是一种漂移。

理想的状态是,设计系统在设计工具里的组件,和在代码里的组件,是同一套东西的两种表达,共享同一套设计令牌,保持同步。这样,设计师在设计工具里拼的界面,工程师能用对应的代码组件高度还原,设计和实现之间的损耗被降到最低。近年来一些工具能力(比如把设计组件和代码组件做映射、让令牌在设计和代码间同步)正是朝这个方向努力,让设计和代码真正连起来,而不是各画各的。

这种协同的价值是巨大的:它大幅提升了从设计到实现的效率,减少了反复的标注和走查(设计师不用再一个个标"这里间距 16px、这个色值多少",因为用的就是同一套令牌),也从根本上保障了一致性(因为设计和代码用的是同一套源)。但它也对治理提出了更高要求:设计和代码这两端要保持同步,本身就需要前面说的版本管理、变更流程来支撑。设计、代码、令牌三者的同步,是设计系统作为基础设施成熟度的终极体现。

我们也来看看业界标杆,以及它们代表的不同治理路径。Atlassian 的设计系统,用一套语义令牌统一了 Jira、Confluence 等多条产品线,还沉淀了大量复杂的企业级模式(空状态、引导流程、特性开关等这些 ToB 特有的复杂场景),它是"统一庞大产品矩阵"的典范,代表了大型企业内生型的治理路径。Salesforce 的 Lightning,是平台型设计系统,它不只服务自家产品,还要支撑整个生态里第三方开发者在其平台上构建应用,这意味着它的治理要面向一个开放的生态,标准要足够清晰和稳定,代表了"平台型"的治理路径。蚂蚁的 Ant Design,则是开源社区型的代表,它通过开放和社区共建,影响了整个中后台设计的范式,我们前面讲的很多中后台模式(表格、表单、布局),都能在它身上看到,它代表了开源社区型的形态。这三者,分别代表了企业内生、平台生态、开源社区三种不同的设计系统形态和治理路径。理解它们的差异,能帮你为自己的处境选对参照:你是要做一个内部统一用的系统,还是要支撑外部生态,还是要开放共建?路径不同,治理的重心也不同。

设计资产管理,是协同的延伸。一套设计系统会沉淀大量资产:组件、图标、插画、令牌、规范文档、模式库。如何让这些资产被清晰地组织、方便地检索、规范地使用,本身就是一项需要认真对待的工作。资产散落(图标在这个文件、组件在那个库)、文档过期(写的和实际的对不上,比没文档更坑,因为它误导人)、找不到、不知道用哪个(同一个东西有三个版本,该用哪个),这些都是设计系统在日常中失效的常见原因。好的资产管理,让设计系统真正成为团队随手可用、值得信赖的工具,而不是一份没人翻的过期文档。一个判断设计系统健不健康的简单标准:一个新来的设计师,能不能在半小时内找到他需要的组件、并确信那是最新的、该用的那个?

本章要点清单

核心观念:设计系统是要长期运营的"产品",不是一次性交付物。成败七分在运营、三分在设计。
把使用者(设计师、工程师)当用户,有路线图、有贡献模型、有专职角色和持续投入。
设计令牌分层:原始值、语义、(组件)。语义层是关键,它让系统从第一天就支持主题化/多品牌;别偷懒直接用原始值。
治理防"漂移"(一千次将就累积成灾):明确角色责任、轻而严的贡献流程、版本与 changelog、定期审计(可借工具)。立项就要算上治理预算。
设计、代码、令牌三端同步是成熟度终极体现;资产管理标准:新人能否半小时找到最新该用的组件。
三种路径参照:企业内生(Atlassian)、平台生态(Lightning)、开源社区(Ant Design)。

小结

设计系统,是 ToB 设计工业化、规模化的基础设施,是前面几章反复强调的"一致""规范""秩序"的最终归宿。这一章,我们确立了最重要的观念:把设计系统当"产品"运营,而非一次性交付;深入了它的技术核心,设计令牌的语义化分层如何支撑灵活的主题化;并用最大的篇幅讲了最易被忽视的治理,如何通过明确角色、规范流程、版本管理、定期审计来对抗"漂移",让系统长期健康地活下去;最后谈了设计与研发的协同,以及资产管理。

第二篇"建造"到此结束。我们走完了从需求、建模,到信息架构、交互、视觉,再到设计系统的完整科学路径。这是一个 ToB 设计师的核心手艺。从下一章起,我们进入第三篇"进阶",去挑战那些把出色设计师和合格设计师区分开来的高阶能力,从复杂系统的优化,到数据驱动,再到 AI 时代的设计。