Design Tokens
Design tokens are the visual design atoms of our design system — named entities that store visual design attributes. Instead of hard-coding values like hex codes or pixel counts directly into components, we reference tokens by name. That name maps to a value that can change based on theme, platform, or brand without touching the component itself.
Why use tokens?
- Consistency — A single source of truth for colors, spacing, typography, and more across every surface.
- Theming — Swap token sets (e.g. light/dark, brand A/B) without changing component code.
- Maintainability — Update a token once and the change propagates everywhere it is used.
- Design–dev alignment — Figma variables and code variables share the same names and values.
Naming conventions
Tokens use a path-like name: category/subcategory/value (e.g. color/primary/500, spacing/md).
- Category — the domain:
color,spacing,typography, etc. - Subcategory — the role or scale:
primary,secondary,sm,md,lg. - Value — the specific step or variant:
500,600,none,full.
Best practices
- Prefer semantic tokens (e.g.
color/action/primary) over raw primitives in components when the meaning is "action primary," not "blue-500." - Don't introduce new one-off tokens for a single component — reuse existing ones, or add a shared token if the need is system-wide.
- Keep token names aligned with Figma variable names so design and code stay in sync.
Token reference pages
Browse tokens by category:
- Color — Semantic color tokens, brand palette, and primitive color swatches
- Typography — Type scale, line heights, letter spacing, and font families
- Spacing — Base scale, padding, gap, layout heights, and screen sizes
- Elevation — Shadow tokens for depth and layering
- Motion — Animation and transition tokens
- Component — Component-scoped tokens and platform-specific values
Using tokens
- Using tokens in code — CSS variables, JS/TS imports, and do/don't examples
- Using tokens in design — Working with Figma variables and keeping design and code in sync