描述视觉风格的术语、类型和分类方法
自 2014 年 Salesforce 率先提出这一概念以来，Design Tokens 为许多设计系统提供了视觉基础。2016 年，我写了一篇关于 Design Tokens 的慷慨激昂的文章，在这个话题上，我的能量将持续迸发。随着视觉风格系统在不断扩大的组件、平台和输出领域进行传播， Design Tokens ——以及它们的命名——已经变得越来越重要。
有效的 Token 名称通过设计、代码和其他跨学科的交接，来提高和维护团队对视觉风格的共同理解。措辞很重要。当我们做产品时，我们必须能够浏览和查询工具，用来快速识别和回忆我们所做的有目的性的决策。不仅仅是在代码和文档中，在设计工具中也是如此。
↑跨代码（左）、文档（中）和设计工具样式（右）的 Design Tokens 。命名并不完美：你能找出不一致的地方吗？
而且命名也很复杂。对一个团队来说，构建 Token 模式是一项模式化的、偶尔充满激情的工作。我曾参与了 Discovery Education、Morningstar、REI、USAC、NetApp 和其他 10 个系统的 Tokens 架构设计，每一次经历都是独一无二且具有启发性的。其他公开的对 Token 的运用也给了我们很多灵感：Adobe、Shopify （目前的，早期的）、Infor、Bloomberg、Sprout、Orbit 和 USDS 等。
↑Salesforce 用户体验团队使用的 Token 层级结构（Ferrua & Rewis, Clarity 2019）
随着 Tokens 变得越来越复杂，命名规则也越来越重要。Salesforce 用户体验团队的 Brandon Ferrua 和 Stephanie Rewis（在 Clarity 2019 上）和 Shopify 用户体验团队的 Kaelig Deloumeau-Prigent（在 Design Systems Community Chapter Toronto，2020年9月）公布了他们的模型。Adobe Spectrum 和 Danny Bank 的 Style Dictionary Token 工具也记录了他们的模型。
从基础开始
即使是简单的 Design Tokens 也会通过层级结构展示命名规则。
例如，$esds-color-neutral-42 这样的 Token 结合了四个层级——名称空间（在这个例子中，esds 代表“EightShapes Design System”）、类别、变体和级别，映射到 #6B6B6B。类似地，$esds-space-1-x 则对应名称空间、类别和级别的等级，来表示将 16px 作为另一个泛型值。
↑复杂的 Tokens 由许多层级组成：命名空间、类别、概念、属性、变体和缩放比例。
除了泛型，我们还需要更多的等级来实现 Tokens 的功能：作为一种集中记录和广泛复用的有目的性的视觉决策方式。较为复杂的 $esds-color-feedback-background-error 和 $esds-font-heading-size-1 特指数值（分别为 #B90000 和 64px ）。级别越高的 Tokens 就越复杂，但也越具体，例如 $esds-marquee-space-inset-2-x-media-query-s 合并了一个组件名称，还包括两个类别/比例配对组合。
为了描述得更充分，一种结合了分类法和类型学的 Token 化的语言需要很多层级来进行表达。事实证明，有足够的层级将他们组织成组：
- 基础层级作为 Token 的主干，结合了类别（例如
color）、概念（action）和属性（size）。 - 修改器层级指的是一个或多个变量（
primary）、状态（hover）、比例（100）和模式（on-dark）。 - 对象层级指的是一个组件（
button）、组件内的元素（left-icon）或组件集合（forms）。 - 名称空间结合了任何（或全部，在极端情况下！）系统（
esds）、主题（ocean或相关子品牌），或相关领域（retail）。
↑来自 Bloomberg、Salesforce、Orbit、Morningstar、Infor 和 Adobe 的表示主要操作的悬停样式的 Tokens。
不同的系统适用不同的层级。上图描绘的来自六个不同品牌的 Tokens，符合我对其 Token 意义的猜测，表示主要操作的悬停样式颜色。我知道，我知道，我尽力了，但每次都可能找不到合适的 Token。快讯：这是 Tokens 使用者所面临的问题。尽管如此，该图片仍展示了跨系统间不同的深度、特殊性、顺序和目的性。并且，模式是显而易见的。
本文详细介绍了如何使用基于修改器、对象和名称空间扩展而来的、稳固的基础规则，来为设计系统中的 Token 进行命名。在这一过程中，完整性、秩序感和多层级等原则和论题，加深了团队对于在 Token 内容增长所面临的挑战的理解。
基础层级
类别和属性为大多数 Token 名称提供了一个基点。随着组合的增长，单一类别的层级被证明是不够的，因为 Token 的子集会被作为概念组织起来。
类别
Tokens 存在于一个原型类别中，如 color、font 或 space。
↑常见的类别与相关的变体术语
类别涉及视觉风格，有时可能会重叠。除了典型的颜色 color，不同的系统以不同的方式命名类别。常见的类别包括：
colorfont（又名type、typography、text）space（又名units、dimension、spacing）size（又名sizing）elevation（又名z-index、layer、layering）breakpoints（又名media-query、responsive）shadow（又名depth）touchtime（又名animation、duration）
如上所示，示例以“首选术语”（如 font）开头，然后是“又名”，突出显示其他系统出于相同目的使用的“变体术语”（如 type 和 typography）。当团队总结出一个基于规则限制的术语词汇表时，这些相关的术语可以用于激发灵感。
原则：避免一词多义词语的出现。
即使是最高层级的类别也会让选择变得困难。type 是一词多义词语，可以被解释为多种含义，比如“排版”或“类型”之意。后者对于变量名来说很麻烦！类似地，有些人用 text 来代替 typography ，然而 text 也是内容的同义词，同时也是一种属性（后面会详细介绍）。由于 typography 字符太长，团队最终往往会选择 font 来替代。
属性
一个类别可以与一个相关的属性配对来定义一个 Token ，尽管这对组合不足以定义一个有目的、有意义的值。
↑类别/属性配对组合
相关的颜色 color 属性包括 text、 background、border 和 fill，从而导致缺少前后语境的基础 Tokens，如：
$color-background: #FFFFFF
$color-text: #000000
$color-border: #88888
常见的排版属性包括 size、weight、line-height 和 letter-spacing ，由此产生的 Tokens 有：
$font-weight: normal
$font-size: 14px
$font-line-height: 1.25
类别/属性这样的配对组合，是非常笼统且没有目的性的。我们需要的是概念和修改器。
概念
可以通过添加一个或多个概念对每个类别的 Tokens 进行分组。
例如，颜色 color 可以被归类为这样的概念：
feedback（又名notification、messaging、alert），包括success、warning和error等变体。action（又名cta、interactive、interaction）将提供行为召唤（如链接、按钮等）和选定项（如标签、导航项、复选框、单选按钮和筛选）的颜色关联起来。visualization（又称为dataviz、charting、charts）。金融机构 Morningstar Design System 甚至在visualization中包含了correlation、valuation、performance和asset-allocation颜色的子级概念，以及默认的可视化颜色顺序order名称。commerce的颜色包含sale、clearance、inventory和timing的变体。
概念与变体相结合，形成了 $color-feedback-success、$color-action-primary 和 $color visualization-performance-positive等 Tokens 的名称。
类似地，排版类型的 Tokens 通常被归类为 heading（又名 header、heading-levels、headline、display）和 body（又名 text ——又是一词多义的词语！）等概念。
特殊情况下，如引题中的 eyebrow 名称或 lead（又名 lede、deck、subheader、subhead），与标题 heading（1、2、3、…）和主体 body（s、m、l）概念不同。这样的命名复杂程度暗示着，为了获得有足够目的性的名称，还需要怎样的变体和规模层级。
原则：内部的同质性，之间的异质性。
在各个层面，尤其是概念层面，要力图实现类别内（如 visualization）的同质性和类别间的异质性（如 visualization 相对于 commerce）。为了保持较低的概念数量，可以将 sale 和 clearance 纳入 visualization。然而，visualization 是针对图表的，而 sale 和 clearance 是电商流程中的具有色彩的对象。考虑到不同的含义，应把它们划分为不同的概念。
修改器
Tokens 通过修改变量、状态、级别和模式级别来体现目的性。修改器可以单独使用，也可以协同使用，与类别、概念和属性等层次相结合，形成一种广泛而有目的性的决策风格类型。
变体
一个变体可以区分不同的用例。例如，设计语言通过改变文本颜色来创建层次结构和对比度，如下所示：
primary（又名default、base）secondary（又名subdued、subtle）tertiary（又名nonessential）
同样地，界面上的反馈（ feedback ）颜色也不同，以提醒用户注意：
success（又名confirmation、positive）error（又名danger、alert、critical）information（又名info）warningnew
像 $color-text-primary 、$color-background-warning 和 $color-fil-new 这样的 Tokens 将类别/属性配对组合与变量结合起来。
原则：灵活性还是特殊性？
像 $color-success 这样的 Tokens 结合了类别（color）和变体（success），作为一个适用于多种情况的解析性标识符。将解释留给用户，以便将 $color-success 应用于任何 background、border 或 text。
灵活性是以牺牲特殊性为代价的，而且——推而广之——可能会牺牲应用的精确性。一个反馈成功（success）的颜色可能只用于文字（text）或背景（background），但不能同时使用。更重要的是，反馈成功（success）的对象可能需要不同的文本（text）、背景（background）和边框样式（border）。在这种情况下，在 Token 中包含属性级别会导致更具体但使用起来不太灵活的 $color-background-success 或 $color-text-success。
状态
Tokens 可以指定基于交互状态的属性，比如：
defaulthover，当指针位于一个物体的上方的时候press/active，在用户按下和释放对象之间的时间间隔focus，当一个对象能够接受输入时disabled，当一个对象不能接受输入时visited，用于在已访问的情况下显示替代链接error，当一个对象处于错误状态时
状态通常与一个对象（button）或类别（color）、概念（action）和属性（text）元组相关联，与一个变体（secondary）相关联。这会产生一个完全成形的 Token，比如 $color-action-text secondary-focus。
级别
Tokens 的级别可以选择不同大小、间隔和其他选项应用于元素之间。常见的级别类型包括：
- 枚举值如标题级别“
1、2、3、4和5”。 - 排序值如谷歌 Material 设计语言的颜色级别为
50、100、…、900。 - 边界值比例，如 HSL 的 0 到 100 亮度值，用于改变色调的深浅，例如 slate gray 的
slate-42、slate-90和slate-95。 - 比例，通常以
1-x为基数，相对增加（2-x，4-x，…）和缩减（half-x，quarter-x，…）。 - T 恤尺寸，从小号
small（变体：s）、medium（变体：m、标准、基本、默认）和large（变体：l）开始，扩展到xl、xs和xxxl。专业提示：尺寸≠间隔，所以考虑用比例而不是 T 恤尺寸来表达间隔，尽管我四年前提到过。
级别既体现在一般性的象征上，也体现在目的性的象征上。例如，大多数系统都定义了通用的（又名，原始的）间隔类型的 Tokens，如 $esds-space-2-x 表示 32px ，颜色如 $esds-color-neutral-42 表示 #6B6B6B ，这些都是对空间和颜色的有目的性的应用。在这种情况下，2-x 和 42 分别位于比例和亮度级别上。
有目的性的 Token 在类别（font）、概念（heading）和属性（size）的范围内为 $esds-font-size-heading-level-1 和 $esds-font-size-body-small 这样的 Token 指定了一个级别（level-1）。
不太常见的情况是，特定性要求将概念/规模配对组合链接到一个 Token 中。例如，响应式排版系统可以将标题（heading）作为枚举级别 level （1，2，3，…）与媒体查询（media-query）断点作为 T 恤尺寸（m，l，…）相结合，用于存储像 45px 这样的尺寸决策。
模式（通常用于“亮色”和“暗色”）
Tokens 可以使用模式修改器来区分两个或多个表面/背景设置中出现的元素的值。这可以实现不同的亮色（light）暗色（dark）模式，表现系统也可以扩展到其他的品牌颜色（brand-color）模式（对于 EightShapes，那就是橙色主题，我们的许多组件都应用在其之上）。
例如，你可能需要 $color-action-background-secondary-hover-on-light 和 $color-action-background-secondary-hover-on-dark 这两个Tokens 来区分垂直导航、垂直筛选器和水平标签中项目的悬停背景色。
这增加了 Tokens 的数量，但实际上仅限于较小的子集，并且通过为更简单的值（想象一下，$color-accent-hover-on-dark）进行别名处理来降低复杂性，这些值可在许多可预测的用途中重复使用。
原则：显式默认值与截断默认值
使用模式的 Tokens 可以假定默认背景（通常为“亮色”或“暗色”），并仅在“暗色”备选方案中添加“暗色（on-dark）”修改器。这样就避免了在许多与“暗色”（on-dark）无关的 Tokens 上添加“亮色”（on-light）。
另一方面，一些系统依靠跨同级 Tokens 的并行构建来可预测地迭代一个集合，这样一来，对亮色（on-light）、对暗色（on-dark）和对品牌（on-brand）的名称修改都将是预期和必要的。
原则：包括还是排除修饰性术语？
通过在“暗色”或“亮色”等标签前面加上“on”（on-）等词，让 Tokens 读起来更清晰。然而，暗色模式（on-dark）通常会需要更多的视觉空间，需要用户花费更多的注意力来输入信息。这样的选择在很大程度上倾向于个人喜好。当然，我更喜欢依据亮色模式（on-light）的可读性来推断一个 Token。然而，我的 Cap Score 看法（查看 Cap Watkin 的 "滑动量表"）是对于“惯例是什么”的理解还不够深，但却坚定地认为“惯例是存在的”。
对象
Tokens 承诺在组件目录中重复使用有目的性的决策。然而，有时 Tokens 只能在几个组件中重复使用，或者——哇！——只能在一个组件中重复使用。对象级别对特定于组件、嵌套在组件中的元素或组件集合的 Tokens 进行分类。这通常是在处理像表单这样的组件集合时产生的。
例如，一个输入组件使用许多现有的 Tokens，如 $esds-color-text-primary 来为文本值添加颜色。另一方面，Tokens 集合可能与输入的边框颜色和圆角半径值无关。像 $esds-color-neutral-70 这样的通用 Tokens 和像 4px 这样的明确值就足够了，对吗？
在一个组件内
边框颜色可能与其他地方有关，但还不能确定。在这种情况下，我们要在某个地方记录这个组件特有的 Token（$esds-input-color-bound）。但是在哪里呢？
全局 Token 并不是开始的地方。相反，将其记录在该组件的特定位置，如 input 的设计参数或 input.scss 文件的标题。这些位置便于使用常规名称记录决策，并在处理其他组件时参考过去的决策。
嵌套元素
即使是像 input 这样的原子级组件，最终也会有像图标和链接这样的嵌套元素，这些元素也是复用样式的相关候选元素。
特定于嵌套元素的 Tokens 可能包括组件名和元素名，这与 BEM CSS 方法 非常相似。特定于元素的 Tokens 也可以出现在本地使用场景中，比如 spec 或 input.scss，例如 $esds-input-left-icon color-fill、$esds-input-left-icon-size 和 $esds-input-inline-link-color-text。
组件集合
像表单 forms（又称 ui-controls 或 form-controls）这样的组件集合与一个组件的本地 Tokens 有关，也与其他相关的组件有关，它们共同构成了一个有意义的集合。例如，Select、Checkbox 和 Radio Button 也可以使用 $esds-color-neutral-70 作为边框。
由于该决策与许多组件有关（我的经验法则是三个或更多），所以现在是时候了：
- 将
$esds-forms-color-border添加到全局 Tokens。 - 将
$esds-input-color-border替换为$esds-forms-color-border。 - 从
input.scss中删除$esds-input-color-border。 - 将
$esds-form-color-border应用于 Select、Checkbox 和 Radio。
原则：从内部开始，然后跨组件推广。
识别候选 Token 并将 Token 理念从内部推广到全局的初期发展实践是逐步添加 Tokens 的合理方式。
原则：不要过早地将决策全局化。
对一致的表单元素边框的共同需求是可以预见的。这些元素是一起设计的，这些约定很快就会出现。
其他情况则不那么明确。想象一下，在工具提示上工作，弹窗和菜单可能稍后会出现。系统可能会重复使用阴影和圆角提示框，但也不能保证这一点。在这种情况下，将特定的工具提示 Tokens 保留在该组件的本地中，并在以后的弹窗或菜单工作开始时引用它们。这可以避免令人恼火的主观争论（“这些是有缺口 notched-layers 的图层！”）过早地扰乱了全局名称空间。
名称空间
在一个名称空间中工作的小团队，只有有限的合作者，不需要担心名称空间的级别。然而，考虑到 Tokens 的存在是为了在许多范围和平台上传递样式，将名称空间作为系统、主题或领域的范围变量的前缀可能是必不可少的。
系统名称
许多系统使用以下方法预先设置名称空间的级别：
- 系统名称，例如
comet-或orbit-。简短的系统名称，例如 5 个字符或更少，通常效果会更好。否则，退而求其次。 - 系统首字母缩写的长名称，如
slds-（用于 Salesforce Lightning Design System）或mds-（用于 Morningstar Design System）。
因此，命名为 esds 的通用 Tokens 在开发者看来是 $esds-color-text-primary 和 $esds-font-family-serif，与一个团队创建的变量不同，并且易于追踪。
主题
系统通常会提供一个主题，在组件目录中改变颜色、排版和其他样式。例如，像万豪这样的组织可能会称为“JW 万豪”、“文艺复兴”、“W”、“庭院”或其他酒店类型的主题。主题的主要目的是传递视觉决策，这些决策经常扩展并覆盖现有 Tokens。对于万豪庭院酒店来说，这可能是在按钮、复选框和选中的标签高亮显示等组件上流动的一种品牌色（#a66914）。
在主题架构中命名和流动的 Tokens 约定是一个相当复杂的话题，超出了本篇文章的范围。不同的团队以不同的、通常非常复杂的方式设置工具、编译和命名结构。然而，这里提出了几个 "关于主题化的主题"，以阐明主题级别的目的。
例如，假设一个动画应用程序（由例如 $aads "动画应用设计系统"支持）可以提供诸如 ocean、sands、mountain、和 sunset 等颜色主题。每个主题可能需要在一般和特定场景中改变类似但不同的设计 Tokens。
// 通用 Tokens，可以将主题颜色别名到多个场景。
$aads-ocean-color-primary
$aads-sands-color-primary
$aads-sunset-color-secondary
//特定 Token 的覆盖和扩展
$aads-ocean-color-heading-text-1
$aads-sands-color-heading-text-1
$aads-mountain-color-alert-background-success
记录 Token 决策的一种方法是将主题（ocean）附加到一个系统名称空间（如 aads）中，从而得到一个更短的名称空间 $aads-ocean。该名称空间为系统作者提供了一个映射于特定主题的值的位置，这些值覆盖并偶尔会扩展默认标记值。例如，在为 ocean 主题编译视觉决策时，以下映射可能是相关的：
$aads-color-text-primary
= $aads-ocean-color-primary;
$aads-color-forms-text-metadata
= $aads-ocean-color-primary;
$aads-color-background-secondary-on-dark
= $aads-ocean-color-primary;
原则：主题≠模式。
一个主题最终可能需要亮色（on-light）、暗色（on-dark）的色彩应用。万豪庭院（courtyard）的组件很可能需要亮色和暗色模式，就像万豪文艺复兴（renaissance）组件所需要的一样。因此，在使用这两个概念的系统中，主题与色彩模式是正交的。
域
虽然我还没有在实践中观察到这一点，但我预计系统将扩展到支持设计系统层面的 Tokens 生态系统。域（又名业务单元）级别为组提供名称空间，以便在系统核心的 Tokens 集之外，自行创建、隔离和分发一组 Tokens 。
例如，构建了选取框、卡片磁贴系统和其他促销组件的消费者（consumer）组可能会产生大量新的 Tokens。这可能会导致在消费者（consumer）名称空间中产生 Tokens，如下所示：
$esds-consumer-color-marquee-text-primary
$esds-consumer-color-promo-clearance
$esds-consumer-font-family-marquee
$esds-consumer-space-tiles-inset-2-x
这些局部决策可能需要在多个主题（各种消费者 consumer 产品系列）或色彩模式（消费者 consumer 的亮色模式 light 和 暗色模式 dark）中应用。
每个组织都是不同的，所以没有传统的名称作为开头。一家银行可能分为信用卡 credit-card 、银行 bank 和贷款 loan 等领域，而另一家银行则分为销售 sales 和服务 servicing 小组。一个互联网企业可能将消费者 consumer 与企业 business 进行对比。团队可能想要区分公共 public、合作伙伴 partner 和内部 internal 应用。从外部看，我可以想象像 Shopify Retail 这样的小组受益于“零售 retail ” Tokens ，扩展他们从核心 Polaris 团队得到的东西，其中一些 Tokens 可能对其他团队有用，甚至推广到核心团队。
汲取的经验教训
无论在哪个层面，完整性、顺序和多层次性的话题都会在命名 Tokens 的讨论中反复出现。
完整性
没有一个单一的 Token 能涵盖所有可能的级别。一些级别——领域、主题、元素——很少需要。其他层面——定量尺度与定性变量——往往是相互排斥的。避免教条式地包含所有可能的级别或重复的 Token 图元。相反，只包括充分描述和区分有目的意图所需的级别。
// 正确的
$esds-shape-tile-corner-radius
$esds-shape-tile-shadow-offset
//错误的、冗余的
$esds-shape-tile-corner-radius-default-on-light
$esds-shape-tile-corner-radius-default-on-dark
$esds-shape-tile-shadow-offset-default-on-light
$esds-shape-tile-shadow-offset-default-on-dark
顺序
正如在我的项目和其他公开展示的 Tokens 的用法所证明的那样，没有通用的 Tokens 的级别顺序。因此，以下是我认为的较为稳定的一些模式：
- 基础层级（类别、属性、概念）是中间层的骨架。
- 基础中的级别根据层次结构的严谨程度（
color-interactive-background）、可读性（interactive-background-color）或保持类别和属性等级别的配对（color-background-interactive）而有所不同。 - 名称空间（系统、主题、域）是先加前缀的。
- 修改器（变体、状态、比例、模式）往往最后才被附加。
- 对象层级（组件组、组件和嵌套元素）从属于名称空间，并建立可以包含基础级别和修改器级别的场景。
- 修改器中的顺序并不一致，尽管模式通常是最后一个（考虑到它的框架是“打开”状态，并且使用仅限于颜色，即使这样，也只有在有区别时才使用）。
虽然这里给出的级别顺序不是唯一的选项。系统的级别顺序取决于你使用的级别、系统需要的内容以及每个团队成员的不同诉求。
多层次结构
概念、类别、变体和其他层次可以重叠和更替。例如，一个 "红色错误 "既可以是概念变体 color-feedback-error，也可以是 ui-controls-color-text-error 的对象变体（包含在 Input、Checkbox、Select 和其他表单控件的包中）。这迫使我们做出决定：
我应该把这个有目的的决定储存在哪个层面？
将同一个决定储存在两个不同的位置可以吗？
如果两个不同选择的目的几乎相同，应该是 1 个还是 2 个 Tokens？
color-feedback 和 ui-controls-color-text 这两个概念都有其他的变体（分别是 warning、success、info 和 label、value 和 helper-text），对于它们来说，error 完成了一个集合。即使实际的红色值是一样的，我也很重视这两个集合的完整性。因此，我会考虑将一个（对象变体）别名到另一个（概念变体）。
$ui-controls-color-text-error = $color-feedback-error
(= $color-red-36)
(= #B90000)
这还避免了这样一种可能性，即 ui-controls-color-text-error 红色稍后可能被调整，而不会影响 color-feedback-error 的其他使用，从而仅跟踪符合该目的的那些值的变化。
考虑这么多可能的 Token 层级可能会让人望而却步（就像一篇这么长的文章一样）。当你下次查看 Tokens 时，会被这样一个观念所鼓舞：当你在为团队创造 Token 词汇表用于分享和成长时，你有一系列的选项可供选择。为 Tokens 命名而快乐！
