Design Tokens are named, reusable values that store important design decisions such as colors, typography, spacing, sizing, border radius, shadows, opacity, motion, and other visual properties. Instead of repeatedly entering raw values such as #0D99FF, 16px, or 8px, teams can give those values meaningful names and reuse them throughout a design system.
Design tokens create a shared language between designers and developers. They help maintain consistency, simplify global updates, support themes and modes, reduce design errors, and make a growing design system easier to manage.
In Figma, variables are a key way to implement design tokens. Variables can store reusable values, support aliases, and use modes for different contexts such as light and dark themes or responsive configurations.
Learn professional Figma, UI/UX design, design systems, components, variables, prototyping, and professional design workflows through JustAcademy Figma Training. You can also Register for Figma Course Demo.
Design tokens are named values that represent reusable design decisions. They allow a design system to store important values in one place and reference those values throughout components, patterns, screens, and products.
Raw Design Value
↓
Meaningful Token Name
↓
Reusable Design Decision
↓
Components
↓
Patterns
↓
Product Screens
Design Tokens: Named and reusable values that represent design decisions and help maintain consistency across a product, design system, and implementation.
Suppose a product uses the same blue color on buttons, links, icons, and other elements. Instead of manually entering the same hex value everywhere, the team can create a token such as color-brand-primary.
color-brand-primary
↓
#0D99FF
↓
Buttons
Links
Icons
Focus States
Other UI Elements
If the brand color changes later, the underlying token can be updated and the connected design resources can follow the new value.
Large design systems contain thousands of design decisions. Without a systematic approach, teams may use slightly different colors, spacing values, font sizes, border radii, and other properties. Tokens help centralize these decisions.
A token can represent a specific design decision that is reused throughout the system. Instead of storing the same value independently in many places, the system can reference one defined value.
Single Token
↓
Multiple Components
↓
Multiple Screens
↓
Multiple Products
↓
Consistent Experience
Imagine a designer manually uses #2563EB in 40 different places. A developer separately uses another blue value in the application code. Later, the brand color changes and every occurrence must be found and updated manually.
Button → #2563EB
Link → #2563EB
Icon → #2563EB
Card → #2563EB
Header → #2563EB
40+ Manual References
↓
Difficult Maintenance
With tokens, the same design decision can be represented by a meaningful name.
color-brand-primary
↓
#2563EB
↓
Button
Link
Icon
Card
Header
When the value changes, the system can propagate the updated value to the resources that reference it.
| Raw Value | Design Token |
|---|---|
| #2563EB | color-brand-primary |
| 16px | spacing-md |
| 8px | radius-sm |
| 24px | font-size-heading |
| 0.5 | opacity-disabled |
Meaningful names communicate the purpose of a value. A developer or designer should be able to understand how a token is intended to be used without inspecting its raw value.
Better: text-primary
Less useful: gray-900 when the actual purpose is primary text.
Design tokens can represent many types of design decisions. The exact categories depend on the needs and complexity of the design system.
Color tokens store reusable color decisions. They can represent brand colors, backgrounds, text colors, borders, icons, feedback states, and other interface roles.
color-brand-primary
color-brand-secondary
color-text-primary
color-text-secondary
color-background-default
color-background-subtle
color-border-default
color-feedback-success
color-feedback-warning
color-feedback-error
Primitive color tokens store the basic values available within the design system. They generally describe the available color scale rather than the exact UI role.
blue-100
blue-200
blue-300
blue-400
blue-500
blue-600
blue-700
blue-800
blue-900
Semantic tokens describe the purpose or role of a value. They make the design system easier to understand and can make themes easier to manage.
text-primary
text-secondary
background-primary
background-secondary
border-default
action-primary
feedback-error
| Primitive Token | Semantic Token |
|---|---|
| blue-600 | action-primary |
| gray-900 | text-primary |
| gray-100 | background-subtle |
| red-600 | feedback-error |
Typography tokens can represent font sizes, font families, line heights, letter spacing, font weights, and other typographic decisions.
font-family-body
font-family-heading
font-size-xs
font-size-sm
font-size-md
font-size-lg
font-size-xl
font-weight-regular
font-weight-medium
font-weight-bold
line-height-body
line-height-heading
Spacing tokens establish a consistent spatial system. They can be used for padding, margins, gaps, layout spacing, and other distance-related properties.
spacing-xs → 4px
spacing-sm → 8px
spacing-md → 16px
spacing-lg → 24px
spacing-xl → 32px
spacing-2xl → 48px
Sizing tokens can define reusable dimensions for controls, icons, containers, avatars, and other interface elements.
size-icon-sm
size-icon-md
size-icon-lg
size-control-sm
size-control-md
size-control-lg
Border-radius tokens maintain consistent corner treatments across components.
radius-none → 0px
radius-sm → 4px
radius-md → 8px
radius-lg → 12px
radius-xl → 16px
radius-full → 999px
Border tokens can define reusable border widths, colors, and styles.
border-width-thin
border-width-medium
border-color-default
border-color-strong
border-color-focus
Shadow tokens help maintain consistent elevation and depth across the interface.
shadow-none
shadow-sm
shadow-md
shadow-lg
shadow-xl
Opacity tokens can provide consistent transparency values for overlays, disabled states, backgrounds, and other UI treatments.
opacity-disabled
opacity-overlay
opacity-subtle
opacity-hover
Motion tokens can represent reusable animation durations, easing behaviors, and other motion decisions.
motion-duration-fast
motion-duration-normal
motion-duration-slow
motion-easing-standard
motion-easing-emphasized
A common design-token architecture uses multiple layers. The exact structure depends on the complexity and requirements of the organization.
Primitive Tokens
↓
Semantic Tokens
↓
Component Tokens
↓
Components
↓
Patterns
↓
Product Screens
Primitive tokens represent the basic values available within a system. They answer the question: What values exist?
Primitive
blue-600 → #2563EB
gray-900 → #111827
spacing-4 → 16px
radius-md → 8px
Semantic tokens describe how a value should be used. They answer the question: What role does this value play?
action-primary → blue-600
text-primary → gray-900
spacing-content → spacing-4
card-radius → radius-md
Component-specific tokens describe where a value is used within a particular component. They answer the question: Where is this value applied?
button-primary-background
button-primary-text
button-primary-radius
input-border-default
input-border-focus
| Level | Purpose | Example |
|---|---|---|
| Primitive | Stores raw values | blue-600 |
| Semantic | Defines meaning or role | action-primary |
| Component | Defines component usage | button-primary-background |
Aliasing means one token references another token instead of storing a separate raw value. This creates relationships between tokens and makes updates easier to manage.
button-primary-background
↓
action-primary
↓
blue-600
↓
#2563EB
Aliasing prevents unnecessary duplication. If multiple semantic or component tokens depend on a primitive value, changing the source can update the dependent values.
Good naming is one of the most important parts of a token system. Names should communicate meaning, follow a predictable structure, and remain useful as the product evolves.
category → role → variant → statecolor-text-primary
color-text-secondary
color-background-default
color-background-subtle
color-action-primary
color-action-primary-hover
spacing-component-gap
radius-card
button-primary-background-default
Token names should generally describe purpose rather than temporary visual appearance. Appearance-based names can become misleading after a rebrand or design change.
| Avoid | Prefer |
|---|---|
| blue-button | action-primary |
| gray-text | text-secondary |
| big-radius | radius-lg |
| new-blue | brand-primary |
Clear names are easier for global teams to understand. Avoid unnecessary abbreviations that may be interpreted differently by different people.
Preferred
background-primary
text-secondary
border-default
Avoid
bg-pri
txt-sec
bd-def
A token system should use a predictable naming convention. If one group uses text-primary while another uses primary-text, searching and understanding the system becomes more difficult.
Category
↓
Purpose
↓
Variant
↓
State
Example:
button-primary-background-hover
In Figma, design tokens can be implemented using variables. Variables store reusable values that can be applied to design properties and can also reference other variables through aliases.
Figma Variables
↓
Design Tokens
↓
Styles / Components
↓
Product Designs
Design tokens are a broader design-system concept, while Figma variables provide a native way to represent reusable values within Figma Design. Variables can therefore be used as the implementation mechanism for many token systems.
| Concept | Meaning |
|---|---|
| Design Token | Reusable named design decision |
| Figma Variable | Reusable value stored and managed in Figma |
| Alias | Reference from one variable to another |
| Mode | Alternative value for a variable in a specific context |
Variable collections provide a way to organize related variables. A collection can contain variables and modes for a specific category or purpose.
Collection: Colors
├── text-primary
├── text-secondary
├── background-primary
├── background-secondary
└── action-primary
Large systems should organize tokens logically so designers can quickly locate the values they need.
Design Tokens
├── Primitives
│ ├── Colors
│ ├── Spacing
│ ├── Typography
│ └── Radius
├── Semantic
│ ├── Text
│ ├── Background
│ ├── Border
│ └── Action
└── Components
├── Button
├── Input
└── Card
Modes allow a variable to have different values depending on context. They are particularly useful for themes and other contextual variations.
Token
↓
Light Mode → White
Dark Mode → Dark Gray
| Token | Light | Dark |
|---|---|---|
| background-primary | #FFFFFF | #111827 |
| text-primary | #111827 | #FFFFFF |
| border-default | #D1D5DB | #374151 |
| action-primary | #2563EB | #60A5FA |
Modes allow the same semantic token to represent different values in different contexts without changing the component structure.
Same Component
↓
Same Token Name
↓
Different Mode
↙ ↘
Light Dark
↓ ↓
Different Values
Depending on the design system, modes can also represent different contexts such as desktop, tablet, and mobile. For example, spacing or sizing values may change between screen sizes.
Spacing Token
↓
Desktop → 32px
Tablet → 24px
Mobile → 16px
Variables can be organized and scoped so that designers can find appropriate variables for specific properties more easily. Clear scoping helps prevent inappropriate token usage.
Components become more maintainable when their visual properties are connected to tokens instead of hardcoded values.
Design Token
↓
Component Property
↓
Component Variant
↓
Component Instance
↓
Product Screen
button-primary-background-default
button-primary-background-hover
button-primary-background-pressed
button-primary-background-disabled
button-primary-text-default
button-primary-border-default
input-background-default
input-border-default
input-border-hover
input-border-focus
input-border-error
input-text-primary
input-placeholder
input-disabled
card-background
card-border
card-radius
card-padding
card-shadow
card-title-color
card-description-color
Interactive components often require tokens for different states.
Default
↓
Hover
↓
Focus
↓
Pressed
↓
Disabled
↓
Loading
↓
Error
Tokens can help teams centralize accessibility-related values such as accessible color combinations, focus indicators, spacing, typography, and component states. The token system itself does not guarantee accessibility, so the resulting values and combinations still need to be evaluated.
Typography tokens can help establish a predictable hierarchy across headings, body text, labels, captions, and other content.
| Token | Example Value | Usage |
|---|---|---|
| font-size-xs | 12px | Small supporting text |
| font-size-sm | 14px | Labels |
| font-size-md | 16px | Body text |
| font-size-lg | 20px | Subheadings |
| font-size-xl | 32px | Large headings |
Spacing tokens create a consistent rhythm throughout the interface. Teams can establish a spacing scale and reuse it across layouts and components.
4px
8px
12px
16px
24px
32px
48px
64px
Grid-related decisions can also be represented systematically. Depending on the system, teams may define tokens or variables for gutters, columns, container widths, and responsive spacing.
Using standardized radius tokens prevents random corner values from appearing throughout the product.
radius-sm → 4px
radius-md → 8px
radius-lg → 12px
radius-xl → 16px
radius-full → 999px
Elevation tokens can establish a consistent relationship between surfaces and depth.
elevation-none
elevation-low
elevation-medium
elevation-high
Motion tokens can help standardize animation timing and easing so interactions feel consistent throughout a product.
duration-fast
duration-normal
duration-slow
easing-standard
easing-emphasized
One of the major advantages of tokens is that they can provide a shared vocabulary between design and development. A meaningful token name can represent the same design decision across design files and implementation.
Design
text-primary
↓
Token Definition
↓
Code
--color-text-primary
↓
Application UI
Designers may think in terms of styles and components, while developers may think in terms of variables and code. Tokens provide shared names that can connect these perspectives.
Meaningful token names can make developer handoff clearer because developers can understand the intended role of a value instead of receiving only raw measurements or color codes.
When tokenized design resources are inspected during handoff, meaningful variable or token information can provide more useful context than raw values alone.
Tokens make large-scale updates more manageable. A change to a source token can flow through connected aliases and components instead of requiring manual edits everywhere.
Change Source Token
↓
Update Aliased Tokens
↓
Update Components
↓
Update Screens
↓
Consistent Product Change
Suppose a company changes its primary brand color. If components use a shared semantic token, the team can update the underlying design value rather than manually changing every button, link, icon, and visual element.
Suppose a team changes its spacing scale. Tokenized spacing allows connected components and layouts to adopt the updated values more systematically.
Semantic tokens can remain stable while their underlying values change between light and dark modes.
background-primary
↓
Light Mode → #FFFFFF
Dark Mode → #111827
Token architecture can help organizations support multiple products or brands. Shared semantic structures can remain consistent while brand-specific values change where necessary.
A well-planned token system can help maintain consistency across web, mobile, desktop, and other product surfaces by giving different platforms a shared conceptual vocabulary.
As a product grows, the number of design decisions increases. Tokens provide a structured way to manage repeated values and relationships rather than allowing every screen to define its own values independently.
Consistency does not mean every interface must look identical. Tokens provide consistent foundations while allowing components and patterns to use those foundations appropriately.
A good token system should balance consistency with flexibility. Teams should provide enough tokens to solve real product requirements without creating thousands of unnecessary values.
Creating a token for every tiny visual difference can make a system difficult to manage. A new token should generally exist because it represents a meaningful and reusable design decision.
If two tokens always contain exactly the same value and have the same purpose, the system may be unnecessarily duplicating decisions. Review whether one token can serve both use cases.
A token such as blue may not communicate enough meaning. A more purposeful structure such as brand-primary or action-primary can be more useful depending on the architecture.
Creating tokens for every individual screen can lead to fragmentation.
Avoid:
homepage-blue
homepage-card-padding
checkout-blue
checkout-card-padding
Prefer:
brand-primary
card-padding
action-primary
Hardcoded values can create inconsistencies when repeated throughout the system. Frequently reused design decisions should be evaluated for tokenization.
Token governance defines how tokens are created, named, reviewed, changed, deprecated, and maintained.
Identify Need
↓
Define Token
↓
Choose Name
↓
Assign Value
↓
Review
↓
Publish
↓
Use
↓
Monitor
↓
Update / Deprecate
Before creating tokens, inspect the existing product and identify repeated colors, spacing values, typography values, radii, shadows, and other properties.
Existing Product
↓
Collect Values
↓
Find Repetition
↓
Find Inconsistency
↓
Define Token Opportunities
Group values into categories such as colors, typography, spacing, sizing, radius, shadows, and motion.
Create a foundational collection of raw values. Keep the structure predictable and avoid creating unnecessary values.
Map the foundational values to meaningful roles such as text, background, border, action, and feedback.
Create component-specific tokens when the complexity of the design system requires them. Smaller systems may not need this additional layer.
Use Figma variables to store reusable values and organize them into collections. Select an appropriate variable type such as color, number, string, or Boolean according to the property being represented.
Connect semantic or component variables to their appropriate foundational values through aliases. This creates relationships between tokens and supports centralized updates.
Semantic Token
action-primary
↓
Alias
↓
Primitive Token
blue-600
↓
Value
#2563EB
When the system needs multiple contextual values, create appropriate modes such as Light and Dark or other product-specific contexts.
Bind variables to component properties such as fills, strokes, spacing, dimensions, and other supported properties. This allows components to use the shared token system.
Test tokens across different components, screen sizes, themes, content lengths, and product scenarios before considering the architecture stable.
Documentation should explain token categories, naming conventions, intended usage, aliases, modes, examples, and contribution rules.
Design Tokens
├── Introduction
├── Naming
├── Colors
├── Typography
├── Spacing
├── Sizing
├── Radius
├── Shadows
├── Motion
├── Semantic Tokens
├── Component Tokens
├── Modes
├── Usage
└── Governance
| Token | Purpose | Example |
|---|---|---|
| text-primary | Main readable content | gray-900 |
| background-primary | Main surface | white |
| action-primary | Primary interactive action | blue-600 |
| spacing-md | Medium spacing | 16px |
| radius-md | Medium corner radius | 8px |
A name such as blue-button can become incorrect if the brand changes from blue to another color. Semantic naming such as action-primary can preserve meaning when the visual value changes.
Inconsistent:
text-primary
primary-background
border-default
defaultIcon
Consistent:
text-primary
background-primary
border-default
icon-default
Adding variables randomly can create a collection that becomes difficult to maintain. Establish categories, naming conventions, hierarchy, and ownership before expanding the system.
Not every one-off value needs to become a token. Tokenization is most useful when a value represents a reusable or important design decision.
Design tokens can be valuable because they connect design and code. Token names and structures should therefore be understandable to both designers and developers.
Create a token system for a fictional product such as an e-commerce website, SaaS dashboard, banking application, food delivery app, or mobile application.
Product: E-Commerce App
Primitive Tokens
├── blue-600
├── gray-900
├── gray-100
├── spacing-4
├── spacing-6
└── radius-md
Semantic Tokens
├── text-primary
├── text-secondary
├── background-primary
├── background-subtle
├── action-primary
└── border-default
Component Tokens
├── button-primary-background
├── button-primary-text
├── input-border-default
├── card-background
└── card-radius
Primitive
blue-600
↓
Semantic
action-primary
↓
Component
button-primary-background
↓
State
default / hover / pressed / disabled
↓
Button Component
Semantic Token
background-primary
↓
Light Mode → white
Dark Mode → gray-950
↓
Card
↓
Dashboard
↓
Product Interface
Primitive
spacing-4 → 16px
↓
Semantic
component-gap
↓
Component
card-gap
↓
Product Screen
Design principles explain why a system makes certain decisions, while tokens encode many of the reusable values that implement those decisions.
| Design System Layer | Purpose |
|---|---|
| Principles | Explain why the system makes decisions. |
| Tokens | Store reusable design values and decisions. |
| Foundations | Define core visual building blocks. |
| Components | Provide reusable interface elements. |
| Patterns | Solve recurring interface problems. |
| Templates | Combine patterns into reusable structures. |
Design Principle
↓
Token Architecture
↓
Variables
↓
Styles / Foundations
↓
Components
↓
Patterns
↓
Screens
↓
Product Experience
Variables and styles can work together in a Figma design system. Variables are particularly useful for reusable raw values and contextual modes, while styles can represent composite design properties such as grouped visual treatments.
Variables are especially useful for token systems because they can store reusable values, reference other variables, and support multiple modes. This makes them useful for themes and scalable design-system architectures.
Token variables can be published through Figma libraries so teams can reuse shared values across design files. A well-managed library helps establish a common source of truth.
When shared variables are updated, teams should review the impact of those changes before adopting them across product files. Communication and documentation are important for significant changes.
Sometimes a token should no longer be used. Instead of immediately deleting it, teams can mark it as deprecated, communicate the replacement, migrate usages, and remove it when it is no longer needed.
Old Token
↓
Mark Deprecated
↓
Choose Replacement
↓
Migrate Usage
↓
Test
↓
Remove Old Token
Large design systems may need versioning or release processes to manage significant token changes. Versioning can help teams understand which token definitions belong to a particular release.
Teams can evaluate how effectively tokens are being adopted by reviewing component usage, hardcoded values, library usage, token coverage, design consistency, and developer implementation.
Design Tokens are named and reusable values that represent design decisions such as colors, spacing, typography, sizing, radius, shadows, and motion.
They improve consistency, reduce duplication, support scalable design systems, simplify global changes, and create a shared language between design and development.
A raw value such as #2563EB describes only the value, while a token such as action-primary communicates the meaning and intended role of that value.
Primitive tokens represent foundational raw values such as color scales, spacing values, font sizes, and radius values.
Semantic tokens describe the role or purpose of a value, such as text-primary, background-primary, or action-primary.
Component tokens represent values associated with a specific component, such as button-primary-background or input-border-focus.
Token aliasing is the practice of allowing one token or variable to reference another token, creating a relationship between design values.
Semantic tokens can use different values in different modes. For example, background-primary can reference a light value in Light mode and a dark value in Dark mode.
Figma variables are reusable values that can be applied to supported design properties and can be organized into collections and modes. They provide a native mechanism for implementing many design-token workflows in Figma.
A good token name is meaningful, consistent, understandable, reusable, and preferably based on purpose or role rather than temporary visual appearance.
No. Tokenization should focus on values that represent meaningful, reusable, or important design decisions.
They provide meaningful names and shared values that can help developers understand and implement the intended design decisions consistently.
Audit Existing Design
↓
Identify Repeated Values
↓
Group Values
↓
Define Primitive Tokens
↓
Define Semantic Tokens
↓
Define Component Tokens
↓
Create Naming Convention
↓
Create Figma Variables
↓
Create Aliases
↓
Create Modes
↓
Apply to Components
↓
Test
↓
Document
↓
Publish
↓
Adopt
↓
Monitor
↓
Improve
| Practice | Recommendation |
|---|---|
| Naming | Use meaningful and consistent names. |
| Architecture | Use a hierarchy appropriate to system complexity. |
| Primitive Values | Keep foundational values organized. |
| Semantic Values | Use meaningful roles for reusable UI decisions. |
| Aliasing | Use references where relationships improve maintainability. |
| Modes | Use modes for meaningful contextual variations. |
| Components | Connect component properties to reusable values. |
| Documentation | Explain naming, usage, and architecture. |
| Governance | Review, maintain, and communicate important changes. |
| Scalability | Design the structure for future growth. |
Design Tokens provide a structured way to manage the reusable values that make up a design system. Instead of allowing colors, spacing, typography, radius, shadows, and other values to become scattered throughout individual screens, tokens give teams a shared and maintainable system of design decisions.
In Figma, variables can be used to create token-based workflows with collections, aliases, and modes. A well-planned token architecture can support everything from a small design project to a large multi-product design system.
The most effective token systems are not simply large collections of variables. They are carefully organized systems with meaningful names, clear relationships, appropriate levels of abstraction, controlled flexibility, documentation, and governance.
For practical learning of Figma, design systems, design tokens, variables, components, prototyping, and professional UI/UX workflows, explore JustAcademy Figma Training and Register for Figma Course Demo.
