Work
Exact
Design systems specialist 2025–26

Design tokens the whole team can see.

Exact's product suite ran on hardcoded styles and per-component props, with the decisions that should anchor it scattered out of sight. I future-proofed it on design tokens: one architecture, synced to Figma variables and the repo, the first components moved onto it, and a live site where the whole team could see and use every mode and theme.

Design tokens Theming Token site
Exact design tokens
Token architecture Colour, type, spacing, breakpoints, with theming as modes.
Figma + code Synced both ways: Figma variables and the repo.
First components Moved onto the tokens, props turned into modes.
Token site A live explorer of every mode and theme, for the whole team.

The problem

A suite built on values, not decisions

Exact's product suite ran on hardcoded values and per-component props. Light and dark were props bolted onto each component, spacing and colour were repeated by hand, and the decisions that should anchor the whole thing had no single home. It worked, but it could not scale, and theming meant touching everything.

And the tokens that did exist were invisible: buried in code, where only developers ever saw them. The people making design decisions could not see the system they were deciding on.

NO SHARED SOURCE Component A #0a5 · 16px · light/dark props Component B #0a6 · 15px · light/dark props Component C #0b4 · 16px · its own values Tokens in code design can't see them no link
NO SHARED SOURCE Component A #0a5 · 16px · light/dark props Component B #0a6 · 15px · light/dark props Component C #0b4 · 16px · its own values no link Tokens in code design can't see them

Every component its own source of truth, light and dark as props, and the real tokens hidden in code where design never saw them.

My role

What I owned

I led the token implementation end to end. I created the token architecture, a clear hierarchy for colour, type, spacing and breakpoints, with light and dark handled as modes rather than props. I set up the two-way sync so the same tokens flowed to the repo for development and to Figma variables for design, then moved the first set of components onto them and deployed the token site for the team.

One thing behind the scenes: applying the semantic tokens across components by hand would have taken weeks, so I adapted an open MCP-and-Figma-plugin setup into a tool that did the application for me. A personal accelerator for my own work, not part of the system I delivered.

The approach

Tokens are decisions, so put them where decisions are made

A token is not a value, it is a decision: this colour, here, for this reason. So the work started by naming those decisions into a hierarchy, then turning light and dark from per-component props into modes the whole system shares. One change to a mode, not a hunt through every component.

Then sync, both directions. The same tokens resolve to the repo for development and to Figma variables for design, so the two sides stop drifting and start sharing one source. What a designer picks is what a developer ships.

And the part most token work skips: visibility. I deployed a site where anyone on the team can browse every token in every mode and theme, live. Tokens that only developers can see do not get used. Put them on a screen everyone shares and they become the system, not the plumbing.

ONE SOURCE, SEEN BY EVERYONE Tokens one source Figma variables Code / repo Components Token site all modes
ONE SOURCE, SEEN BY EVERYONE Tokens one source Figma vars Code / repo Components Token site all modes

One token source flows to Figma variables and code, onto the components, and out to a live site where the whole team sees every mode and theme.

The outcome

Tokens with a home, and an audience

The engagement delivered what the plan set out: a token architecture synced both ways to Figma variables and the repo, the first set of components moved onto the tokens, and a deployed token site where the whole team can see and use every mode and theme. The suite finally has decisions in one place instead of values in a thousand.

The token site is the part I am happiest with. Tokens stop being something only developers ever encounter and become something the whole team reaches for, which is the difference between a token file and a token system.

Craft proof The token site with its mode and theme switches, the Figma variables, and the first components on tokens. Real screenshots to come.

Questions

What was delivered?

A design-token architecture synced both ways to Figma variables and the repo, the first set of components moved onto the tokens, and a deployed token site where the whole team can see and use every mode and theme. This matched the plan of approach.

Why put the tokens on a website?

Tokens usually live in a repo where only developers ever see them. A deployed explorer lets the whole team, design, development and beyond, browse every token in every mode and theme, so the tokens actually get used and trusted.

How did you apply tokens across components so quickly?

I adapted an open MCP-and-Figma-plugin setup into a tool that applied the semantic tokens for me, turning weeks of manual work into an automated pass. It was a personal accelerator for my own work, not part of the delivered system.

Tokens nobody can see don't get used.

That's the work I do. Let's talk.

Get in touch