很少有设计系统是专门为一种产品或一种设计语言服务的。我们所做的绝大部分的设计系统都需要高度的灵活性，以便满足客户多样化的需求。其中一些灵活性可以通过组件结构、风格、行为和内容的变化来实现，但高级的审美灵活性往往要通过创建主题设计系统来实现。
究竟什么是主题设计系统呢？本文将探讨设计系统需要适应的各种主题，包括：
-
多品牌
-
子品牌
-
白标
-
季节或活动
-
一种设计语言的多代产品
-
多个平台或产品系列（网络应用程序与营销网站）
-
深色和浅色主题
三层 Token 架构
在对以上场景进行深入研究之前，我先简单介绍一下这个能够支持以上所有场景的主题架构。三层设计 token 架构 可以通过一组设计系统 UI 组件流转一组特定的 token:
下面是对 3 个层级的详细介绍：
-
第 1 级 token 在摘要中定义了主题的设计属性，作为 UI 视觉语言的原材料。
-
第 2 级 token 是一个语义主题层，将第 1 级 token 映射到 UI 内的高级用途。
-
第 3 级 token 是组件特定的，被映射到第 2 级 token。
这种架构在实践中的例子：
这种架构将品牌的外观和感觉控制在远离核心组件库的层级中，这样就可以通过一组共享核心组件流转不同设计语言。
从技术层面上看，我们可以在设计系统资源库中创建一个 design-tokens 目录，或创建一个独立的资源库，用来存储我们的主题设计 token。每个主题的核心理念如下：
多年来，我们使用了许多工具，但大部分情况下，我们用 Style Dictionary 来管理和转换 token。当然，这里我们先不讨论这在静态设计工具中是如何发挥作用的，因为那是另一个领域。
以上是架构概述，现在我们来深入探讨一下这个架构有助于解决哪些场景。
多品牌
我们曾与辉瑞公司、DotDash、Condé Nast 等多家公司合作，创建了能够支持多个品牌的设计语言的设计系统。
每个品牌都是相同的架构：HTML、API、常见的 CSS 样式（比如 display 和定位属性）和 JavaScript 行为，通过这些组件流动不同的美学。
支持多个品牌的设计 token 目录结构通常如下:
设计系统团队公布主题，然后设计系统消费者将把核心 token（所有主题共享的 token）和合适的品牌主题拉到产品中，来达到想要的效果。
子品牌
主题设计系统可以增加额外的层级来支持子品牌，子品牌源自母品牌，但与母品牌有细微差别或覆盖，便于与其他子品牌区分开来。
我们可以在主题设计系统中添加一个额外的子品牌层，以便附加或覆盖 token 值，从而达到想要的效果。可以把子品牌主题放到这堆代码上，如下:
白标
我们曾与一家创建并向银行销售抵押贷款软件的公司合作。尽管抵押贷款软件是第三方软件，但银行希望用户在使用软件时能够感受到银行的品牌文化和设计语言标准，从而增强用户申请和管理抵押贷款的信心。
与子品牌类似，白标体验有核心的品牌体验并附加或重写特定的设计属性（绝大多数是颜色和排版）来达到想要的效果。
white-label-theme 主题可以作为客户特定的配置文件，甚至可以悬浮在内容管理系统（CMS）中，便于客户控制自己的 UI 覆盖（类似于为 Gmail 或 Myspace 进行主题换肤）。
季节或活动
我们曾与许多零售商合作过，他们要求有高度灵活的设计系统，以便适应季节性活动和促销活动。例如，他们团队可能要为情人节建立一个电子商务网站主页，要求有粉红色的行动召唤（CTA）按钮和不同字样的促销标题。只要使用一个架构良好的主题设计系统，就一定能够适应这些临时的、五花八门的设计语言。
季节或活动主题的执行方式与支持子品牌或白标体验的方式相同，有活动特定的主题价值覆盖或扩展核心和品牌价值：
一个设计语言的多代产品
从理论层面上讲，设计系统能在一秒钟内对设计语言进行全面修改，但实际上它是如何运作的呢？答案是：创建一个可以支持传统和未来的设计语言（即 2.0! 3.0! 下一代 ! 再下一代！重塑！改款！未来网站! ……我们都知道！）。
这种做法与支持多个品牌的做法相同，但其目标是能够支持过去，同时以一种全面和系统的方式推出未来。
这个架构可能会非常强大，它让设计系统团队控制如何对公司的数字产品进行美学修改。消费团队可以选择 legacy-theme 来采用设计系统，把对当前用户体验的干扰最小化。随着设计系统组件的就位，设计系统和产品团队可以协调何时切换到 next-generation-theme。团队在采用设计系统时总害怕改变太多、太快，我们发现这个方法可以有效地缓解恐惧感。
产品系列
我经常遇到的一个问题是：我们的软件产品（又称应用程序）和我们的营销产品（又称网站）能否应该共享同一个设计系统？我用自己喜欢的发票/费用/时间跟踪工具 Harvest 来展示营销网站和网络产品之间的分割。Harvest 有一个营销网站，该网站销售产品并提供重要信息。
他们可以提供真实的网络应用体验，我们可以在上面跟踪时间、创建发票、管理产品等等。
根据我的经验，市场和产品之间的鸿沟和我们了解的设计师和开发人员之间的鸿沟一样深。作为设计系统顾问，我看着这个鸿沟现象在我的工作中不断地上演。
数字体验有不同的产品需求、考虑因素和受众（大多数时候），这是绝对事实，因此这两个世界不可能共享同一个设计系统？对吗？也不完全对。
首先，品牌就是品牌，品牌在整个公司的数字生态系统中应该保持一致和连贯性。另外，当你把营销体验和产品体验分解之后，就会发现它们都是由按钮、表单字段、文本、图标等等组成。这些共同的组件是设计系统的素材，因此，创建坚固、灵活、可访问的表单控件，使之能很好地为产品和营销服务，才更有意义。
把这些看似不同的经验之间的差异分解之后，可以归结为几个关键领域:
-
营销网站使用了大量的空白空间，需要较大的尺寸，而产品应用程序的设计要更紧凑和有效
-
营销网站使用的排版与产品网络应用所用的不同且尺寸更大。
-
营销和产品体验使用不同的组件：营销网站使用英雄、兜售、卡片、对比表和报价，产品应用程序使用表格、表单、图表和图形。
这些差异也许能证明完全独立的设计系统是合理的，但我并不这么认为。一些网站使用这些组件，其他网站使用其他组件。一份工作可能不需要同时使用猴子扳手和圆锯，但同时有这两个工具也没什么坏处。至于美学上的差异，我们可以创建不同的主题来适应不同的类型规模、尺寸、以及营销网站和产品应用体验之间的差异。
深色和浅色模式
我在其他地方写过深色模式和倒排（又称淘汰）样式之间的区别 。倒排/淘汰 token 处理特定组件在深色背景上的渲染方式，通常在特定的主题内定义。例如，theme-color-neutral-dark-content 可能会应用默认文本颜色，但 theme-color-neutral-dark-content-inverted 则应用于深色背景上的组件。
一般来说，支持深色模式（指 prefers-color-scheme: dark）可以用多种方式处理。深色模式的 token 可以和浅色模式 token 放在同一个主题中。另外，如果浅色模式和深色模式差别很大，可以把两种模式分别放进各自的主题。
灵活的基础
人们通常认为设计系统是一刀切的解决方案，不能满足个性化的体验。这种观点当然是胡说八道，设计系统可以根据具体需要灵活变化。虽然这篇文章从设计语言的角度讨论了灵活性，但设计系统还有许多其他方面的灵活性（组件变体、支持多种技术堆栈、组合、配方等）。总的来说，设计系统可以提供一个灵活的基础，让不同产品在此基础上进行构建。
原文作者：Brad Frost
原文链接：The Many Faces of Themeable Design Systems | Brad Frost
