一文读懂DesignToken：提升前端开发效率的关键工具

一文读懂DesignToken：提升前端开发效率的关键工具

DesignToken是近年来在B端设计领域高频出现的重要概念，主要用于设计规范的交付和前端协作。本文将从基础概念出发，深入解析DesignToken的工作原理、应用场景及其在项目中的具体实践方法，帮助B端设计师掌握这一重要工具。

DesignToken是什么？

了解DesignToken首先要了解Token的概念。在开发领域，Token通常被翻译为“令牌”，是程序之间进行数据验证和通信的相关编码的统称。例如，用户登录应用时，服务器会返回一个令牌，用于后续的身份验证。

虽然“令牌”这个翻译在开发场景中很合适，但直接将DesignToken称为“设计令牌”并不准确。更合适的翻译是“样式标签”，原因将在下文解释。

DesignToken的工作原理

在HTML+CSS的基础知识中，要为一个元素设置样式，需要为其添加相应的CSS属性和值。例如，要将一级标题设置为品牌红，就需要添加如下CSS代码：

h1 { color : red }

如果链接文本也需要使用相同的颜色，就需要添加相同的属性和值：

a { color : red }

这种做法的问题在于，当需要修改品牌色时，开发人员需要手动查找并修改所有使用该颜色的属性值，效率低下且容易出错。

而DesignToken的作用就是在样式和目标元素之间添加一层“标签”，用于统一管理。例如，可以为品牌色定义一个Token，命名为BrandColor，后续所有使用品牌色的属性只需要添加这个Token即可，而不需要填写具体的色彩数值：

h1 { Color: var( BrandColor ); }

通过定义一个语义化的标签，可以让不同设计元素被引用，不仅提高了代码的可读性和编写效率，还使得后续的批量修改变得更容易。只要修改这个Token的色值，就可以批量修改所有关联了这个标签的元素的颜色。

这个逻辑对于有UI设计经验的人来说很容易理解，它类似于在UI设计软件中定义样式。通过定义一个样式并命名，后续就可以批量调用和修改这个样式，这就是DesignToken的实际应用案例之一。

DesignToken的复杂应用

DesignToken并不仅仅是一个简单的样式名或标签，它还可以实现更复杂的操作与应用。以主色为例，虽然规范中定义的主色只有一个，但在实际应用中可能会产生各种变体。例如，一个填充主色的按钮，除了默认状态，还包括悬停、点击、禁用等不同状态，它们都需要通过颜色来区分，因此需要设置多个主色变体。

同理，这些多出来的颜色，也需要为它们设置对应的Token命名。除了主色外，其他辅助用色也有同样的使用需求，且颜色的使用场景不一定只是状态切换，因此命名往往是在色彩后加数字的方式，例如Arco的主色和成功色命名案例：

但是，即使有了这些基础的Token，开发的复杂性仍然存在。同一个色彩可以应用到多种对象上，比如一个辅助色既可以用在文字，也能用在按钮，还能用在日历、选择器、复选框中。当多个颜色，且每个颜色应用到的对象是数十种时，前端实现设计稿的过程就会变得非常复杂。

为了解决这个问题，可以对Token进行“套娃”式的定义。即针对色彩更具体的应用场景进行定义，创建更细分更有可读性的Token进行命名，然后关联基础的色彩Token为它们赋值。例如：

Login-Button-Bg: var ( BrandColor-1 );
Form-Input-Border:var ( BrandColor-1 );

有了这样的联系，修改了BrandColor的颜色，关联它的更下级的Token，自然也会被修改。

DesignToken的全面应用

如果DesignToken只定义颜色，那不管怎么套娃都改变不了它鸡肋的命运。真正让DesignToken发挥价值的地方，在于它还可以定义其他设计属性。包括尺寸、字体、透明度、圆角、投影、模糊、动效等要素，即我们在设计规范中定义的大多数样式内容。

通过这些DesignToken的定义和应用，前端在开发过程中可以大幅度提升效率，提高页面还原度和最终交付质量。

如何制定DesignToken

了解了DesignToken是什么，接下来就要了解项目中应该如何制定DesignToken，我们先从独立设计和开发的项目说起。

DesignToken是设计规范的延续，需要先完成B端设计规范，也就是在项目流程的规范定义和后续页面设计之间展开。因为DesignToken必然会影响设计软件内样式定义的规则，所以越早确定越好。

DesignToken可以覆盖规范中的大多数样式，所以首先要根据规范中整理的样式做分类，例如：

• 色彩
• 字体
• 尺寸
• 圆角
• 阴影
• 动效

每个项目的规范内容都有差异，所以除了色彩和字体外还包含什么内容是无法固定的，下面是不同设计规范制定的DesignToken类目：

然后我们就要定义DesignToken的基本命名标准，因为DesignToken本身是可以套娃的，所以每一层的命名形式都要做出区分，我们把Token简单划分成两个层：

1. 基础样式层
2. 组件应用层

基础样式层就是上面提到的分类，它的命名形式可以用"分类-场景-状态"这个模式来定义，而Token毕竟是代码，所以只能用英文，不用考虑大小写，用横线来进行内容的分段。应用的案例如下：

• 基础颜色Token：
• 品牌默认主色：color-brand-default
• 品牌主色悬浮：color-brand-hover
• 错误颜色禁用：color-error-disabled
• 文字字号Token：
• 一级标题字号：fontsize-head-big
• 一般正文字号：fontsize-text-default
• 醒目价格字号：fontsize-price-big
• 阴影等级Token：
• 较低的阴影：shadow-low
• 较高的阴影：shadow-high

这个命名的方法不是完全固定的，需要在团队内部协商，尤其是需要让相关前端开发人员检查。除了命名的格式外，还包括一些英文用词的统一。

接着需要创建出对应的表格，来记录所有Token的明细，表格的属性包括Token名、中文名、值、应用场景等，比如下面的色彩Token案例：

完成基础样式层的定义以后，就可以进行组件应用层的Token制定。但这一步，就不是由设计师来主导，而是让前端工程师自己定了。基础样式层的Token，在设计软件中就是样式的命名，对设计过程有直接的影响，但是组件应用层，则完全作用于前端开发的使用场景，对设计师而言是毫无必要的。所以项目如果还需要定这一层，就要由前端工程师自己判断使用的需要，制作一个新的Token列表出来。

而在组件应用层的Token，则会使用新的命名规则，网上常见的做法就是类别+元素+属性+等级+状态，比如下面这个普及度最广的案例：

光命名还不够，同样需要使用表格的方式进行记录，而它和基础样式中唯一不同点，就是数值是基础样式的Token名而不是实际属性值。比如下面案例：

相信你们立马就能感觉出来这个命名实在是太复杂了，不是单词写的越多、越生僻效果就越好，而是没有必要的情况下有经验的前端是绝对不会使用这么复杂的命名，不仅编写起来麻烦，而且可读性也极差，只会反向降低自己的效率。

所以任何成熟项目的DesignToken命名，都是尽可能精简命名的段数和单词长度，提高利用率。只要明白这个道理即可，而不用盯着前端或自作主张做出看起来非常专业但实则臃肿鸡肋的命名文档。

具体可以参考成熟的案例，如SEMI、TDesign的Toekn命名规则：

• https://semi.design/zh-CN/basic/tokens
• https://github.com/Tencent/tdesign-common/blob/develop/style/web/theme/_light.less

掌握以上的认识，制定项目基础规范的DesignToken就没有问题了。但是，上一篇分享中提到的深色模式，就是在基础规范之上制定一套额外的深色规范，同样要被考虑进去。

而DesignToken实现深色模式的切换有两种做法，一种是在Token命名中增加模式的前缀，比如Arco在深色模式添加了Dark的前缀用于区分。

还有一种做法，就是命名没有任何变化，只是创建一个新的样式表，替换里面的颜色，比如在Semi Design中的浅色和深色模式命名没有区别，只是HTML会调用Light或者Dark。

无论使用哪一种，都要记住在基础规范中定义的所有Token，在深色模式下都要罗列出来，即使它们已经合并成相同的颜色，这样才便于维护。

不管DesignToken这个概念看起来多高效还是先进，都一定要充分结合实际情况展开实践，再总结相关的经验做优化。并且并不建议设计师投入太多的时间到这个部分的工作中去，因为常规项目的迭代很快，我们很难预知项目半年以后会长什么样子，所以DesignToken的应用要把持灵活、高效、简洁的核心价值观。

下面是Arco和Semi的Token命名文档案例，给大家作为参考：

总结

DesignToken是B端设计中非常重要且实用的概念，它通过统一管理和命名设计属性，显著提升了前端开发的效率和设计还原度。对于B端设计师来说，掌握DesignToken的原理和应用方法，是提升工作效率和项目质量的关键。