设计从来不是一成不变的东西。优秀的设计师往往都明白一个道理：想要通过一劳永逸的设计创造一个伟大产品是不现实的。设计存在的终极目的是解决问题，市场在不断的变化，那么设计也会随之不断的适应和更迭，所以怎样保证产品团队能快速高效的完成更迭才是重中之重。一般而言，产品研发团队会依靠统一的设计系统（Design System）去实现更快速的产品设计和构建流程，而“Design Tokens”就是现代设计系统的中基本的组成部分。
Design Tokens翻译过来可以叫做“设计指令”或者“设计变量”，是一种设计师和开发之间一种表达设计决策的通用语言，它可以确保构建的产品在不同平台和设备上都与设计稿一致，确保设计稿被高效、准确地还原。
本篇文章，我们会全面的介绍和了解什么是Design Tokens，它的重要性，以及如何利用它为你的产品建立一套高效完整的设计系统！
什么是Design Tokens？
Design Tokens 是一种定义产品属性的代码语言。通常会用来指代一些反复在不同的设计稿，代码，工具和平台中使用的某种设计属性，如颜色、排版和间距等。它可以取代硬编码常量，快速高效的实现所有产品设计和体验的一致和统一！
举个例子，比如你在一个产品中使用蓝色作为主色，这个蓝色色值是＃508BFF。那么你可以将该色值通过硬编码的方式添加到设计元素中，将其用作常量。但这样做其实效率极低，因为每次想要更改颜色时，您需要手动去调整所有使用此色值的每个实例的代码。要是遇到在大规模项目中，这样繁琐而巨大的工作量可能会直接让你崩溃，而且还容易因为遗漏修改部分代码导致设计上不一致。但如果使用Design Tokens就能实现高效快速的修改，首先你需要为颜色代码＃508BFF定义一个Token值。这个值在设计和开发过程都会被使用，如果需要更换一个其他色值的颜色，开发只需重新输入每一个 Token 对应的新色值，就可以做到产品全局的自动颜色更换！
Design Token的概念最初是由salesforce(一家硅谷的saas企业,2021年收购了slack)的lightning design system团队在14年提出并在团队内部落地的，它的初衷是帮助确保 Salesforce 产品的设计一致性，自那以后，设计令牌变得越来越普遍，时至今日国内国外的很多互联网大厂都已经在自己的项目中使用，包括adobe、Google、腾讯，Mockplus 等设计团队。
Design Tokens是如何被应用的?
其实Design Tokens已经被广泛应用到了像Mockplus RP这样的设计工具中。首先我们已经知道Design Tokens是定义产品设计属性的变量，如果我们能将它的原理直接应用和整合到设计系统的组件库上，那它就能成为产研团队使用的设计系统中重要的组成部分，从而在产品设计和开发过程中帮助设计师，开发实现快速修改和信息同步，当设计师使用Mockplus RP产出原型和线框的时候，实际上他们已经在使用Design Tokens了。比如，我们把一个色#508BFF定义为“blue-200”的Token，设计和开发过程中当需要使用这个颜色的时候都使用“blue-200”的这Token，这样就能保证在产品的不同的地方，以及在不同产品开发进程中都使用的是同一个颜色，当Design Tokens被修改过后，在设计中所有对应Token的实例都会自动同步修改。
Design Tokens有哪些种类？
一般而言Design Tokens的值可以指代颜色、字体、间距等。
根据使用目的，主要可以分为以下几个类别：
颜色Tokens：用于定义产品中使用的颜色值，包括设计中使用的主要颜色、次要颜色和其他颜色。
字体Tokens：用于定义产品的字体相关的属性，包括字重和字号等。
间距Tokens：用于定义设计中元素之间的间距，包括外边距和内边距。
视图高度Tokens：用于定义产品中元素之间的景深。
动效Tokens：用于定义动画效果，包括动画时长和缓动曲线。
图标Tokens：用于定义产品中使用的图标的样式，包括大小、颜色和形状。
品牌Tokens：用于定义品牌的视觉元素，包括品牌Logo、品牌字体、品牌颜色调色板和其他品牌相关属性。
Design Tokens的优势是什么呢？
我们可以将Design Tokens当成构建设计系统的一块关键拼图。它提供了一种将设计元素的属性标准化的方式，确保它们在设计和开发中，不同平台和设备上都能保持一致。它的主要优势有几点：
共享的设计语言：Tokens为设计师和开发人员提供了一个共同的设计语言，使他们更容易的协作和理解彼此的决策。
一致性：可以帮设计师和开发人员共同创建视觉和体验上的一致和统一。
易维护性：便于团队高效快速做批量修改，当一个Token被修改时，该变更会自动应用到产品中所有该Token的实例上。
资源高效复用：Tokens是可以直接在多个产品和设计中快速复用的，从而减少重复工作。
什么时候用Design Tokens？
一般而言，在以下三种情况是最适合使用Deisign Tokens去提高效率的：
计划构建一个新产品或重新设计现有产品的时。
产品需要适配多个平台时。
产品设计经常更改，希望维护更方便的时候。
但是如果您在设计中都是使用硬编码的方式，又或者产品设计在接下来的几年中不会有太大变化，那Deisgn Tokens可能不太适合你，也不会对你有多大的帮助。
使用Design Tokens一般有哪些步骤？
总结下来大概有以下几个步骤：
整理出界面元素清单
当你需要新建Design Tokens时，首先需要将你的产品和设计组件进行拆解到很微小的元素，比如按钮和输入框这样的很小的界面组成部分，此外你还需要整理出他们的对应的视觉风格。当做完这一系列的清单整理，你就能对构成整个产品界面的所有元素和风格有一个清晰的认识。
定义您的设计系统
当您完成界面清单整理后，下一步就可以着手定义产品的元素了（例如菜单、CTA按钮等这样的功能性元素）并定义它们的视觉属性。包括它们的颜色、字体、间距、动画和其他设计属性。
这里需要注意，不要一股脑的把设计中所有颜色、字体或间距都定义为Tokens。你需要有一套明确的标准：具体什么样的元素和属性才需要被定义为Tokens。把那些只会在设计中使用一次的颜色或字体转定义为Token并没有多大意义。一个过来人的经验是可以把使用次数作为标准去判断该元素是否需要被定义为Token。比如，如果样式被使用了10次，那就需要被定义为Tokens了。
此外还有一个建议是：最好有一个管理Token的负责人，负责检查和审核设计系统进行更新的需求。所有团队成员提出的新的Token需求需要他统一把控，避免不必要的Tokens添加到设计系统。
创建Tokens
接下来就可以开始创建添加Tokens了。Token的命名方式建议最好能清晰的记录每个Token的相关信息，比如Token名称、值、用例，以及创建它目的的以及如何使用的介绍，以及团队成员需要了解的关于这个Token的其他信息，这样能可以让你团队中的每个人都能清晰的了解如何使用它们。
设计师经常会犯的一个错误就是给Tokens的命名太过随意。一个好的Token命名应该直观的告诉其他团队成员它的预期使用场景或方式。比如，如果你将一个CTA按钮的颜色Token命名为“mysuperblueelement-400”，对于第一次看到这个名称的人来说，它并没有传达太多有用信息。但是如果你将它命名为“cta-primary-background-blue-400”，它就清楚地说明这个Token用于主要CTA按钮上，作为一个背景颜色。这里建议命名方式可以参考这样的形式：[分类] - [类型] - [属性]，分类对应一个元素的类别（如按钮、输入框等），类型是指定元素的具体类型（如主按钮、次级按钮等），属性就是该元素的颜色和其他的一些视觉属性。
将Design Tokens应用到你的设计中
你可以使用Mockplus DS中创建Tokens，快速复用完成产品原型和线框的构建。这里就会涉及到选择不同的格式了，虽然可以使用许多不同的格式，但建议最好用JSON格式，因为该格式可以存储项目-值对（item-value pairs），并且可以根据开发人员的需求轻松做出优化调整。
在代码中实现 Design Tokens
接下来就是在代码中实现Design Tokens了。Design Tokens应该集中存储在一个地方，方便开发人员导入他们的代码库中。导入之后，非常重要的一步是将硬编码的值替换为Design Tokens，接下来还需要二次确认代码中每个设计元素使用的是正确的Token。
为了方便查找和使用，最好是把不同类别的Tokens用不同的文件或子目录进行管理，比如可以将颜色Tokens分组到名为“colors.scss”的文件中。
同一元素的Design Tokens保持全局使用
产品中同样的元素不应存在一部分是Token化的，而另一部分不是，因为这种情况很容易导致设计上的视觉不一致。始终一致地在整个产品中使用Design Tokens， 后期修改上也会方便很多。
结论
Design Tokens是团队在构建产品时用于设计决策的通用语言。用它来代替硬编码可以确保构建的产品在不同平台和设备上都与设计稿保持一致，让产品设计更迭和修改过程也更加高效流畅。如今，Design Tokens 已经成为了设计师和开发之间的单一事实来源（a single source of truth），真正意义上的帮助设计和开发实现设计的一致性！
网友评论