构建和实施设计决策的10个小技巧
在最近的一次代码审查中，当我与团队里的设计师一起浏览一个 Pill 组件的样式时，我的热情被激发了起来。
.pill {
background-color: $background-color-light;
border: $border-hairline;
border-radius: $border-radius;
display: inline-block;
font-size: $font-size-metadata;
margin: $space-inline-left-xs;
padding: $space-inset-xs;
}
.pill--reverse {
background-color: $background-color-dark;
border-color: $background-color-dark;
color: $text-color-light;
}
.pill--ghost {
background-color: transparent;
color: $text-color-light;
}
我几乎无法抑制自己的兴奋：
"快看，是的，这是代码，但仔细看看这些 Tokens。你知道这看起来像什么吗？"像参数！那又怎样？"我可以读懂这些，你也可以。"而且我们可以在任何地方连接这些参数：文档、设计和会话。每一个地方！"
我的队友反应暗示了他的好奇心，即使他的情绪没有像我那样澎湃。他不是像我这样的研究系统理念的极客。至少现在还不是。但他明白了重要的一点：对于我们做出的决策，有一条可见的路径可以到达它们所执行的地方。
我们已经花了很多精力试图把设计从我们的变量中分离出来——那些最底层的可重复使用的代码——我立刻被把设计重新纳入的想法吸引住了。
以下是我们如何在整个设计、代码和协作过程中进行演化、构建和实现 Tokens 的。
从变量到 Tokens
每个设计系统都提供选项。例如，颜色可以从黑色到中性色再到白色。每个中性色——通过 #2B303B 这样的 HEX 代码识别——可以存储并在变量 $color-neutral-20 中提供，以便在 Sass 这样的预处理器中使用。
$color-neutral-20 = #222222;
$color-neutral-90 = #EEEEEE;
$font-size-m = 1rem;
$font-size-s = 0.875rem;
$space-m = 16px;
$space-l = 32px;
变量使晦涩难懂的数值不再神秘。但它们并不能弥合命名和用法之间的鸿沟。它们回答了 "我有什么可以选择？"但却没有明确 "我该做什么选择？"。
当前的选项还是不够好。
设计决策，适用于场景的选项
一个系统的优势来自于知道如何将选项（如 $color-neutral-20 ）应用于场景中（如传统的深色背景色）。这让选项成为决策的基础。
$background-color-dark = $color-neutral-20;
$background-color-light = $color-neutral-90;
$font-size-paragraph = $font-size-m;
$font-size-microcopy = $font-size-s;
$space-inset-default = 16px 16px 16px 16px;
$space-stack-l = 0 0 32px 0;
这些都是我可以放心使用的决策。
然而，这样的决定通常仍然隐藏在一些文件中，这些文件是由他们自己的网络产品的开发人员使用。那么设计师呢？其他的网络产品呢？跨越到其他平台，如 iOS 和 Android ？我们对每个人的决策都进行了编码，但它们存在于回购协议的某个地牢里，其他人无法找到。
设计 Tokens，通过系统传递的决策
Salesforce 用户体验团队提供了一个概念。他们的想法吸引了我，最重要的是他们的 Living Style Guide，它使用开源工具 Theo 将 Design Tokens 应用于各个产品之中。
在这里，选项和决策不会隐藏在 Sass 文件中。相反，它们被集中起来，并作为 Tokens 传递给任何采用该系统的产品、设计师或开发人员，而且是以易于使用、可预测的格式传播。
数以百计的 Tokens 可以成为可读的、刻意的、可追踪的决策，并编织成一个系列产品或企业产品。
把这些决策看作一张规则表？我可以。设计师也可以。有了这样的可见性和工具，他们认识到自己决策的影响。以前，我们决定用 $color-neutral-80 做边框或背景，有点异想天开。现在，我们正在以一种深思熟虑的、传统的方式应用 $border-hairline 或 $background-color-light 。
设计师开始合作。他们在做决策时更加谨慎和自信，将自己的想法组织成一个可共享的结构。开发人员也纷纷效仿。
这样可以将红线标注和像素测量等痛苦的工作转化为富有象征意义的合作。在我们的工作中——批评设计概念、编写验收标准、审查拉取请求—— Tokens 的架构和实现是始终存在的。
构建 Tokens
一个成功的、持久的 Token 架构依赖于简单明了的分组、排序、分类和决策。
#1 先显示选项，然后显示决策
你不能在没有选择的情况下做决定。Tokens 是说明从一个到另一个路径的有效工具。
在我们的 Token 文件中，从可用颜色等选项开始。之后，我们将选项应用于前后场景中，如“文本颜色”和“背景颜色“。
# Choices
color :
white : &color-white "#FFFFFF"
black : &color-black "#262626"
neutral :
20 : &color-neutral-20 "#222222"
90 : &color-neutral-90 "#EEEEEE"
blue:
50: &color-blue-50 "#2196F3"
60: &color-blue-60 "#1E88E5"
# and many more...
# Decisions
interactive-color :
default: *color-blue-50
dark: *color-blue-60
background-color :
default : *color-white
light : *color-neutral-90
dark : *color-neutral-20
disabled: *color-neutral-90
text-color :
default : *color-neutral-25
on-light : *color-neutral-25
on-dark : *color-white
light : *color-neutral-55
disabled : *color-neutral-65
link :
default : *color-blue-50
on-dark : *color-white
要点：组织你的决策，提出它们的原子理论基础：从选择到决策，从简单到复杂。
#2 从颜色和字体开始，但不要止步于此！
我经常谈到设计语言的三大要素：颜色、排版和图标。因此，我们的 Token 文件从颜色和类型选项开始也就就不足为奇了（图标在其他地方都是自动化生成的）。然而，视觉风格是由很多东西组成的， Tokens 也可以如此。
虽然我们从对背景和文本的颜色应用开始，但我们将扩展到许多其他类型的决策，包括以下内容：
color :
interactive-color :
background-color :
text-color :
font :
family :
size :
line-height :
border :
size :
icon :
space :
inset :
stack :
inline :
grid :
layout :
row :
margin :
gutter :
shadow :
block :
text :
size :
transition :
timing :
layers :
responsive :
theme :
product :
age :
motif :
要点：从颜色和类型开始，但不要仅仅停留在颜色和类型上。扩展你的决策，用来涵盖设计语言中各种可能的问题。
#3 在有意义的范围内改变选项
许多 token 化的概念包括可选择的尺度，如T恤衫的尺寸（XS、S、M、L、XL、XXL ），渐进式（如几何 2、4、8、16、32、64 ），或自定义术语（如 compact、cozy 和 comfortable）。尺度也可以从几个选项开始（只有 S 和 M ），然后根据需要再增加。
space :
default : 16px
xxs: 2px
xs: 4px
s: 8px
m: 16px
l: 32px
xl: 64px
inset :
default : 16px 16px 16px 16px
xxs : 2px 2px 2px 2px
xs : 4px 4px 4px 4px
s : 8px 8px 8px 8px
m : 16px 16px 16px 16px
l : 32px 32px 32px 32px
xl : 64px 64px 64px 64px
扩展支持将 Token 层次结构细分为类似但不同的变体，例如将 space-inset（从 XS 到 XL）细化为 space-inset-squish 和 space-inset-stretch 的变体（这两种变体也都提供 XS 到 XL ）。
在缩放模型上达成一致——使用T恤的尺寸格式或是渐进式，由你来决定——对于这样的命名规则，应由团队共同决定。更加困难的是，你需要避免硬性规定，以避免以后在两个缩放等级中再插入一个。
要点：采用和 Token 化缩放模型，并展示它们如何适用于不同的场景。
#4 邀请贡献，但要策划收集
什么时候一个选择才能定义成一个 Token？第一次使用：不，还不够。第二次使用可能缺乏说服力。但第三次呢？如果它出现了很多次，那么它通常是具有象征性的。虽然存在例外情况，但“被使用了三次？”这样的标准是讨论的基础。
那么谁是 Token 的守门员？如果我们采用合理的设计和开发审查流程，就没有人会这样做。任何人都可以提出 Token、在概念中呈现候选人或拉取请求。我们的 Slack 频道也有很多关于 Token 的谈论。
尽管如此，我作为一名 Token 管理员，在工作中寻找可以定义为 Token 的候选对象。我可能会略过一个请求标记，跳过 JavaScript 。然而，我会彻底检查样式和 Token 文件，细化名称，重新分类不合理的名称，并避免名称的过度扩展。但并不是每个人都足够关心或有时间保持 Token 的简洁。
要点：让 Token 成为团队努力的方向，（即使是含蓄地）指定一个结构化的架构思想来管理这些收集到的信息。
#5 从组件到 Tokens 的分级决策
这是一种分散注意力的做法，以转移脑力，不断思考 Tokens、Tokens、Tokens。"这应该是一个新的 Tokes 吗？那是一个 Token 吗 ？我没有使用 Token ？"不！"没有人需要这样的纠结。
然而，我的团队成员 Kevin Powell 有一个很好的习惯，就是在组件样式文件的顶部储存变量。例如，他的表单组件样式中使用的变量的一部分，标识了文本颜色在表单元素中的多种用途，如行内错误、输入、标签和占位符文本。
↑左边是新出现的组件文件，顶部是文件的特定变量，便于与右边的 Token 文件进行比较和考量。
这些特定于组件的变量，为加入到 Token 库的候选对象提供了有用的清单。在这里，我们可以把握机会，用 Form_elements.style 文件中需要刻意禁用的 $background-color-disabled 替换不太特定的禁用颜色 $color-neutral-90 。另一方面，组件的 $border-color-input-hover 不太可能在表单之外重复使用，因此不是一个很好的候选 Token 对象。
要点：鼓励在设计和开发中养成习惯，将可重复使用的决策——Token 的候选对象——放在一个可预测的位置，如文本文件的顶部或设计艺术的角落。
#6 有预见性地应对系统性变化
Tokens 是一个很好的工具，因为你可以从头构建一个原始的系统。但18个月后，当设计决策发生变化时，情况会怎样呢？Token 的变化是如何级联的？风险是什么？如何降低风险？
考虑到 Tokens 的特殊性，它们可以保护你免受不可预测的、更宽泛的变化，因此更应该有节制和有目的地使用它们。
↑搜索一个通用变量。
在此之前，你要梳理和评估一个资源库中的 #2B303B 十六进制代码或 $color-neutral-20 变量，并应用在大量不用的元素中。
↑搜索一个特定决策。
现在，你刻意精确地跟踪 $text-color-microcopy 的使用范围，并降低了风险。是的！
要点：利用 Token 在维护上的优势，将其作为你维系团队的一个亮点。
将 Tokens 落地
大多数团队开始将决策整合成为 SASS 或 Stylus 文件中大量可预测的、分层次的变量名称。但该文件将决策隐藏在一个位置，限制了对该技术的使用。
这使得 Tokens 的预期效果无法实现。在整个系统中传递 Tokens 的第一步是用 JSON 这样的开放格式来释出它们。
#7 通过 JSON 使 Token 数据可复用
JSON 是一个理想的开放标准，用于对分层名称/值对进行编码，以便在不同的工具间重复使用。
有了 JSON 中的 Tokens，你可以根据你的社区需要，为多个预处理器—— SASS、Stylus 和 LESS ——转换决策。这为产品打开了大门，这些产品被限制在一个他们不能或不会留下的预处理器上，即使它不是系统的“推荐”预处理器。
类似地，JSON 为其他平台搭建了桥梁，无论是直接在 iOS 运行中使用，还是为 Android 团队转换成 XML 。
要点：以跨平台可重复使用的格式对 Tokens 进行编码，以每个人都能使用的形式将其公开。
#8 通过 YAML 轻松管理和读取 Token 数据
JSON 功能强大、层次分明且灵活。然而，作为一个管理数据的地方，它并不完美。语法冗长，手动整理时容易出错，缺乏注释支持，并且缺少变量。
YAML ，这是一种更具可读性的语言，用于记录分层属性/值对。YAML 以更易读的格式向 JSON 的分层功能添加变量和注释。YAML 有助于快速向任何受众展示易于阅读的 Tokens，其简单性为设计师提供了一个边界，让他们可以提出新的价值观，甚至自己提交拉取请求。
作为构建过程的一个步骤，我们的团队使用 yamljs 将我们作为单一真相来源，管理的 YAML 数据转换为 JavaScript 对象。
要点：考虑使用 YAML 来增强设计师参与和处理代码的能力，让他们更接近代码以及那些使用代码的人。
#9 用 Token 数据实现文档自动化
如果设计师和开发人员不知道设计决策是什么，以及如何访问它们，那么在代码中嵌入设计决策是没有价值的。这就是为什么我们像使用代码一样使用 Tokens 作为内容。
在我们的系统中，我们将 Tokens 作为数据结构（think:JSON）线程放置到模板中， 用来对 Tokens 进行引用和在其他主题（如空格和主题按钮）中显示决策。
↑文档站点的基本模板，由 Token 数据提供支持。
其他文档更具有定制性，例如包含名称、可访问性评分等的颜色着色堆栈。虽然不是简单的 Token 层次结构循环，但文档仍然可以直接调用 Tokens。
要点：使用 Tokens 来丰富你们的指南内容。
#10 在设计工具中嵌入 Token 数据
Token 数据不仅可以激发研发人员在开发工具上的创意用法，也可以激发设计师在设计工具的创意用法。我们讨论如何使用 Sketch 、Photoshop 或 InDesign 等工具为我们产品的设计师群体构建定制工具。
这类软件提供了各种强大的挂钩（hooks），可以充分利用 JSON 数据。例如，Invision 的 Craft 依赖于以文本形式存储在子文件夹中的 JSON 对象，这意味着可能与我们系统构建过程的输出集成。这种连接在过去是费力和孤立的，以至于它们会被忽略。现在，随着系统的成熟，它们感觉更现实了。
要点：找出机会，将系统扩展到设计师工具中，特别是设计软件。考虑成本——包括设置和维护——相对于系统用户体验的好处。
团队内对 Tokens 的运用越多，我就越觉得讨论设计是一件很自在的事情。用有意义的名称编码的智能决策，使我相信团队的输出正在朝着一个更具凝聚力、可维护性的系统目标迈进。
是要着手一个设计系统，还是需要更深入地讨论产品和参与者？EightShape 举办系统规划研讨会，并就设计系统为客户提供指导。让我们谈谈吧！
