Design System Guide. Chapter 6. Tokens

Tokens are often perceived as a purely technical detail, a way to pass values from design to code. At best, they are seen as a convenient format for storing colors, sizes, and spacing.

In reality, tokens are a key mechanism that makes the entire multi-layered structure of a design system reproducible, scalable, and manageable over time.
It is through tokens that a system stops being a set of agreements and turns into a working architecture.

Without tokens, decisions made at the base layers remain declarative: parameters exist separately in Figma and separately in code, but are not connected.
They may match in value, but not in origin. Any change requires manual synchronization, which means reliance on trust, attention, and constant control. Over time, discrepancies become inevitable, even in strong teams.

Tokens solve this problem by turning parameters into a single source of truth that both designers and developers rely on.
Importantly, they capture not just numbers or colors, but the decisions behind those values.

A design system is built on explicit connections between layers.
Lower layers define constraints and the rules of the game; upper layers assemble interfaces and flows from them.

Tokens make these connections real and enforceable. They:

• capture decisions made at the level of principles and base layers
  
• provide them in a format understandable to both design and code
  
• prevent local overrides of system parameters without an explicit step outside the system
  

In effect, tokens are a contract between layers.
Components, templates, and screens no longer “know” concrete values. They only know roles and dependencies: primary color, secondary text, base spacing, accent state.

When tokens are missing or poorly organized, the same values begin to be duplicated in different places.
At first this seems harmless: the same gray is simply copied into several styles. But over time:

• micro-variations appear
  
• values stop matching
  
• changes in one place are not reflected in another
  

Consistency erodes not abruptly, but gradually, which is exactly why the problem is often noticed too late.

The key difference between tokens and regular styles lies in the level of abstraction.

A style answers the question “what value is used.”
A token answers the question “why this value is used.”

For example:

• #1A73E8 is just a color
  
• color.action.primary is a decision
  

This naming creates an additional layer of meaning.
When a designer or developer uses a token, they are not choosing a shade of blue, they are choosing a role: “primary action.”

This significantly reduces cognitive load and the number of errors.
Most importantly, it allows the system to change without rewriting all interfaces: if the role remains the same, the value can evolve.

Tokens are not the starting point of a design system.
They emerge only after the system has already defined:

• which semantic roles are truly important
  
• where the boundaries of acceptable variability lie
  
• which constraints must be strict and which can be flexible
  

Until these questions are answered, tokens will inevitably be arbitrary.
They will reflect the current state of the UI Kit rather than an architectural intent.

A common mistake is trying to introduce tokens too early or extracting them mechanically from an existing set of components.
In that case, tokens simply solidify existing chaos:

• random names
  
• excessive roles
  
• duplicated values
  

Instead of a management tool, they become yet another layer of complexity.

Well-designed tokens are always a result of architectural decisions, not their cause.

Built-in Figma Tokens

Figma provides native token support through Variables:

• Documentation

Variables allow you to:

• define color, typography, and sizing tokens
  
• use them in styles and components
  
• link values across modes (for example, light / dark)
  

This is a good entry point for most teams, especially at early stages of building a system.

Tokens Studio

Before Variables appeared, the most popular tool was the Tokens Studio plugin:

• Website and documentation
• Figma plugin

Tokens Studio still remains a more powerful solution in a number of scenarios:

• support for complex and nested tokens
  
• storage of descriptions, comments, and metadata
  
• flexible JSON structure
  
• integration with CI/CD and repositories
  

It is often used in mature design systems where Figma is just one of the token clients, not the only source.

The main pain point without tokens is divergence between design and implementation.

Typical scenarios:

• a designer changes a brand color in Figma → developers keep using the old value in code
  
• a new theme or mode is introduced in code → it appears in Figma late and incompletely
  
• local tweaks in components accumulate, and system parameters stop being unified
  

As a result, even a visually similar interface loses predictability:

• identical buttons behave differently
  
• states differ across screens
  
• support and QA spend time searching for “minor” inconsistencies
  

Tokens solve this problem by making parameters shared between both environments.

For tokens to work between Figma and code, a reliable export and transformation process is required.

The most common tool is Style Dictionary:

• Documentation

Style Dictionary allows you to:

• transform tokens into CSS variables
  
• generate themes for different platforms
  
• maintain a unified format for web, iOS, and Android
  

A typical workflow:

1. Tokens are stored in Figma or Tokens Studio
   
2. Exported to JSON
   
3. Transformed for target platforms
   
4. Used directly in code
   

When such a pipeline is in place:

• changes propagate automatically
  
• errors are detected early
  
• design and code rely on a single data source
  

Tokens do not just transmit values.
They actively protect the architectural constraints of the system.

If a parameter is tokenized:

• using arbitrary values becomes difficult
  
• deviations become conscious and visible
  

If it is not, local decisions start accumulating unnoticed.

Thus, tokens evolve from a passive value store into an active governance tool of the design system.

Tokens are not an additional technical layer, but a mechanism that makes the entire design system structure alive and functional.

They provide:

• safe and controlled change
  
• real synchronization between design and code
  
• enforcement of constraints rather than mere recommendations
  

When tokens are built on already established principles and architecture, they allow the system to grow and evolve while maintaining consistency and predictability.