Design Tokens Are Not a Nice-to-Have
Tokens are the difference between a design system that scales and one that fragments. Here is how to build them right.
Design tokens are the atomic values of your design system — colors, spacing, typography, radii, shadows, motion. They are not a "nice-to-have" documentation exercise. They are the single source of truth that prevents your system from fragmenting as it scales.
Why Systems Fragment Without Tokens
Without tokens, every developer makes local decisions. One uses #333 for text, another uses rgb(51,51,51), a third uses a CSS variable they defined themselves. Multiply this by 200 components and you have a system that looks like a system but behaves like chaos.
The Token Architecture We Use at ALO
At ALO, tokens live in a single TypeScript file (styles/tokens.ts) with const assertions. Every component imports from this file — never hardcodes. When we change the accent color from #C9A227 to something else (we will not, but hypothetically), one edit propagates everywhere. That is the power of tokens.
- Color tokens: background, surface, accent, text, border, and diagnostic colors
- Typography tokens: font families, sizes (using clamp), weights
- Spacing tokens: section padding, container width, component gaps
- Motion tokens: easing curves, durations, variant definitions
- Radius tokens: from 6px buttons to 9999px pills
A design system without tokens is a suggestion. A design system with tokens is a contract.