前言
近期执行的专案在进行翻新包含了整体的视觉设计，因此前端也面临要如何同步管理产品视觉的问题。工具是使用 Figma 而前端是使用 Tailwind 这套 utility-first CSS 的框架，不过以上都只是工具，主要想要谈的还是更抽象的：数字产品可以如何管理 UI 上的变量。
先说痛点，先前专案并没有具体的规范应该如何定义 UI 当中的数值，导致魔法数字（没有规范与描述的值）流窜于整个产品当中，造成了非常大的的困扰。
我会解释得尽量具体明白如果要重新设计一款数字产品会怎么管理其中的数值，这些想法很大程度启发自 Figma 关于 Design Token 相关文件。
什么是 UI 变量
UI 变量就是存在于用户界面上的变量，有的地方叫它设计令牌（Design Tokens），有的地方则称呼变量（Variables），总之就是一个名称指向一个值，可以想象一个箱子装载某种应用于 UI 的数值。
UI 数值有很多种，可以是代表颜色、大小尺度、圆角尺度、透明度、特效尺度……等，具体的例子如下：
gray-500=#333spacing-1=4pxopacity-50=50%
不同环境多少会有差异，通常变量也具备指向另一个变量的能力，例如：
primary-500=gray-500
如何管理 UI 变量
你一定用或多或少采用过变量的概念去管理数值，但却没有特定的命名或规则，因此第一步要做的就是找出数值的规律，并且给予一个统一明确的名称。接下来会以颜色为主要案例解释。
第一步：原始值 Primitive Variable
目的：达成全局通用且可被管理的「数值」
既然被称呼为原始值，这个阶段的命名应当直白单纯的描述「值」本身，例如：它是黄色的、绿色的、洋红色的，并且与其他颜色的明暗关系是介于百分之三十，未来整套系统只会也只需要有这样一种颜色避免混乱：yellow-300。
透过建立一系列变量来代表某种色阶区段的颜色：
yellow-100=#fef9c3yellow-200=#fef08a- …
yellow-1000=#713f12
如此一来就可以清晰的定义整个产品「黄色」涵盖的范围与阶层，而不是让颜色散乱、毫无秩序可言的分散在各地。可依据喜好去定义命名前后缀或变量量，重点是一致性。
第二步：语义化 Semantic Variable
目的：达成全局通用且可被管理的「意义」
语义化就代表在这个阶段应当赋予值一个具体的意义，例如先前提到的黄色系列颜色本身并没有具体的涵义，可以在任何地方被使用，可能会导致让特定的颜色与意义绑定在一起，在中大型系统中我们必然会需要将重复的 Pattern 给抽离出来管理，例如：
accent-100=yellow-100accent-200=yellow-200accent-1000=yellow-1000
这样就创建了一个具备涵义的颜色：accent（强调色），未来只要产品中有需要强调颜色的时候，由于先前已经定义好整套现成可用的强调颜色，任何会需要强调颜色的 UI 都能受益，增进了设计的一致性与维护性。
同时制作语义化变量也能动态的替换特定语义化变量背后的数值，最好的例子就是深色模式，举例情境……
- 未来强调色要微调，只要重新指向语义化数值就能一次搞定。（我不喜欢强调色是黄色，所以改指向红色）
- 要制作不同风格系统，只要重新指向语义化数值就能一次搞定。（我要制作一套深色风格界面，所以改指向深色系列的原始值）
等到某种意涵在 UI 当中被重复使用时就代表你应该尽量将它抽离为语义化变量，不只是方便未来维护，也能让每次绘制全新 UI 时能够从约定好的基础上开始。可以参考成熟的设计系统通常具备哪些语义化变量开始，例如：primary、secondary、success、warning、danger、info。
第三步：组件变量 Component Variable
现今 UI 多多少少具备某种性质的可重复扩充性，就像积木一样，而组件变量就是针对这些组件的数值所打造的语义化变量，例如 button-hover、button-active、button-disabled，定义好这些组件变量就像是在为组件建立可替换的接口，通过指定不同数值给组件变量以达成相同组件但不同的外貌，举例情境……
- 相同的组件但在横跨不同产品时，由于每个产品对应品牌颜色皆不相同，因此可以通过指定颜色给事先定义好的组件变量达成相同组件但不同产品品牌的外貌。
- 定义组件变量将会让我们强制思考组件对外的关系，要求公开接口的描述必须清晰。
总结
以上都是用最具体的方式描述如何管理 UI 变量的大概念
实际上你可以根据自己的喜好去制定细节，像是统一常见的组件接口名称、语义化变量的命名规则、原始值的阶度……等，重点是要让整个系统具备一致性与可维护性。