A design token is a named design decision: not a hex code but "brand", not "16px" but "space-4". It sounds like a small change of vocabulary. In practice it is what lets one design system serve light and dark themes, several brands and several platforms without every screen being redrawn by hand.
Why tokens matter now
Products rarely live in one place any more. The same interface runs on the web, on iOS and Android, in dark mode and light, sometimes under more than one brand. Hard-coded values multiply with every one of those combinations. Tokens let you change a decision once and have it flow everywhere it is used.
Design and code, in sync
Design tools have embraced the idea — Figma's variables, for example, bring named, themeable values into the design file — and the W3C Design Tokens Community Group has been standardising a common format so tokens can move between tools without bespoke converters. The goal is a single source of truth that both designers and engineers read from, with automation keeping the two in step.
Structure the decisions
- Base tokens hold raw values: the full colour palette, the spacing scale.
- Semantic tokens say what a value is for: "surface", "text-muted", "border-strong".
- Components use semantic tokens only, so a theme is just a different mapping of meanings to values.
Govern them like an API
Tokens are a contract between design and engineering. Version them, document what each one is for, deprecate before you delete, and add automated checks — such as contrast tests on every text and background pair — so a well-meaning change can't quietly break accessibility.
Our Design Systems practice builds token-driven libraries in design and code, and our UI/UX Design and Web Design & Development teams use them every day.