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.
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.
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 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.
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.



