A token migration that turns scattered values into product decisions.
Migrating tokens is worthwhile when the model changes along with the names. Rename alone and you get a more organised kind of ambiguity.
Start with meaning
The old system may have hundreds of colour, spacing, and typography values. The migration decides which of them are primitive, which are semantic, and which are one-off exceptions on their way out.
A sensible sequence
Keep the migration tied to actual product work, so the new language proves itself under use.
- Inventory the existing values and identify high-frequency decisions
- Define foundations and semantic aliases
- Migrate one active product area end-to-end
- Use the result to adjust naming and scale before broader rollout
What success looks like
A designer can choose a token because they understand the role it plays. An engineer reaches for the same role straight from the code. Changing a product decision has a predictable effect. That is the point.
Make the next part of the product easier to build.
Bring the thing your team is repeatedly working around. We will work out whether a system intervention is the right move.
Let's chat ↗