Design System 中的 Design Token

在过去的两期周刊中，咱们分别介绍了 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，包含以下几类属性：

1. Background Color
2. Text Color
3. Border Color
4. Font
5. Font Size
6. Opacity
7. Line Height
8. Spacing
9. Radius
10. Sizing
11. Shadow
12. Time
13. Media Query
14. Z-index

这套规则的抽象的主线逻辑是元素中 Style 的属性值加上少量的自有业务定制。这也是最安全的作法，毕竟这已经在 CSS 语法这个领域通过长久的验证，比起你本身组合一套来作的稳定性和拓展性必定会更好。

咱们再找两个例子往深走一步，看看它每一个属性里面是怎么来定义和运做的。

###Radius（圆角半径）与 Shadow（阴影）

一般状况下，不少人会为每一种“卡片”进行完整的样式设定。这种逐个处理的方式一般的结果就是随着业务复杂度的增长会越变越多。

就像下图同样刚开始可能只须要一种卡片（card01），设计师在某个项目中想要作一些风格差别，因而出现了 card0二、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」这本书结构框架的读书笔记和经验总结。但愿将本身的感觉和经验分享给你们，辅助你们的阅读。

点击领取 PinDesign 会员计划 50 元优惠券

Design System 往期回顾：

1. 什么是 Design System
2. 什么是 Design Principles
3. Components 与 Patterns 究竟有什么区别
4. 你该为产品设计怎样的气质