如何通过Design tokens，快速进行设计决策？

不知大家是否在工作中，会因为遇到以下场景而感到烦恼？

设计师：“👀大佬，帮我把APP的按钮颜色，统一换成紫色呗？”

开发同学：“😒换不了”

设计师：“当初不是让你做成“组件”了，改个色值这么简单的事情怎么就做不到？😤”

由于品牌升级等一些因素，设计师想通过替换当前品牌色，已满足诉求。但是开发同学却不能快速的实现你心中所想，只能通过逐一查找，将带有此色值的地方寻找出来，单独修改。

出现这样的情况，是因为开发同学太懒不想写成“组件”？还是因为他们对此根本不知道从何下手？

我们可以先思考下，在搭建项目的组件库时，我们首先是否需要对色彩先进行制定，而后在对每个颜色进行语义化命名并转换为可供不同文档调用的一套色彩库。

其实对于开发也是一样的道理，需要通过对每个颜色进行语义化命名，单独生成一套可供调用的色彩库。那么我们应该如何让开发去做出这样的一个库呢？（老实看下去，会告诉你的）首先我们需要先了解下Design tokens。

关于Design tokens的由来

在互联网的快速发展的时代，许多公司的设计团队都构建了属于自己的设计体系，虽然设计体系能够保证项目中开发代码与设计稿保持一致，但在产品不断迭代升级的过程中，即使是一个简单的设计决策（例如颜色变化）也需要开发耗费数周的时间才能修改完成。

为了解决这个问题，在2014年由Salesforce的设计团队，建立了一个新的概念，可帮助实现跨多平台并解决设计扩展性等问题。他们把它命名为Design tokens，其中token是令牌、标记、象征的意思。通过使用Design tokens，可跨平台快速实施设计决策，仅需要几分钟，而不是耗费数周的时间去进行修改。（简单来说：用了Design tokens，改个颜色就是分分钟的事情了！）

怎么使用Design tokens？

Design tokens是与平台无关的变量，它们构成了设计系统的基础组成部分，可用于定义颜色，文本样式，间距及其他属性类型。他们为主题和设计过程的视觉组件化提供了基础。

我可以进一步将Design tokens定义为储存视觉属性的命名实体，且与平台无关；

• 存储视觉属性：例如：颜色、文本样式、间距、行高和动画时间等。

• 命名实体：由名称与属性值组成token。

• 平台无关：token是平台特定变量之上的抽象层。它们为独立于实现框架的设计属性创建了通用语言。

通俗来说，通过将视觉属性进行实体命名后，以特定的文件格式（通常是JSON或XML）保存。这些文件被用作为输入型文件，经过处理与转换，将生成不同格式及输出方式，供其他项目和代码库使用；

我们举个栗子🌰

首先设计师需要先将此前为开发提供使用的十六进制颜色编码，通过使用token对每个颜色编码进行专属的命名。

例如：

$color_fill_main = #FF8A00

token名称为：$clolor_fill_main，其值为： #FF8A00

其他颜色如下，将对于的色值通过语义化命名，建立起颜色专属的token。

 

假设：

当公司内需要对品牌进行升级，希望将全局的品牌色调修改为紫色。那么我如何通过Design tokens快速实现此决策呢？

首先我们需先将Design tokens列表中所对应的品牌色的实体命名找出，并修改其对应的色值属性。

如：将「$color_fill_main」所对应的色值修改为 「#8E97FD」，只要引用了「$color_fill_main」地方都会更改，即可满足上述要求。

*通过修改视觉属性，但实体命名不做修改，对开发整体代码是毫无影响的，开发仅需重新发布token即可；

Token的其他用法

此外，Design tokens还可以通过引用另一个token，这些token通常称之为Alias token。

通过Alias token可以创建出更多的选择与层次结构，并控制更改的范围及用途。

当设计师想将按钮上的字体修改为白色，并移除按钮边框，以满足新的设计风格，可以将字体所带的实体命名中的变量进行修改「$color_text_title = $color_fill_black」，修改为「$color_text_title = $color_fill_white」，字体发生变化。

在将边框所对应的实体命名变量进行修改「$color_button_stroke = $color_fill_black」，修改为「$color_button_stroke = $color_fill_no」（对应的属性值为空）。

即为下图所展示样式

开发同学应该如何实现？

以设计师视角了解Design tokens的基础原理和运用，那么开发同学应该将上述内容进行整合落地？

当我们在完成对色彩库中的颜色、字体等token的定义后，可形成一个独立的文档，交付开发同学。让开发同学根据文档token与属性，构建起供开发同学可调用的色彩库。

但是由于不同的平台，平台之间都有自己要求的数据格式。

比如：

• 在Wbe上，使用的是以.CSS文件格式设置的RGB值；

• 在iOS中，使用的是以.JSON文件格式设置RGBA值；

• Android，则使用的是8位十六进制（AARRGGBB）值格式化为的.XML文件；

那么随着时间推移和积累，如何能保证每次的多平台之间的同步工作不会出现错误及遗漏？

按照现有流程应该是如何的？

1.设计师在设计工具中新增色彩并更新；

2.将新增的色彩属性及文档分别同步给不同平台的开发同学；

3.开发同学建立或修改对应token的值；

4.设计师对不同平台环境进行结果验收；

当如果其中某平台出现纰漏，需要通过重新校对数据，重新进行修改。而且维护这些对设计师与开发都存在比较高的人力成本且耗时；

所以Salesforce设计团队，开发了Theo，并且代码在GitHub上开源。通过使用Theo文件完成了对Design tokens在应对不同平台的调用中，快速的帮助这些原始值进行格式转换，以满足任何平台的需求。

Theo可以使每个平台的统一使用同一个Design tokens文件，而不必以每种平台/格式对这些信息进行硬编码。（GitHub文件：https://github.com/salesforce-ux/theo）

详细了解及使用Theo教程，可以参考官方文档（记得墙）

地址：https://medium.com/salesforce-ux/living-design-system-3ab1f2280ef7

📝让我们来总结一哈：

1.Design tokens是与平台无关的变量，它们构成了设计系统的基础组成部分，可用于定义颜色，文本样式，间距及其他属性类型

2.通过修改视觉属性，但实体命名不做修改，对开发整体代码是毫无影响的，开发仅需重新发布token即可；

3.通过Alias token可以创建出更多的选择与层次结构，并控制更改的范围及用途。

4.Design tokens简化了设计师与开发之间的协作流程，并确保整个目标平台中的品牌一致；

5.Theo可以使每个平台的统一使用同一个Design tokens文件，而不必以每种平台/格式对这些信息进行硬编码；

6.可以基于Design tokens快速帮助设计师与开发的配置深色模式主题；

以上为个人观点及理解，欢迎大家一起沟通交流👏