When designers and developers start talking about design tokens, everyone else tends to tune out. A shame, because the idea is simple. A design token is a design decision with a name. Instead of “#3A2BFF” you say “the colour for the primary action”. That name makes the decision reusable, explainable and checkable.
Why a name matters so much
A hex code says nothing about why it is there. If a marketer, developer or AI tool only gets colour values, everyone has to guess which colour is meant for what. You know the result: three slightly different purples on one website, and a button that suddenly appears in the accent colour.
A token records the intent. When the brand colour changes, you update one value and every application follows. More importantly, everyone speaks the same language, from designer to developer.
Core values and roles
Good token sets have at least two layers.
Core tokens
The base values of your brand: the colours in your palette, the typefaces, a spacing scale, animation durations. They describe what is available, for example color.iris or space.4.
Semantic tokens
Roles that point to those base values: action.primary, text.secondary, surface.inverse. They describe what a value is for. In everyday work you mostly use this layer. It means you can later decide the primary action gets a different colour, without hunting down every single button.
Larger systems sometimes add a third layer of component tokens, such as the background of one specific button. Only start on that when you really need it. Every extra layer is extra maintenance too.
The DTCG format
The Design Tokens Community Group works on a shared exchange format for tokens. On 28 October 2025, version 2025.10 was published as a stable specification. It is a report from a W3C Community Group, not a formal W3C standard, but it gives tools and teams a common foundation. A small set of tokens looks like this:
{
"color": {
"volt": {
"$type": "color",
"$value": {
"colorSpace": "srgb",
"components": [0.227, 0.169, 1],
"hex": "#3A2BFF"
},
"$description": "Brand colour volt."
}
},
"action": {
"primary": {
"$type": "color",
"$value": "{color.volt}",
"$description": "The next step. One per view."
}
},
"space": {
"4": {
"$type": "dimension",
"$value": { "value": 16, "unit": "px" },
"$description": "Base distance inside components."
}
}
}A few things stand out. Every token has a $type and a $value, and optionally a $description. A semantic token refers to another token using curly braces, such as {color.volt}. And the description is plain language, so people and agents alike understand what the token is for.
Take care when moving tokens between tools. Not every program fully supports all of 2025.10 yet. An export button does not prove nothing gets lost, so check the result.
What is in it for a marketer?
More than you might think. Tokens are the reason a template, a web page and a generated LinkedIn image use the same colours and proportions. When your Figma library, Canva Brand Kit, templates and website are fed from the same source, you no longer have to check whether everyone uses the right green.
Tokens help with briefings too. When you ask an agency for a campaign, you do not hand over loose colour codes but a file with roles and descriptions. The agency sees right away which colour is for actions, which for backgrounds and which only as an accent. That saves correction rounds and discussion afterwards.
And for a developer?
Tokens are transformed into CSS variables, themes or platform-specific formats. You build components on roles instead of fixed values. That makes a dark mode, a sub-brand or a rebrand manageable. Coding agents benefit in the same way: an instruction like “always use action.primary for the main button” is unambiguous.
Pitfalls
- Too many tokens. If nobody knows which one to pick, you are helping nobody.
- Names based on looks instead of function. blue-button is outdated after the first brand change.
- No descriptions. Without an explanation it stays a list of numbers.
- No owner. Tokens without governance drift apart quickly.
Tokens are not a goal in themselves. They make sure good design decisions survive outside the designer’s head.
We do the same on this website. Every colour, size and animation duration comes from one token file, which drives both the styling of the site and the documentation on our design systems page.
