背景

在项目的迭代升级中，面对设计趋势变化或者产品风格变化，需要对视觉进行调整。而在这过程中会遇到很多问题

1.设计、开发要修改某个样式的话，就会牵涉很多相同地方。需要重复修改；

2.修改一次之后，如果再修改还要花费同样的时间精力。可维护性差；

3.修改样式的过程中，总会有遗漏的部分；

4.设计师对样式的理解不同，导致同一场景下，使用了不同的样式。破坏了一致性；

5.设计稿还原的实际效果较差

这消耗了设计师和前端开发大量的时间。而这些问题用Design Token就能较好得解决

什么是Design Token

Design token是对设计样式，开发UI实现的管理工具。它构建和维护设计系统里所有的“值”，包括 spacing, color, typography,animation等。开发和设计用同一种语言对样式描述，双方的协作会更加方便

全局token

全局token是设计语言中的原始值，与背景无关，抽象度很高，常常被其他token继承使用。颜色、动效、间距、阴影、圆角等都可用于全局token。举一个例子，颜色的全局token：$red-1、$green-2

语义token

语义token更加具体化，有助于传达token的预期用途。比如$color-text-primary：$blue-7，它的意思是“主要文字的颜色”，而不是图标、背景、线框的颜色。

组件token

组件token比语义更加具体化了，把使用范围局限在组件中。更加有助于传达token的预期用途。比如$size-image-s：$size-3

为什么选择Design Token

已有的样式功能，比如sketch和figma的样式可以在很大程度上减少样式的修改。但是有多层次的Design Token能更细致地控制，从而减少修改的内容。

如下图，如果要修改“次要文字”的颜色 。方案一的情况下，需要把所有的涉及到次要的文字的地方逐一修改。而方案二只需要修改“color-text-secondary”一个地方

注意：现有的设计软件，如Figma、Sketch、即时设计、MasterGo软件自带的功能中都不支持多层次的Design Token。现在仅在Figma的插件中可以实现多层次的Design Token。

Design Token的优势

语义化：Design Token在名称就表示了它的使用场景。如下图所示，原始数值#26801b对于大部分设计和开发来说都想不出这是一个什么颜色。具体化为Blue-400时，就能知道这是一个颜色不深也不浅的。进一步具体化为color-primary-default，就能知道这是这个平台的主色。再进一步具体化为color-button-bg-default时，就知道这是按钮的背景颜色

可维护：把位于不同地方的同一个颜色，用一个Design Token管理。如果不复杂设计软件自带的样式功能也可符合使用需求

一致性：样式的用法使用文档记录下来，帮助设计师正确使用规范，减少人为的使用偏差。比如下图中描述了“危险颜色”、“警告颜色”、“圆角”的使用方法，设计师甚至前端开发可以查阅

Design Token如何解决问题

经过分析，发现核心问题在于四点“可维护性差”、“遗漏内容”、“样式使用错误”、“还原效果差”。通过Design token就可以很好解决这些问题。

解决方式：

1.Design Token能关联所有相同的地方，修改一个地方就可以修改所有相同的地方

2.Design Token关联好的地方，就不会出现遗漏了

3.对Design Token思考后，给出相对准确的样式使用规范，形成文档就可以减少这种情况发生

4.开发输入Design token时，会进行“联想”，这些都是已经设计预设好的值。所以出错概率更小

5.Design Token以样式作为核心考虑的内容，促使设计对所有样式审查，减少遗漏

Design Token命名

Token的类别

参考Semi Design、Ant Design、TDdesign、Deui、Gestalt、Corbon Design，最后提炼出Color、Spacing、Radius、Border Width、Shadow、Typography、Sizing这几个优先确定的类别

抽象的角度

抽象的缺点在于不同的人，甚至一个人也会对同一个东西产生多角度的看法。这种情况发生了，会让Design Token应用不方便。所以要约定大家认同的抽象方式，参考其他设计系统的使用方式。

如下图所示message/success组件中的背景，有两个方向进行抽象化，一个是从具体的元素——背景；另一个是从含义角度上抽象——成功。这里参考了较多的token规范，采取「含义」大于「对象」的方式。也就是使用“成功”

抽象的程度

上面我们提到了Design Token有三种：全局token、语义token、组件token。那么在应用的过程中，如何到底使用哪种token呢？

抽象到哪个程度取决于使用token的时候，是否方便。如果一个类别下全局token只有一个，那就没有意义具体到语意token，组件token。下图中要给image配对应的size，但是size一共有6种，且某些数值相近，不好分辨。实际上image的size token只有4种，使用组件token后，能快速判断设计稿使用了那个token。这样方便了Design Token的使用。

总结：当同级别、同类别Token较多的时候，使用更具体的token。因为如果不使用更具体的token，选择就会出现困难 。遵守上述方便使用的核心准则。size、typography、spacing、Chart组件的color都会从全局token具体到语义token或组件token使用。

如下图所示，如果一个系统内border width只有一个值，那么再具体到组件border width-input也不会方便选择。所以不要过度具象

命名结构

从Semi Design、Ant Design、TDdesign、Deui、Gestalt、Corbon Design和下图看，Design Token命名的结构并没有非常统一的认识。这就是上面所提到的人和人之间对事物抽象方式不同，导致难以形成统一意见的结果

最终决定参照国内命名最完备的Semi Design。组件token中元素顺序为，类别-组件-属性-状态（大小）

命名规则总结

1.size、typography、spacing和Chart组件的color token可以具体到组件token；

2.当抽象要从「含义」和「对象」选择时，优先选择「含义」，例如Success、Warning；

3.从全局token、语义token到组件token，每一次都是因为上一层token数量过多，导致使用困难。而细化使用范围的方式。若抽象的token就方便使用，不要具体化；

4.单词时间用“.”分隔，数字越小表示尺寸越小；

5.组件token中元素顺序为，类别-组件-属性-状态

形成文档

文档在Figma中完成，根据全局token、语义token、组件token划分为三块大内容。设计师与开发都可以在这里查阅这个基准文档。

结语

Design Token 作为较新的工具还没被普及开来，但已有很多大公司使用。并且在自己项目实践的过程中，极大提高了公司设计和研发团队的协作效率升。如果项目比较复杂，非常推荐使用