最近在工作项目中完成了一次对产品视觉的统一升级，但是在整个过程中，我们发现，虽然组件库的搭建很完整，但是组件库的搭建并不是所有设计同学共同完成的，而是由1-2名设计师主导制作，再加上设计团队内新老成员交替，设计侧对规范执行并不严格，经常会出现不知道应该使用哪个色值、某些场景的按钮应该遵循哪个规范的情况。这些问题相信大家在日常工作中或者新入职的时候都遇到过。
再加上需要同时支持公司不同的业务线，新业务也在不断拓展，也导致了下游开发同学的代码组件碎片化，在接到相似的需求时无法复用，需要二次开发，极大的影响了迭代效率，同时维护的成本也无限增高，而且在最近的一次迭代中，我们对产品的品牌色进行了一次升级，在完成升级的2个月之后，仍然能看到某些页面的颜色没有更新，仅仅是更新了一个品牌色，可能对开发来说都是一个巨大的工作量。
更何况需要适配暗色模式这种全局的更新，所以我们急需要一个可协作的、统一的设计规范。和技术侧同学反复评审之后，我们决定使用design token来规范产品的视觉层面，也从代码层面保证了每次的迭代质量，提高测试同学的走查效率，也方便了多业务之间设计到代码的可复用能力保证了各个项目的高效运转。
什么是design tokentoken直译过来就是令牌或者象征性的符号，在技术的逻辑中是用于用户身份与服务器进行验证，design token就是将设计系统中的颜色、布局、样式甚至动画等基础元素进行抽象化，总结成一套可识别的代码系统，从而保证产品在多端的样式一致性，而且在开发过程中，基于design token拓展的设计系统，可以把一切复用性比较高的组件提前开发，极大的提高了产研效率。
总的来说，design token就像是一辆汽车的车牌号，通过车牌号可以在特定的平台追溯到汽车是什么品牌、颜色、功率等等的所有信息，而我们将产品中的组件转化为一串串字符代号，将例如“#000000”转化为dark-primary，就像是在为组件库定制牌照一样，方便设计师和开发精确的定位到元素的信息，这样既避免了在设计和开发时的个人失误影响元素的视觉样式，也提高来设计稿-开发的协作效率。
design token的起源design token的概念最初是由salesforce（一家硅谷的saas企业，2021年收购了slack）的lightning design system团队在14年提出并在团队内部落地的，到现在为止，国内国外的互联网大厂都已经在自己的项目中实际使用，其中包括adobe、Google、figma、腾讯等设计团队。
现阶段基本每个互联网公司的设计团队都维护者自己的一套产品组件库，对于规模更大的团队，还有很多团队将设计组件库与技术团队的代码组件库打通，开发同学也能在接到需求时快速搭建基础产品；组件库的出现虽然提高了团队的整体效率，但是实际面临的情况可能更为复杂，像开头提到的问题，新同学对组件库的了解不深入，加之与组件库配套的相关文档不完善或者太过冗长，长时间累积下来整个组件库就会失去本身的价值；
再比如一些需求中，设计师看来，某个按钮的描边应该是3dp，而实际开发落地中可能写成了4dp或5dp，而单凭测试同学或设计同学验收可能无法发现这些细节问题，就算设计同学真·像素眼发现了这些瑕疵并反馈到开发，也会有“就这么1dp的差别，谁能看得出来”之类的理由搪塞，而新同学遇到这些问题也不好意思摆明自己的态度，久而久之也会导致整个组件库的价值失衡。
而design token的优势在于对设计师来说，无论是新同学还是老同学，design token通过字符串来直接对颜色或其它元素注明用途，避免了组件库的由于描述不清晰，难以理解，最后导致各个设计师之间的产出不一致
对于开发同学来说，直接调用token进行开发，既提升了产出效率，也提高了设计还原度，在代码层面，也变得更加容易拓展，方便维护
下面就带大家回顾一下我们在项目中是怎么把design token实际运用到产品中的。
提出升级目标在以往的每次组件库升级中，设计团队的积极性总是很高，大家都致力于维护一个精美的产品组件库，最终设计团队完成搭建之后，满心期待的向业务方提出体验与视觉优化的需求，但是每次都会以“业务目标优先，优化型需求优先级暂时向后排“或者开发资源紧张等理由搁置，造成了每次的版本迭代设计侧需求只能见缝插针提出，并不能进行一次完整的、系统性的升级。
和开发同学沟通也是一个相当困难的工作，虽然整体升级后，无论是设计侧还是技术侧都会大大降低重复的工作量，提高协作效率，但是由于我们产品已经走过了将近十年的时间，代码中沉淀了很多复杂的逻辑，开发同学事实上对我们的这次升级积极性并不高......
这一次我们设计团队以提高设计与研发效率为出发点（否则又会被以各种千奇百怪但又无法反驳的理由打回......)，提出建立design token的需求，在和业务方亲密协商 后，终于妥协，在保证业务需求不被影响的前提下进行升级。
需求评审大闯关以往的需求评审和技术评审， 设计师都是以参与者的角色，大部分时间都是对需求中交互上的逻辑、视觉上如何表现等提出问题，但这次的需求评审，需要我们设计侧完全进行主导，如何高效地跟技术、产品同学表述清楚需求的目的和具体的实施细节，成了我们面对的最大问题。
明确评审传达的内容
首先我们从需求需要同步的信息内容出发，划分了三个维度：这次需求的价值、需要技术侧支持落地的功能和具体的实现方式
对产品同学来说，我们这次提出的需求并没有一个可量化的预期收益，对业务的核心数据可能也起不到立竿见影的效果。对技术同学来说，升级的意愿和积极性也不是太高，所以，我们必须抓住上下游的痛点，明确这次升级的价值。在产品同学方面，我们从需求的迭代效率提升和产品的体验一致性切入；在开发方面，我们从上下游协作效率、代码可复用性、研发效率提升的角度进行阐述，将整个需求在效率和协作方面预估一个可量化的具体数据，建立各方同学对本次需求的价值认同。
对团队中的其他人来说，之前的需求都是由产品经理提出，所以对设计师提出的需求，除了感觉很新鲜之外，天然的会有不信任感，产品会怀疑需求是不是设计团队凭空捏造出的需求，没有出发点，技术同学会怀疑设计师提出的需求有没有提前进行调研
为了解决上下游对设计团队提出的需求不信任问题，我们从技术可行性方面，调研了目前各个大厂在项目中使用design token具体的落地方法和落地效果，表明在需求评审前，设计团队已经做了非常多的准备工作，并不是单纯的拍脑门提需求。
这次的需求无论是设计团队还是技术团队，都是一个大体量的项目，环节之间的拉通仅通过一次评审是没办法完成的，在需求内容上，我们按照基础元素、基础组件、业务组件的思路简单的与技术同学沟通了这次的需求内容和需要技术支持的具体方式；在经历了四轮以上的技术评审后，终于将方案细化到可执行的地步。
方案全景我们设计团队首先对组件库中的基础元素进行穷举、将元素分类为：基础控件、业务组件、基本布局三个大类。
但是众所周知，产品经理的脑洞千奇百怪，会设计很多试错型的需求，使我们在接手后，不得不面临一些特殊的场景页面，那这些页面的元素和组件究竟要不要加入我们的design token中呢？
针对这个问题，我们初期定制了一个比较笼统的、完全凭借设计师个人主观感受的规则：判断特殊场景的可复用性，如果复用性比较高的话，我们就进行一次设计团队组内评审，讨论是否将其加入token，当然现在来看，这个规则完全可以进一步细化，比如可以从特殊场景的组件与通用组件的符合程度、组件复用率、可拓展性等多个方面判断组件是否有必要加入主组件库
第一步制作组件的工作相信大家在日常工作中也会频繁接触，组件完成后，我们从基础元素开始，对所有内容进行语意化的命名，简单解释就是指定某个元素的使用场景和状态（后文细述）并且根据命名的规则，将元素的token字符串一一输入到Excel形成表格，
整个excel完成后，交付开发，并将组件库落地为文档，使用文档化的说明描述组件的表现方式，组件的使用场景与方法，降低开发的转换门槛，开发将Excel转换为编译器可识别的json文件，并对比文档进行修正，最终做到与设计组件库-代码组件库一一对应。
在工作中是怎么落地的初期建立专项小组
在确保正常对业务需求支持的背景下，我们和技术团队的几名同学成立了一个专项小组，升级专项启动后，初期主要由设计团队执行。但是很快我们就发现，如果完全按照需求文档的思路来进行，将所有的元素拆分出来，并制作语意化token，这似乎是一个在短期内不可能完成的任务，而且日常工作中还要保证对业务需求的支持，一个历经了十年的产品，无论是页面数量和其中的逻辑复杂程度都是难以想象的。然而这些现实的问题如果不想办法解决，整个项目都无法推进。
转换思路，追求最小可验证模型
为了避免出师未捷身先死，我们迅速转变了思路，既然无法脱离业务的双周迭代的需求节奏，在设计团队内沟通后，决定初期不从大而全的token制作出发，而是跟随需求场景，逐步迭代，定期复盘统计改造完成的页面。保证了业务项目如期推进的同时，我们的design token覆盖度也能不断上升。
建立design token体系基础
由于人手紧张的原因，我们没有办法一下子建立一个完整的design token体系，为了验证最小可行性模型（MVP），我们先用基础的颜色、按钮的样式等等一些基础的控件和规范定义了一套小型的token。
命名规范
按照DTCG的说明文档，token的命名不应该描述具体的色值和控件外观等，而是要实际的指明颜色或某个控件的使用方法，比如button- error，代表是一个警告按钮，没有描述button的具体外观和色值，只是抽象成一串字符，便于进行代码化。同时也在也在字符串的各级别上给出了清晰的参考，比如：
第一类
作为整个token字符串的第一类别，也是token的基础骨干，一般建议将其定义为整个设计系统的名称，比如只有一款产品的中小型公司，就可以直接将第一类别定义为产品名称，如果是规模比较大的企业或者说公司有多条业务线的情况下，也可以定义为Token文件的名称，那么Token字符的第一级别就应该是业务的品牌。
当然，如果感觉没必要从这么宏观的角度出发，也可以将第一类的字符串定义为颜色主题（日、夜间模式的切换）或者是适老化模式和正常模式的切换，不过随着安卓12在去年推出的material you的设计理念，系统可以跟随手机壁纸颜色切换不同的主题颜色，未来各家厂商也会逐步上线此类功能，到时候的应用场景可能会更加广泛
在这个级别下，还有一种类型，大多是在海外产品或出海产品比较常见，就是会根据不同的系统来适配不同风格的设计（iOS、安卓、web）这样的话，这个级别也可以加入不同终端的判定。
第二类
第二级别的token主要是用来识别或定义字符串属于什么类别，比如按钮、icon、或者是一个组件，但需要注意的是，如果是定义字符串在组件上生效的话，就需要考虑2种情况，如果这个组件内部的元素已经被其他token字符串定义过了怎么办？比如组件内部的按钮已经被token定义为了白色，但是组件整体却被定义为了夜间模式，很可能会导致系统bug，所以第二类在初期不建议用来定义组件，或者在token嵌套逻辑梳理清晰后再定义组件token。
第三类
第三级别属于token中最核心的一部分，在这里我们将要定义token的实际属性，在这一级别我们可以定义很多不同的元素，可以定义为颜色、字体、间距、元素大小、布局方式、web端的话还可以定义媒体断点控制不同尺寸下的显示方式、阴影、交互状态甚至是线性动画的缓动曲线也可以定义。需要注意的是，在命名这个级别的字符串时，一定要避免使用在代码端意思相近的英语单词，比如定义字体：尽量避免使用type来定义，而是使用text，因为在技术侧type可以解释成很多意义，最后可能导致无法区分（灵魂小建议：如果使用拼音来进行定义的话，与代码的冲突可以无限接近于0）。在这个级别还可以组合使用，比如：color-text；color-background；text-size等等。
第四类
最后一级就是字符串的具体视觉表现样式的定义了，如果在前三级定义好了字符串的元素是什么形态（颜色？布局？字体？动画）那么在这一级别就是控制元素在不同状态下的视觉表现，颜色上可以区分为品牌色、辅助色、中性色、警告色......分别以不同的命名来进行区分，从元素的交互状态上来区分的话可以分为：成功状态、错误状态、警告状态等等，也能将第四级定义为元素视觉的实际数值，比如定义字体的话，可以定义1、2、3....级的标题样式，定义颜色的话，可以将基础色映射出的同色相的色值分别定义：比如red-1、2、3就代表相同色相为红色下的不同颜色梯度或者定义红色在日、夜间的不同色值。如果将颗粒度进一步缩小的话，也可以定义一个按钮的圆角大小
DTCG通过四个梯度完整的定义了design token所表示的不同意义，举例子来说，如果要定义一个按钮的design token，就可以这种结构化的级别层层递进：品牌名-button-color-press-primary来代表具体的按钮样式，但是我们在实际落地到项目中时，完全没有必要把所有级别的字符串都写到文档中，只要层级逻辑合理，减少一些字符的类别也是可行的
除了四种不同的结构化命名类别外，还有一个最重要的变量，就是全局变量， 全局变量是整个设计系统中的原始变量，它不带有任何的层级关系，仅仅作为第四级变量的具体数值（色值、间距值、字号等等）
初期试水初期搭建时，首先在figma或sketch中新建一个文件来作为整个组件库的源文件，在验证阶段，我们主要对颜色进行了定义，将品牌、辅助、灰阶色分别映射10个色彩梯度，并将不同分类的颜色一一列举出来
颜色列举完成后，我们规范了各个颜色的使用场景，主要分为功能色、文本色、填充色，然后对实际的颜色场景进行语义化的命名，由于颜色是一个通用性非常高的元素，所以我们将其定义为了全局变量，确保在之后的token制作中其他元素的可拓展性。
参考Apple HIG的色彩指南和Google的material color level的指南用：primary、secondary、tertiary、quaternary、quinary、senary作为后缀来表达颜色的强度，根据颜色的使用场景和颜色的梯度后缀，在figma中制作定义好颜色样式。
为了方便开发直接调用，我们还用Excel将所有的变量都导入进去，方便直接生成json和xml文件，省去了开发手敲变量
设计侧完成前期工作后，我们在一次小型的改版项目中进行了效果验证，虽然在初期试水的情况下，虽然开发对尝试的积极性并不高（因为要改动已有的代码组件加上还不能脱离日常的需求）但是实际的反馈是代码端的组件规范性和可拓展性、可复用程度有了质的提高，而且可预见的，未来无论是协作效率还是开发效率还有还原质量都有了保证，所以我们决定，将整个产品的design token提前提上日程
逐步上线验证效果在得到正向反馈后，我们迅速把重点放在了如何结构化的定义一整套design token上，首先我们将组成页面的所有基础元素一一穷举，决定在色彩、字体、icon、投影四个组成页面的基础元素上进行的design token转化，颜色的token化在初期的验证项目中已经跑通了，在接下来的二期项目中，我们依然按照命名规范逐一对基础元素进行token化，并基于初期的颜色token，分别多各类基础元素进行颜色嵌套，这样无论是设计流程中还是开发流程中，都可以方便快捷的替换颜色。同理，这种逻辑嵌套也可以应用在其他元素或者组件中。
而且我们找到了一个非常棒的figma插件“figma tokens”，利用这个插件我们可以完全节省掉自己导出Excel的时间，而且还可以自行导出json文件，大大减少了重复性的工作量
至于具体的操作方法，拿一个简单的medium的登录页来举例，在定义好基础的全局变量后，首先分析页面中的元素，页面分别以图标、 文字、按钮组成，然后对其进行token化，并通过插件导出json文件交接开发，这样非常方便的完成了页面的搭建，当然，还可以对其中的一些变量进行更进一步的封装，使其成为一个类似函数（将所有的逻辑封装在一起形成一个代码块）的概念。
开发可以更简单的调用，例如对字体在全局变量中定义更多的属性，像字号、字重、行高甚至是不同标题的颜色，最终定义为一个text-24的简单字符串，在调用的时候整个design token字符串可以更加简洁。（是的，我没有把我标出来的元素一一举例，因为太多了，淦！不过应该也不影响大家理解 ）
经过将近6个月的建设，专项小组完成了近三十多个核心页面的替换工作，在视觉一致性上有了非常大的提高，同时由于design token的存在，新同学对标准化的设计系统不再像之前一样，面对样式繁多的组件库无所适从，需求效率、走查效率显著提升，之前存在的各场景的规范不统一问题被完美解决，在实际承接需求方面，对基础的、可复用性强的需求，环比改造之前可提效50%以上，对于探索性需求，由于design token的支撑，减少了非常多的基础工作量，同样环比改造之前，提效30%以上。
总体来看，这次的项目虽然对业务、对用户的影响非常小，但从上线后，整个团队都感受到了此次项目升级带来的正向反馈，设计团队可以专注于更高效的承接业务需求，产品同学在拓展新业务时可以更专注于业务探索，提高版本迭代效率，快速铺开业务规模，开发同学也可以完美的还原设计稿，减少重复走查的工作量。
总结在这次的项目中，我们设计团队的同学和开发团队的同学一起历经了将近半年的时间，在项目开始之前，我们设计团队作为中台支撑各个业务线的需求，和开发同学的交流也仅限于日常的需求交付和需求验收，而平时上下游两个团队之间也经常因为互相不理解对方的开发逻辑和设计逻辑产生小矛盾。
但经过这段时间的紧密配合，团队之间交流加深，设计同学也慢慢了解了开发还原中的逻辑，开发同学也切身体会到了设计师的细节控晚期症状......除了团队配合之外，项目内容本身也仍然有继续迭代的空间，我们这次仅仅是定义了产品的基础token，后续我们会逐步将icon、布局、动画、插画一一写进我们的design token，并且利用已有的无缝协作插件彻底拉通设计-开发之间的壁垒，形成一个完整的设计系统。
design token能发挥的作用不仅仅是在规范设计语言一致性上，随着国内老龄化加剧，各大互联网厂商的设计团队和开发团队都面临着适老化的压力，很多产品甚至为了降低改造的工作量，重新开发了大字版来进行适老化，可是这样的解决方案也只是解一时之渴，而通过design token定义的设计系统，无论未来的发展方向如何，产品在适应性和可改造性上，都是不同维度的提升，同样的，有海外业务的公司，利用design token 也能极大的提升本地化的效率，所以在最后建议大家，除了关心用户体验和业务数据之外，也要对自己能否在团队内部提升效率多多考虑～
参考文章
https://medium.com/eightshapes-llc/naming-tokens-in-design-systems-9e86c7444676
https://medium.com/@jonas_duri/effective-design-token-structure-111e4bd934c8
https://frontside.com/blog/2021-01-15-design-tokens-and-components/
https://spectrum.adobe.com/page/theming/
https://zhuanlan.zhihu.com/p/32548767
