What problem does the Design Token actually solve? From Figma Variables to code, the design system should no longer rely on "remembering this color"

When the team is still small, everyone can remember that "the main color is #246BFE and the common spacing is 16." Once a product features multiple brands, dark mode, multiple terminals and multiple development teams, this way of maintaining consistency through memory will quickly become ineffective. The value of a Token lies in transforming design decisions from scattered numerical values into reusable, replaceable, and synchronizable semantic layers.

01 A Token is not about "quantifying all values", but rather establishing a common language for design decisions

Color #246BFE itself has no business significance. Naming it blue-600 only solves the lookup problem; When it is further referenced as color-action-primary, the team realizes that this value assumes the role of the "primary operation".

Therefore, mature tokens usually have at least two layers: the base value and the semantic value: the base layer describes the objective numerical value, while the semantic layer describes the purpose of use. When the brand blue is changed in this way, only the mapping needs to be modified, and there is no need to search for colors on each page one by one.

02 Figma Variables make tokens no longer just tables in the specification document

Figma's current Variables can store reusable values such as colors, numbers, and strings, and handle Light/Dark, desktop/mobile, or brand variations through Mode. Variables can also Alias each other, that is, they can refer to another variable.

This means that the design file can truly be token-driven, rather than the specification stating spacing-04=16px, while the actual page is still filled with 16 by the designer's hand. The closer the norms and design behaviors are, the easier the system is to maintain.

03 Do not mix the base Token, semantic Token, and component Token into one layer

For example, color-blue-600 belongs to the base value; color-text-link belongs to semantics; button-primary-background belongs to component-level mapping. All three layers can be valuable, but not all teams need to complete all three layers.

If the product scale is not large, the basic and semantic aspects are already sufficient. Establishing thousands of component tokens too early will cause designers to first understand a complex naming system in order to select a border color.

04 Mode is suitable for expressing "the value changes of the same semantics in different environments".

In Light mode, surface-primary may be white, but in Dark mode, it turns dark gray. The spacing page on mobile devices may be smaller. Figma also supports managing these contexts through Mode.

Mode is not used to replace all Variant components. Structural changes such as button size and icon position are still more suitable for component properties; Tokens are better at managing values that can be systematically replaced.

05 Naming should express the purpose and avoid writing the current visual implementation in the name

"grey-100-text" will soon encounter problems: if the background is changed to off-white in the future, this name will conflict with the actual value. Semantic names should be as stable as possible, such as text-secondary, border-subtle, surface-raised.

The base color can retain an objective name because it originally describes the color gradation. The semantic layer should be named around roles and states. Naming stability is more important than "looking technical".

06 The synchronization of design and code does not end with exporting JSON once

The real difficulty with Tokens lies in governance: Who can make changes? How has the review been changed? When will the code be synchronized? How can old tokens be deprecated? If the design end changes the value at any time and the development end synchronizes once every quarter, the two sides will still drift.

The team needs to define versions, change records and release processes. Even with the use of automated tools, someone still needs to determine whether this change is a visual adjustment, a disruptive alteration or a new semantic.

07 Do not force occasional values into tokens for the sake of "systematization"

A special offset that is used only once for a certain marketing Banner may not be worth creating a global token. If a variable is created for every value that appears in the system, the final selector will be more difficult to use than filling it in by hand.

The criteria for judgment could be: Whether it can be reused across pages and components? Is it necessary to switch themes? Does it represent stable design decisions? If all the answers are yes or no, the local values can be completely retained.

08 The value of a Token is ultimately reflected in the modification cost rather than the number of variables

A truly mature Token system should make brand color changes, Dark Mode, density mode, and multi-terminal spacing adjustments more controllable, and also allow designers and developers to discuss the same name.

If the team has 3,000 tokens but still needs to manually patch each page every time there is a revision, it indicates that the system merely changes the storage location of the values without truly establishing a maintainable dependency relationship.

09 From "value changed" to "Semantic changed", the type of change should be distinguished

Adjust the primary-color from blue to a slightly darker blue, which is usually a value layer change; Changing the danger color from red to orange might have altered semantic recognition. Changing the spacing-page from 24 to 40 May affect a large number of layouts. The risks of different changes vary.

Token changes can be classified: visual fine-tuning can be released in minor versions, while semantic renaming and deletion require migration instructions. Otherwise, if the design team simply says, "Just change a variable," the development side might have to deal with regression tests on dozens of pages.

10 A multi-brand system can better reflect the true value of a Token

When the same set of product capabilities needs to be white-labeled to multiple customers, the component structure remains unchanged, but the brand color, font, rounded corners and partial density are different. Tokens can concentrate these differences at the theme layer instead of replicating three sets of component libraries.

However, if brand differences have already involved completely different information architectures and interactions, Tokens should not be forced to address them. Token excels at managing visual and a few behavioral parameters, but it is not a universal abstraction for all product differences.

Frequently Asked Questions

Does a small team need to create a Design Token?

One can start with the least color, font, and spacing semantics without having to replicate the complete layering of large companies.

Is Figma Variables equal to Design Token?

Variables is one of the tools for implementing and managing tokens. Token is more broadly defined, involving naming, semantics, code and governance.

Does Dark Mode have to use Mode?

Mode is well-suited for managing the values of the same semantics under different topics, but the specific implementation still depends on the system structure.

Should the Token name be a color name or a purpose name?

The base layer can use color names, while the semantic layer prioritizes using purpose names, such as text-primary and surface-brand.

Is it true that the more tokens one has, the more professional they are?

No. Quantity should be driven by reuse and maintenance requirements. Excessive segmentation will increase cognitive costs.