Tokens are a contract, not a colour palette
What changed the engineers’ minds at SPH Media, and three rules for anyone starting a token system.
When I introduced tokens at SPH Media, the first reaction from a few engineers was polite scepticism. They had seen design systems before: a Figma file with pretty swatches, a component library nobody updated, and six months later the same conversation about which blue is the right blue.
The thing that changed their minds wasn’t the swatches. It was the agreement.
A token is a named decision that both sides promise to honour. color.action.primary doesn’t say what colour it is. It says what it’s for. Design owns the value, engineering owns the implementation, and neither side has to ask the other before using it. That is a contract, and like any contract it only works if both parties sign.
At SPH that mattered because we had ten to twelve publications in market with their own habits. We couldn’t stop the presses to restyle them. Tokens let us introduce a shared language underneath the existing products and migrate screen by screen, so a change made once could flow everywhere without a redesign project.
Three things I’d tell anyone starting this
Name for intent, not appearance. blue-500 tells you nothing when the brand changes. surface.raised survives a rebrand.
Start with the tokens that end arguments. Spacing, type scale, interactive colours. The decorative layer can wait.
Ship them in code first. A token that exists only in Figma is a suggestion. The day it compiles, it becomes a rule.
Keep reading
More from the same notebook.
Which workflow is costing you the most right now?
Onboarding that leaks customers. An operations queue that still runs on phone calls. A design team that needs a lead. Tell me which one, and I’ll bring design, AI and twelve years of taking flows like that end to end.
Thirty minutes to start. You describe the product and what is slowing it down. I tell you honestly whether I’m the right person for it, and if not, who might be.