Skip to Content
DocumentationOrganizing Your Figma VariablesVariable organization principles

Variable organization principles

When using Variables Xporter, the way you organize your variables directly impacts the quality of your exported code. Let’s explore how to effectively organize variables in Figma to ensure the exported code seamlessly integrates with your development environment.

Naming principles

To make variables more understandable and maintainable, we recommend following these naming principles:

  • Use English names: this ensures compatibility with development environments and maintains consistency when exporting to Tailwind CSS configurations or CSS variables
  • Choose semantic naming: variable names should clearly express their purpose, making them instantly understandable to team members
  • Keep it concise: avoid overly long or complex naming to maintain code readability and maintainability

Top-level names

If your project uses Tailwind CSS, ensure that your top-level variable names align with Tailwind CSS theme configuration keys. Here are some common configuration keys:

  • colors
  • spacing
  • fontSize
  • fontWeight
  • borderRadius
  • opacity

You can find the complete list of configuration keys in the Tailwind CSS Theme Configuration Reference.

Naming conventions

In design systems, we often need to use multiple words to describe a variable. Variables Xporter automatically converts naming formats based on the target format:

  • Tailwind CSS configuration files: uses camelCase format (e.g., fontSize, fontWeight)
  • CSS variables: uses kebab-case format (e.g., font-size, font-weight)

Here are some common naming formats for reference:

  • 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
ℹ️

When exporting variables, regardless of which format you use from the above, Variables Xporter will automatically convert the output to match the conventions or requirements of Tailwind CSS configuration files and CSS variables:

  • Tailwind CSS configuration files: uses camelCase format (e.g., fontSize, fontWeight)
  • CSS variables: uses kebab-case format (e.g., font-size, font-weight)

Grouping principles

Proper variable grouping significantly improves workflow efficiency. We recommend using the / symbol to organize variable hierarchies, similar to managing a file system:

Think about how difficult it would be to find files if they were all dumped in your computer’s root directory. Similarly, we need to create clear hierarchical structures for our variables:

    • primary
    • secondary
    • tertiary
    • ...

These correspond to the following variables in Figma:

  • colors/primary
  • colors/secondary
  • colors/tertiary

Using the DEFAULT keyword to organize variable hierarchies

The DEFAULT keyword serves a dual purpose: it sets a default value and, more importantly, unifies variables at the same level, making variable management clearer and more systematic. Let’s look at a specific example:

  • colors/primary
  • colors/primary/foreground

This is a common set of variables used for primary color and text color on primary backgrounds, but this naming alone isn’t sufficient. Let’s think about it in terms of file management:

    • primary
      • foreground

Here we encounter an interesting challenge: while logically colors/primary and colors/primary/foreground should be in the same directory, they’re actually scattered in different locations. Let’s see how this appears in Figma:

Cannot find colors/primary variable in colors -> primary directory

Cannot find colors/primary variable in colors -> primary directory

To find the colors/primary variable, you need to go to the colors directory:

Finding colors/primary variable in colors directory

Finding colors/primary variable in colors directory

As our variables grow in number, finding colors/primary becomes more cumbersome because we can’t rely on the sidebar for quick navigation and must search within the colors directory instead. This not only affects our workflow efficiency but, more importantly, when we try to convert this structure to Tailwind CSS V3 configuration, we run into a technical limitation: JavaScript objects cannot use the same key as both a value and an object.

export default { : { : { : { : 'var(--colors-primary)', primary: {
An object literal cannot have multiple properties with the same name.
: 'var(--colors-primary-foreground)', }, }, }, }, : [], };

Don’t worry though, Tailwind CSS provides an elegant solution — using the DEFAULT keyword:

export default { : { : { : { : { : 'var(--colors-primary)', : 'var(--colors-primary-foreground)', }, }, }, }, : [], };

The best part is that in actual development, you don’t need to write out the DEFAULT keyword. Tailwind CSS handles this detail automatically, keeping your code clean:

<div class="text-primary"> <p>Hello, world!</p> </div>

With this technique, we can elegantly organize our variables in Figma. Just use DEFAULT as a marker for default values:

  • colors/primary/DEFAULT - default value for primary color
  • colors/primary/foreground - text color on primary background

They will appear in the same directory:

Organizing variable hierarchy using default values

Organizing variable hierarchy using default values

Last updated on
Built with ❤️ by Kinsey.