在过去的两期周刊中，我们分别介绍了 Components 与 Pattern 的差别，同时也介绍了 Pattern 中非常重要的一个概念 - Perceptual Pattern（气质模式）。
对于整个 Design System ，Components 和 Pattern 除了为产品开发效率、一致性、设计指导提供帮助之外，它还肩负着另一个重要使命：
通过它们来表达我们在 Design System 中创建的设计原则并参与到产品的建设中，从而为产品打造赋有情感的品牌认知。
我们在前面的 Principles 部分曾提到，设计规则创建与执行同样都很重要。从目标达成的角度来说，我们期望参与产品的每一个角色都应该能记住这些原则，结合 Perceptual Pattern “脑补”出这些界面展示在用户面前的样子。这也就需要我们有一套控制性强且拓展的方法来维系产品的风格系统，也就是我们今天将要讨论的 Design Token。
什么是 Design Token
在真实的产品过程中，这个环节在开发过程中是完全断掉的。我们通常看到的 style 代码（如下）都是一些几乎没有体感的参数，难以脑补出它“装饰”出的界面会是一个什么样子。如果产品复杂，时间一久想要全局迭代维护也会是件痛苦的事情。
但如果我们将这些参数封装起来用语义化的方式来进行描述，整个界面的“画面感”就会清晰很多。这些在系统中定义出的”font-size-level03”、”border-distinguish-background” 就是从不同思考逻辑出发定义出的 Design Token。
当然，文字的语义化功能是有限的，也只是 Design Token 最终的一个呈现。想要真正增强“画面感”，让大家能读、能理解还需要我们在 Design System 中建立一整套对应的系统，并让大家对它们有着清晰的记忆。
这里我们将继续以 Salesforce 的 Lightning Design System 为例，来给大家进行 Design Token 的详细分析。
Lightning Design System 的 Design Token
Token 原本的意思是令牌，在工程逻辑中用于用户身份与服务器端进行验证操作。而在 Design System 的领域中，Design Token 的定义更像是设计变量。对设计变量名称的合理定义可以让属性参数更容易理解，也更便于对产品风格的控制。
Salesforce 在文档中也对他们的定义作出了一段解释，简单来说就是：
Design Token 是设计系统中的视觉设计原子。它们是一组有着统一命名规则的实体，用于存储视觉设计部分的具体参数，比如 HEX 色值、间距、尺寸的像素等。使用它可以有帮助为 UI 开发工作维护一套具备可扩展性、一致性的视觉体系。
举个例子，在背景色部分 Lightning 定义了（节选） notification、badge hover、error dark 等 token，并在建立样式体系的过程中为其定义了具体的色值。于是在开发的过程中，大家所看到的将是更为语义化的描述。
如果需要调整产品的整体风格，只要这套体系的搭建足够的健壮，整个实施过程将变得更加的高效且安全。
Lightning 定义了一整套 Token，包含如下几类属性：
- Background Color
- Text Color
- Border Color
- Font
- Font Size
- Opacity
- Line Height
- Spacing
- Radius
- Sizing
- Shadow
- Time
- Media Query
- Z-index
这套规则的抽象的主线逻辑是元素中 Style 的属性值加上少许的自有业务定制。这也是最安全的做法，毕竟这已经在 CSS 语法这个领域经过长久的验证，比起你自己组合一套来做的稳定性和拓展性一定会更好。
我们再找两个例子往深走一步，看看它每个属性里面是怎么来定义和运作的。
###Radius（圆角半径）与 Shadow（阴影）
通常情况下，很多人会为每一种“卡片”进行完整的样式设定。这种逐个处理的方式通常的结果就是随着业务复杂度的增加会越变越多。
就像下图一样刚开始可能只需要一种卡片（card01），设计师在某个项目中想要做一些风格差异，于是出现了 card02、03。
接着随着卡片在更多场景下的使用，右侧这些不同尺寸、不同圆角的 card 就出现了。到最后没人能够搞清楚究竟有多少圆角矩形，也没人知道究竟该如何使用。
via: www.lightningdesignsystem.com/design-toke…
阴影部分也一样，Lightning 为不同的业务场景定义了好多不同种状态。比如 focus 在按钮上的阴影、拖拽时阴影的变化、图片的阴影。
via:www.lightningdesignsystem.com/design-toke…
看到这里大家可能会发现一个问题，Lightning 的层级定义方式似乎与我们常见的方式不同。我们经常看到的是类似下方（Carbon）这样由小到大一级级递增上来的。
而 Lightning 则是更多根据场景来进行定义，也就是我们前面看到的表格圆角、卡片圆角、按钮圆角等。不过我相信它们也肯定是有按照层级定义的一套 guide，只不过是“藏”了起来。
对于 Salesforce 生态中的开发者们来说，他们更需要的是更直接的指导，确定某个场景下的组件具体的样子。Lightning 这么做也正是因为由于它们业务的自身特性而决定的，所以这里我还是想再提一下。
我们所看到的每一个 System 思路和工作方式可能都不一样，因为它的主要目的是更有效的服务与业务。所以我们可以借鉴的思考方式，但无法全部照搬。
###Design Token 的作用仅此而已？
答案显然是否定的。PinDesign 早期在关于移动端设计方面给大家提出过一个「跨多终端设计统一」的概念，而 Design Token 在跨多端设计统一中则有着非常大的价值。
绝大多数的产品，我们可能都至少要考虑在 Web、iOS、Android 上的设计，每当要增加或更新功能的时候设计上多会有多倍的时间消耗。
但如果从一个系统的角度来考虑这显然不是一件科学的事情。如果接下来产品要拓展到更多的端，设计的资源消耗则会更多，而且可控性也会越来越差。
这个时候我们就需要再次请出 Design Token 了。在跨多端的设计中它不仅仅是一个存储样式的变量，更是一套用于在各操作系统间进行“翻译”的“口令”。
如果我们将产品当做一个“人”来看待，那么 Design Token 则可以用来进行不同语言的翻译。同样都是 shadow，我们可以根据不同语言（系统）的要求去设定好翻译过的内容（具体参数）。
只要产品的设计框架足够健壮，我们在不同系统中所消耗的设计资源将会大幅降低，开发的效率和一致性也能得到更好的保障。更重要的是，设计师可以将更多的精力放在对产品的逻辑、流程设计上，而这也是设计师真正该做的事情。
以上是 Design System 系列的第五期的节选内容，在余下的全文内容中（付费部分）我将重点关注动手部分，和大家聊聊如何为自己的产品创建 Design Token，以及在创建的过程中的重点关注。
加入 PinDesign 会员，获取本期主题「Design System 中的 Design Token」的全文内容及本系列前三期周刊的赠送。
Design System 是 PinDesign 周刊的一个新系列，基于「Design Systems」这本书结构框架的读书笔记和经验总结。希望将自己的感受和经验分享给大家，辅助大家的阅读。
Design System 往期回顾：