Design tokens explained: turn your brand into data

Design tokens are the individual visual decisions that make up a brand — one colour, one font size, one spacing step, one corner radius — stored as named, structured data instead of being drawn into a design file or a PDF. Rather than writing #FF450B in fifty different places, you define a token called colour.brand.primary once, and every button, link and heading points at it. Change the token and everything that uses it changes with it. That is the whole idea: brand as data, not brand as a picture.

This post explains what tokens are, shows a concrete example, contrasts tokens with the traditional brand guidelines PDF, and describes how capturing a brand as tokens plus rules keeps every client’s work consistent — and lets components (and AI) build on-brand by default.

What are design tokens?

A design token is the smallest reusable unit of a design decision, given a name and a value. Think of it like a variable in a document instead of a number typed everywhere. space.md = 16px is a token. radius.card = 16px is a token. colour.text.body = #242424 is a token.

Individually they look trivial. The power is in what happens when everything downstream refers to the name rather than the value:

• A designer picks “brand primary” from a palette — they are choosing a token, not remembering a hex code.
• A component’s stylesheet reads colour.brand.primary — it never hard-codes the red.
• A rebrand becomes an edit to a handful of values, not a search-and-replace across an entire codebase.

Tokens are usually organised into a few clear categories. Here is a typical map:

Category	What it holds	Example token → value
Colour	brand, surface, text and state colours	colour.brand.primary → #FF450B
Typography	font families, sizes, weights, line height	font.display → Inter 800
Spacing	the spacing scale used for margins and padding	space.md → 16px
Radius	how much corners are rounded	radius.card → 16px
Elevation	shadows and layering	shadow.card → 0 14px 28px …

What does a design token look like?

Because tokens are just data, they are usually written in a machine-readable format such as JSON. A tiny slice of a token file might read:

{
  "colour": {
    "brand": {
      "primary": { "value": "#FF450B" },
      "ink":     { "value": "#242424" },
      "surface": { "value": "#F5F5F5" }
    }
  },
  "space": {
    "sm": { "value": "8px" },
    "md": { "value": "16px" },
    "lg": { "value": "24px" }
  },
  "radius": {
    "control": { "value": "10px" },
    "card":    { "value": "16px" }
  }
}

That is the entire trick. It is boring on purpose. Because the file is structured and named, a stylesheet, a design tool, a build script and an AI assistant can all read the same source of truth. Nobody has to eyeball a swatch and hope they picked the right red.

Tokens are also human-readable. A person opening that file can see the brand’s decisions at a glance, and a rule sitting next to the tokens can say, in plain language, “primary actions use colour.brand.primary with white text.” The values feed the machines; the names and rules keep humans oriented.

Why not just a brand guidelines PDF?

A brand PDF is a description of your rules. Design tokens are the rules in a form software can actually execute. That difference is the whole argument, and it shows up in five practical ways:

	Brand PDF	Design tokens
Format	A picture of the rules	The rules as data
Read by	People, occasionally	Code, tools and AI, every build
Applied	Copied by hand	Consumed automatically
Kept in sync	Manually, if ever	One edit updates everything
Drift over time	Inevitable	Structurally prevented

The failure mode of a PDF is familiar to every agency. The guidelines say the red is #FF450B. Six months and three freelancers later, the live site has four slightly different reds, because nobody reads a PDF at build time and a hex code copied by hand is a hex code that will eventually be copied wrong.

Tokens remove the copying step entirely. The button does not know the brand red — it reads colour.brand.primary. There is no second place for the value to live and slowly disagree with the first.

How do tokens keep every client consistent?

For an agency, the interesting question is not one brand but many. This is where the model earns its keep.

sSystm’s Design System module captures a client’s brand as exactly this: structured design tokens — colour, type, spacing, radius — plus rules, both human- and machine-readable. Crucially, there is one design system per client. Each client gets its own set of tokens; the tooling around those tokens never changes. The type and the shape differ from client to client — one brand is a sharp serif with tight corners, another a rounded grotesk with full pills — but the machinery that reads and applies the tokens is identical every time.

The consistency comes from a simple rule: components and wireframes style themselves from whichever client’s tokens are active. You do not restyle a button for each brand. The button reads the tokens; swap the active client and the same button is now correctly on-brand for the new one. Everything stays consistent by default, because “on-brand” is a property of the data, not something a person has to remember to apply.

That is a meaningfully different promise from “here are the guidelines, please follow them.” With tokens, following the brand is the path of least resistance rather than an act of discipline.

Tokens plus rules: the brand as executable data

Tokens on their own capture the values. Rules capture the relationships — the dos and don’ts that a hex code alone cannot express. Kept next to the tokens and written to be read by both people and machines, a rule set might say:

• Primary actions use colour.brand.primary with white text.
• Body copy stays on surface, with a minimum contrast of AA.
• Never place muted text on the secondary surface.
• No gradients on interactive surfaces.

Because those rules live as data beside the tokens — not as a paragraph in a PDF nobody opens — they can be checked, applied and honoured automatically. The brand stops being a document you consult and becomes a specification the work is built against.

How AI builds on-brand from tokens

The token model matters more, not less, once AI enters the workspace. An AI assistant asked to build an interface will produce something — but without the brand as an input, it is guessing at your colours and spacing. Feed it structured tokens and rules and the brand becomes something the model can read and honour, not a picture it cannot see.

This is the same principle behind AI that builds without locking you in: the assistant works from your data — your tokens, your rules, your workspace — rather than from assumptions baked into someone else’s tool. On-brand output becomes the default because the brand is a genuine input, expressed in a form the machine can consume.

Where the Design System module fits

A design system is one module in a larger picture. sSystm is an all-in-one agency operating system — CRM, projects, billing, documents — where you switch on only the modules you need. The Design System is a premium module for agencies that manage multiple brands and want each one captured once, as data, and applied everywhere without drift.

If your brand currently lives in a PDF, a shared drive and the collective memory of whoever has been around longest, the move to tokens is the move from hoping things stay consistent to knowing they do. Turn the brand into data, and consistency stops being a chore and becomes the default.

Explore the Design System module to see how a brand is captured as tokens, rules and per-client systems — or browse the full module catalogue to see where it sits in the wider agency OS.