How to Better Name and Manage Variables in Figma

Establishing a set of Design Tokens is crucial work that helps you better manage your design system while making your designs more consistent and maintainable. In Figma, we can use Local variables to build Design Tokens, but how to better name and manage these variables is key.

Use English Naming

Please use only English or numbers to name your variables. Don't mix multiple languages, as this not only makes variables look messy but also confuses developers in Dev mode who can't easily copy useful code.

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

For example, if you use naming like colors/background/默认, in Figma's Dev mode, the generated CSS variable will be var(--colors-background-) — the Chinese "默认" disappears because Figma can't recognize Chinese characters and ignores them. Chinese characters are also not allowed in CSS.

Use / for Grouping

Grouping Rules

Please use / to reasonably group your variables as much as possible. This better organizes your variables, making them clearer and more readable, while also helping other designers and developers find and use them.

1. Foundation: Represents basic design property types like colors, spacing, screen, etc.
2. Target: Indicates where the variable is applied — can refer to specific properties like border, background, box-shadow, or application scenarios like foreground, danger.
3. Modifier: Provides additional detail supplements for the variable, such as hover, active, focus, disabled, danger, success, primary, secondary, etc.

Manage Your Variables Like Files

With the above grouping rules, it seems we can manage variables well, but there's an issue. Suppose you have the following directory structure:

Imagine you're creating a variable named colors/background/hovered, meaning the background color in hover state. What about the default state background color?

You might think to use colors/background directly, which seems concise and reasonable. Let's see what problems this brings:

The actual structure in Figma:

Where is the colors/background variable? You'll find you can't manage default state and hover state variables in the same place because they belong to different folders/groups.

Therefore, when managing variables, if a variable has multiple states, please name the default state separately, such as colors/background/default. Don't omit the Modifier part.

Methods for Separating Multiple Words

When encountering properties, states, or components composed of multiple words, you need separation. Common formats:

• camelCase → twoWords
• kebabCase → two-words
• pascalCase → TwoWords
• snakeCase → two_words
• constantCase → TWO_WORDS

Which format to use should be fully communicated with your team.

Separation vs. Grouping?

Only separate when properties, states, or components are composed of multiple words:

border-radius/sm  ✅
maxWidth/2xl  ✅

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

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

You're creating Design Tokens that need to be used by multiple people and continuously iterated. Clear, understandable structure and naming are crucial.

Reference Your Development Tech Stack

No rules are set in stone. Our team uses Tailwind CSS in development, and Tailwind CSS configuration files typically use DEFAULT to represent default state. To maintain consistency, we also use DEFAULT in Figma, such as colors/background/DEFAULT.

If your development team uses CSS Variables, then when separating words, you should always use kebab-case format, as this is the common naming convention for CSS variables.

In summary, communication with the development team is necessary to ensure your variables can actually be implemented.