Methodology for storing design decisions as platform-agnostic data variables.
Design tokens are the single source of truth for your design system. Instead of hardcoding hex values or pixel sizes, you use tokens (like `color-primary` or `spacing-md`). This allows you to update the entire system across multiple platforms (Web, iOS, Android) by changing a single value.
Change the primitive values to see how they cascade through semantic aliases to update the UI components.
brand-500
space-base
radius-md
The raw values. E.g., `blue-500: #0066CC`. These are the building blocks of your palette.
Tokens with meaning. E.g., `color-action-primary: blue-500`. Describes *what* the color is for.
Specific to a component. E.g., `button-bg-primary: color-action-primary`. Allows granular control.
The final output format. CSS variables for web, XML for Android, JSON for iOS.
Understanding the distinction between these two layers is key to a flexible system.
Raw values that represent the available choices in your system. They have no inherent meaning.
blue-500: #2C6CB2
space-16: 16px
Aliases that describe the intended use of a token. They reference primitive tokens.
color-action-primary: {blue-500}
space-inset-md: {space-16}
A consistent naming scheme is critical for a scalable system. We recommend a structure that moves from general to specific.
color, font, space).text, bg, border).primary, success, card).hover, active, disabled).color-bg-button-primary-hover
space-inset-card-lg
font-size-heading-xl
Aliasing allows you to change values in one place and have them propagate. Choosing the right depth of aliasing balances flexibility with complexity.
Semantic tokens point directly to primitive values. Simple and easy to maintain, but less flexible for complex theming.
Component tokens point to semantic tokens, which point to primitives. Allows changing a component without affecting other elements using the same semantic color.
Tokens change value based on context (e.g., light/dark mode). Semantic tokens point to a theme-specific primitive.
While tokens are defined once, they must be transformed to match the syntax conventions of each platform.
Design tokens make theming effortless. By swapping the values of your semantic tokens, you can completely change the look of your application without touching the markup.
The most common theme. Simply redefine your semantic color tokens (e.g., bg-default) for a dark context.
Support multiple sub-brands by swapping out brand-specific primitive tokens (e.g., brand-primary).
Adjust spacing and sizing tokens to create "Compact" or "Comfortable" density modes for different user needs.
:root {
--bg-default: #ffffff;
--text-primary: #111827;
}
[data-theme="dark"] {
--bg-default: #111827;
--text-primary: #ffffff;
}
A powerful Figma plugin that allows you to create, manage, and sync design tokens directly within your design files.
An Amazon-built build system that allows you to define styles once and use them for any platform or language.
A design system platform that automates the handoff of design tokens and assets from Figma to code.
Automate the transformation and distribution of tokens whenever changes are pushed to your repository.
Treat your design tokens as a product. Use semantic versioning to communicate changes and ensure stability for consumers.
Breaking changes. Renaming tokens, removing tokens, or significantly changing a core value that affects layout.
New features. Adding new tokens (e.g., a new color ramp or spacing value) in a backward-compatible way.
Bug fixes. Tweaking a hex value to fix contrast or adjusting a border radius slightly.
color-primary
→ Active
color-brand-primary
→ Introduced (alias old token)
color-primary
→ Removed
Tokens are only useful if people know how to use them. Good documentation includes not just the value, but the *intent* behind the token.
#475467
Used for secondary text, captions, and helper text that needs to recede from the primary content.
A clear governance model ensures your token system remains clean and scalable over time. Without it, you risk token bloat and inconsistency.
Design Systems team owns the core tokens (primitives & semantics). Product teams can suggest changes but shouldn't modify them directly.
Establish a process for requesting new tokens. Is it a one-off need or a recurring pattern? If recurring, it might deserve a token.
All token changes must go through a design and code review to ensure they follow naming conventions and don't duplicate existing values.
Design tokens are stored as data (usually JSON) and transformed into platform-specific files. This automation ensures all platforms stay in sync.
Establish a strict naming structure (e.g., Category-Type-Item-State) like `color-text-primary-hover`.
Use tools like Figma Tokens (Tokens Studio) or Style Dictionary to manage and transform tokens.
Ensure design tokens in Figma are automatically synced with the code repository.