A design token system, built to keep design and engineering aligned as Blocto’s team grew.
Blocto’s product lines kept expanding and the engineering team grew fast. The more people shipping, the harder it got to keep everything consistent. In Q4 2022 we began rolling out design tokens, and from the start we treated it as ongoing maintenance, not a project with an end date.
Groundwork
Defining tokens is easy. Making them stick is the work.
Prep started back in Q3. I read through how other teams had rolled out their own systems, then went back and forth with our engineering lead for weeks, all around one question: how do we make this hold up in every project, instead of living in a spec no one opens?
The Challenge
The hard part was never the tokens. It was getting two teams to change how they work.
On the engineering side, that meant selling the idea first, agreeing on shared rules, then working out how new projects would adopt tokens while the older ones kept running untouched.
On the design side, every designer had their own projects and their own habits. We had to settle on one workflow so our design files mapped cleanly onto the tokens. Without that, engineering had nothing clean to pick up.
The System
One system, two layers.
Global tokens hold the raw values. Aliases on top carry the meaning, so a designer picks “primary,” not a hex code.
01
Colors
A full scale for every hue, 50 through 900 at the global layer. The alias layer on top assigns the roles: primary, secondary, error.
02
Typography
Sizes, line heights, and weights as raw tokens. Then aliases, heading, body, button label, that say what each style is actually for.
03
Dimension & Shadow
Spacing, icon sizes, radius, and border width. Plus two shadow sets, one tuned for app and one for web.
Takeaways
Two things stay with me.