Design tokens, explained for the people who sign off the budget.
Tokens sound like a developer’s concern. They are really the cheapest insurance a brand can buy. Here is what they are, what they cost and how to start.
Every brand has a blue. Very few brands have one blue. Ask your website, your app, your sales deck and your packaging which blue they use and you will usually get four different answers.
That drift is not carelessness. It happens because the brand lives in a PDF while the work lives in a dozen tools, each with its own copy of the colours, fonts and spacing. Every copy is a chance to be slightly wrong. Design tokens remove the copies.
What a design token is
A design token is a named decision. Instead of writing a colour value into a stylesheet, a slide template and a print file, you write it once, give it a name such as brand-primary, and let every tool read that name. Change the decision in one place and every product that reads it changes too.
Tokens are usually stored as a simple data file that design software, code and content tools can all understand. The format matters less than the habit: one source of truth, read by everything.
Three layers, three jobs
- Core tokens hold the raw values: every colour, size and duration the brand allows.
- Semantic tokens give those values a purpose: text-primary, surface-raised, focus-ring.
- Component tokens apply purposes to parts: button-background, card-border, input-error.
The middle layer is where the value sits. When a product team asks for the colour of a warning message, nobody should have to remember a hex code. They ask for the warning token and get the right answer in light mode, dark mode and print.
Why a budget holder should care
Tokens are rarely sold well because they are sold as engineering. The real return shows up in places a finance team already measures.
- Rebrands and refreshes cost a fraction of what they did, because values change in one file.
- Dark mode, accessibility fixes and new markets become updates, not projects.
- Agencies and freelancers work from the same values as your own teams from day one.
- Design and engineering argue less, because the decision is written down and versioned.
A token is a brand decision that no one has to remember.
How to start without a big programme
The most common mistake is to treat tokens as a migration that must be finished before anyone benefits. It works far better as a series of small, useful steps.
- Audit: collect every colour, font size and spacing value in use across your three busiest products.
- Reduce: merge the near-duplicates. Most brands can lose half their colours without anyone noticing.
- Name: agree semantic names with design and engineering in the same room, in one afternoon.
- Connect: wire the token file into your design tool and one live product first.
- Grow: add each new product or template as it is touched, never all at once.
Within a quarter you will have a working system in the places that matter most. Within a year the rest of the estate will have joined, mostly through work that was happening anyway.
Naming is the hard part
Most token programmes that stall do so over names. Names that describe the value, such as blue-500, break the moment the brand moves to green. Names that describe the purpose, such as action-primary, survive any change of value. Write the purpose, not the paint.
Keep the vocabulary small and boring. If two people need a meeting to decide which token to use, you have too many. A good test is whether a new designer can pick the right token from its name alone, without opening the documentation.
Who owns the tokens
Tokens need a single owner, usually a small brand systems team that sits between design and engineering. Their job is not to approve every change but to keep the vocabulary clean, publish updates on a predictable rhythm and say no to one-off values that would weaken the whole.
Treat the token file like any other product: version it, write release notes and tell people what changed. A change that arrives with a short note is adopted. A change that arrives silently is resented, and quietly overridden.
Three mistakes to avoid
- Copying every existing value into tokens unchanged, which preserves the mess in a tidier file.
- Letting each product team invent its own semantic names, which recreates the drift tokens were meant to end.
- Treating the first release as finished; a token set that never changes is soon ignored.
Signs it is working
- New screens arrive in review already on brand, without a designer correcting colours by hand.
- A colour change requested on Monday is live across products by Friday.
- Accessibility contrast checks pass by default, because the tokens were built to pass.
- Nobody asks which blue to use any more.
None of this is visible to customers, and that is fine. What they see is a brand that looks like itself everywhere, which is the whole point of having one.
