在 Figma 中如何更好的命名并管理变量

建立一套 Design Tokens 是一个重要的工作，它可以帮助你更好的管理你的设计系统，同时也能够让你的设计更加一致和易于维护。在 Figma 中，我们可以使用变量（Local variables）来构建 Design Tokens，但是如何更好的命名并管理这些变量是关键。

使用英文命名

请仅使用英文或数字为你的变量进行命名，不要混合使用多个语言，这不仅让变量看起来混乱，在 Dev 模式里也会让开发者感到困扰，他们无法简单的复制有用的代码。

colors/background/默认  ❌  
colors/background/default  ✅

例如，如果你使用 colors/background/默认 这样的命名，在 Figma 的 Dev 模式下，生成的 CSS 变量会是 var(--colors-background-)，中文的“默认”不见了，因为这种情况 Figma 无法识别中文字符，所以会将其忽略，在 CSS 中，中文字符也是不被允许的。

使用 / 进行分组

分组规则

请尽可能的使用 / 将变量进行合理的分组，这样可以更好的组织你的变量，使其更加清晰易读，同时也方便其他设计师和开发人员查找和使用。就像文件一样，你不会把所有文件都丢在电脑的根目录里，而是将他们放在不同的文件夹，分门别类。 一般情况下，你可以用以下规则进行分组：

  1. Foundation: 表示基础的设计属性类型，如 colors、spacing、screen 等。
  2. Target: 表示该变量应用到何处
    • 可以指具体的属性，如 border、background、box-shadow 等，对应的完整命名是colors/border、colors/background、colors/box-shadow。
    • 也可以指应用的场景，如 foreground（用于文字颜色）、danger（用于强调危险状态的颜色），对应的完整命名是colors/foreground、colors/danger。
    • 还可以指具体的组件，如 Button、Input、Card、Icon 等。对于组件，你可能需要进一步的分组， 因为一个组件会包含多个样式，例如 Button 组件可以分为 colors/button/background、colors/button/border 等。
  3. Modifier: 这个部分是对该变量的额外细节补充，如 hover、active、focus、disabled 等，也可以指具体的状态， 如 danger、success、error、warning 等以及颜色等级 primary、secondary 等，并非所有变量都需要这个部分，例如全局变量 colors/border、colors/background 等，只有当你需要对该变量进行细分时才需要添加。

像管理文件一样管理你的变量

有了上面的分组规则，似乎已经可以很好的管理变量了，但是有一个问题，假设你在电脑上有以下目录结构：

把他想象成你正在创建一个名为 colors/background/hovered 的变量，它的意思在 hover 状态下背景的颜色，那么默认状态下的背景颜色呢？ 可能你会想到直接用 colors/background 来表达，这样看似简洁合理，让我们来看看这样的命名方式会带来什么问题，在文件管理中还原这样的结构：

在 Figma 中的实际结构：

colors/background 这个变量呢？你会发现你无法在同一个地方管理默认状态和 hover 状态的变量，因为他们属于不同的文件夹/分组，这就是问题所在。 就像是你在管理你电脑里繁多的文件，你自然会把同一类型的文件放在同一个文件夹里，而不是把他们分开，这样你可以更好的管理和查找文件。 所以，在对变量进行管理时，如果某个变量有多个状态，请为默认状态进行单独命名，例如 colors/background/default，不要省略 Modifier 部分，这样能保证 colors/background 分组下的所有变量都在同一个地方。

分隔多个单词的方法

在遇到一个属性、状态或者组件是由多个单词组成时，你需要进行分隔。在 Figma 中，你不能使用 .、{}、$ 等字符作为分隔，当遇到需要分隔多个单词的情况时，请使用以下格式：

  • camelCase -> twoWords
  • constantCase -> TWO_WORDS
  • kebabCase -> two-words
  • pascalCase -> TwoWords
  • pascalSnakeCase -> Two_Words
  • snakeCase -> two_words
  • trainCase -> Two-Words
  • capitalCase -> Two Words
  • sentenceCase -> Two words

具体使用哪种命名格式，请与你的团队充分沟通，包括开发人员及其他设计师，这十分重要，并且尽量不要包含多种格式，除非你知道自己在做什么。

分隔还是分组？

请在真的需要分隔的时候才进行分隔，例如某些属性、状态或者组件由多个单词组成： border-radius、max-width、dropdown-menu

border-radius/sm  ✅
maxWidth/2xl  ✅

在以下情况，你应该使用分组，而不是分隔：

colors/background-card ❌
colors/border-dropdown-menu ❌

colors/background/card ✅
colors/border/dropdown-menu ✅

上面的错误案例中，colors/border-dropdown-menu 能够很好的说明分隔和分组的使用时机问题，border-dropdown-menu 并不是表示唯一含义的一个词汇，dropdown-menu 才是，把它们强行组合在一起会让人感到困惑， 而 colors/border/dropdown-menu 则能够很好的表达出 border 和 dropdown-menu 之间的关系。时刻记住，你创建的是一个需要被多人使用、并不断迭代的 Design Tokens，清晰明了、容易理解的结构和命名十分关键， 不要害怕分组，比起分组更可怕的是不合理的分隔，这会让你的变量越来越混乱，最终难以维护。

参考开发的技术栈

任何规则都不是一尘不变的，你可以根据你的团队情况进行调整，但是团队的统一规范很重要，我们团队在开发时使用 Tailwind CSS，在 Tailwind CSS 的配置文件中通常会用 DEFAULT 来表示默认状态， 所以为了保持一致，我们也会在 Figma 中使用 DEFAULT 来表示默认状态，例如 colors/background/DEFAULT，这样能够让 Figma 中的变量导出为 Tailwind CSS 配置时更加方便和统一。 如果你的开发团队使用 CSS Variables，那么在分隔单词时，你就应该总是使用 kebabCase 格式，因为这是 CSS变量常见的命名习惯。

总而言之，需要与开发团队进行沟通，以便你的变量真的能够落地。