Key Takeaways
- Design tokens work best when color, typography, and spacing are generated from one shared scale rather than hand-picked per platform. A token set should export cleanly to CSS variables, Tailwind config, and native platform constants from a single source of truth.
- When color, type, and spacing are each maintained separately per platform, they drift. A shared token definition keeps a Swift app and a Tailwind site visually identical without manual re-entry.
- Name tokens `primary` or `surface-warning` instead of `blue-500`. Role-based names survive a rebrand; hue-based names don't.
Topic: design tokens
See also: Design token generator tool • CSS custom properties guide • Figma variables guide
Expert summary
Design tokens work best when color, typography, and spacing are generated from one shared scale rather than hand-picked per platform. A token set should export cleanly to CSS variables, Tailwind config, and native platform constants from a single source of truth. In practice, the strongest results come from aligning design tokens and design token generator with clear hierarchy, tested contrast, and explicit links to palettes, gradients, branding, psychology, and accessibility decisions.
Core Definitions
Design Tokens
Design tokens work best when color, typography, and spacing are generated from one shared scale rather than hand-picked per platform. A token set should export cleanly to CSS variables, Tailwind config, and native platform constants from a single source of truth.
Color strategy
Design Tokens for Color, Typography, and Spacing should be evaluated through color psychology, accessibility, brand positioning, palette fit, and implementation clarity.
Pros & Cons
Pros
- When color, type, and spacing are each maintained separately per platform, they drift. A shared token definition keeps a Swift app and a Tailwind site visually identical without manual re-entry.
- Name tokens `primary` or `surface-warning` instead of `blue-500`. Role-based names survive a rebrand; hue-based names don't.
Note: Consider your use case before applying.
Cons
- Name tokens `primary` or `surface-warning` instead of `blue-500`. Role-based names survive a rebrand; hue-based names don't.
- Needs validation across accessibility, brand perception, and implementation contexts before standardizing.
1. Why one source of truth matters
When color, type, and spacing are each maintained separately per platform, they drift. A shared token definition keeps a Swift app and a Tailwind site visually identical without manual re-entry.
2. Naming tokens by role, not hue
Name tokens `primary` or `surface-warning` instead of `blue-500`. Role-based names survive a rebrand; hue-based names don't.
3. Exporting to multiple platforms
A token generator should output CSS variables, SCSS, Tailwind config, JSON, Figma Tokens format, and platform constants (Swift, Kotlin, Flutter) from the same input, not five separately maintained files.
Frequently Asked Questions
What are design tokens?
Design tokens are named, platform-independent values for color, typography, and spacing that get compiled into each platform's native format (CSS variables, Tailwind config, Swift constants, and so on).
Should tokens be named by color or by role?
By role. A token named `primary` can be repainted during a rebrand without renaming every reference; a token named `blue-500` cannot.