Your Figma variables are not a design token system

Much like Brad Frost's astute observation that Your Sketch library is not a design system, I find myself compelled to make a similar declaration about another misunderstood element of design systems: design tokens.

The Common Misconception

It's easy to think that creating a comprehensive set of variables in Figma means you've implemented design tokens. After all, these variables do help control colours, spacing, typography and various style properties across designs, bringing welcome consistency to mockups and prototypes. However, there's more to design tokens than what happens in our design tools.

A basic example of Figma variables organised following a semantic naming convention, and grouped in two modes—that, in this case, represent two themes.

Figma variables are an excellent tool, introduced in 2023, that finally brought native variable management to Figma. However, they were designed primarily to serve the design workflow—not to bridge the design-to-development gap.

In fact, a variable in Figma is a representation of a design token, not a token itself.

This distinction is crucial.

What design tokens actually are

Design tokens are platform-agnostic representations of design decisions. They exist outside of any particular design tool or development framework. True design token systems include:

1. A source of truth - often Figma variables, but could be anywhere. A design token management tool is highly recommended.

2. A standard token format - converting design decisions into a standardised format, typically JSON — There is a web standard for design tokens: Design Tokens Format Module

3. Platform adapters - translating the standardised format into language-specific variables (CSS variables, Swift constants, XML files for Android, etc.)

4. Metadata and documentation - describing the purpose, usage, and relationships between tokens

View fullsize

Without this transformation capability, you simply have design tool variables—useful, but limited.

When a Simpler Token Approach Might Suffice

If your product exists solely on a single platform (like web only) and represents a single brand, a full cross-platform design token system with complex transformation pipelines may be unnecessary overhead. What you genuinely need is:

• A simple token system with a comprehensive set of variables in your design tool

• A consistent method to export and share these tokens with developers

• A systematic implementation for developers to consume these values in code

Even in web-only projects, tokens offer considerable benefits for large-scale design systems by providing a single source of truth, enabling theme management, and facilitating maintenance. The difference is that you can often implement a more streamlined token workflow without the added complexity of cross-platform transformations.

The Purpose of Design Tokens

The real power of design tokens emerges in multi-platform environments. When your product must maintain visual consistency across web, iOS, Android, and potentially other platforms, design tokens become essential. They ensure that your brand colour, your borders, and your text styles are identical regardless of whether it's rendered in a browser, iOS app, or Android application.

Even more compelling is the case for multi-brand products or white label solutions. In these scenarios, a robust design token system becomes not just useful but critical:

• Multi-brand portfolios: Companies managing several brands need the ability to maintain distinct visual identities while sharing underlying components. Design tokens allow teams to swap entire brand themes without rebuilding components.

• White label products: For products that need to be reskinned for different clients, design tokens provide a systematic way to adapt all visual elements to match client brand guidelines. This transforms what would be weeks of manual adjustments into a streamlined configuration process.

• Theming capabilities: Whether supporting light/dark modes or completely custom themes, design tokens provide the architecture to change visual characteristics at scale without touching component code.

Implementation Considerations

A proper design token implementation requires:

• Naming conventions that make sense across platforms (e.g., using color.brand.primary instead of just blue to ensure semantic meaning translates across different codebases)

• Transformation tools like Style Dictionary, Theo, or Token Studio for Figma that convert tokens between formats

• Version control for managing changes to tokens (e.g., storing tokens in Git repositories with semantic versioning to track changes like "updated primary blue from #0055FF to #0066FF")

• Integration processes for each platform that consumes the tokens (e.g., npm packages for web, CocoaPods for iOS, Gradle dependencies for Android)

• Governance workflows for proposing and approving token changes

Bridging the Gap

While Figma variables aren't design tokens, they can certainly be part of your token strategy. Consider:

1. Using Token Studio for Figma as a bridge between Figma variables and code-ready tokens

2. Establishing a clear token hierarchy from primitive values to semantic applications

3. Creating a syncing strategy to keep design tool variables and code tokens aligned

4. Documenting the relationship between variables in your design system and tokens in your codebase

Moving Forward

Before investing in a design token system, ask yourself:

1. Do we build for multiple platforms?

2. Do we struggle with inconsistency between platforms?

3. Do we frequently make design changes that need to cascade across many products?

If you answered yes to these questions, a proper design token system—beyond Figma variables—will provide significant value.

Conclusion

Figma variables are an excellent start and a critical component of your design system. However, they're just one piece of a complete design token ecosystem. By understanding the distinction, you can make informed decisions about where to invest your team's resources and how to structure your design system architecture.

The ultimate goal isn't to have the most sophisticated token system—it's to create consistent, maintainable products that can evolve—and scale—efficiently. Sometimes Figma variables with a simple export process is enough. Other times, you need the full transformation pipeline that fully fledged design token systems provide.

Choose the approach that matches your actual needs, not what's trendy in design system discourse.