If you're building a design system at any scale, you need design tokens. Not want — need. Here's my complete guide based on building token systems at three different companies.

**What are design tokens, really?**

Design tokens are named entities that store visual design attributes. They're the bridge between design decisions and code implementation. Instead of hardcoding `#1A1917` everywhere, you store it as `color.brand.primary` and reference that everywhere.

**The naming convention problem**

Most teams use naming conventions that break. Here's mine: `{category}.{property}.{variant}.{state}`. So: `color.text.secondary.hover`. It reads clearly, it scales, and it handles all the edge cases.

**The three tiers**

Global tokens → Semantic tokens → Component tokens. Most teams only implement global tokens and wonder why their system breaks. You need all three tiers.

**Dark mode is about semantic tokens**

Your light mode and dark mode aren't different colour palettes. They're different mappings of semantic tokens to global tokens. `color.surface.primary` maps to `gray.50` in light mode and `gray.950` in dark mode. That's it.

**Multi-brand theming**

Same principle, one level up. You have global tokens (shared across all brands), semantic tokens (where brand differences live), and component tokens (specific overrides). Build this from day one.

The tools for this have never been better — Figma Tokens plugin, Style Dictionary, and Tokens Studio make the implementation mostly painless. The hard part is governance.