Systems
Design tokens are an operations problem, not a CSS problem
Teams rarely fail at token syntax. They fail at naming, ownership and the quiet drift that starts the week after launch.
Feb 24, 2026 · 6 min read · By Tomas Berg
Key takeaways
- Decide who owns tokens before you build them.
- Name for intent, not appearance.
- Measure drift, or the system dies quietly.
The failure mode nobody plans for
Token projects start with enthusiasm and end with a spreadsheet. Six months later two products use different names for the same value, and dark mode is an audit finding.
Naming is the decision
Appearance names (`blue-500`) age badly; intent names (`action-primary`) survive redesigns. The argument about naming is the actual design work – have it once, with everyone in the room.
“Decide who owns tokens before you build them.”
Ownership and release cadence
A token set needs a maintainer, a version number and a changelog – the same discipline as an API. Without a release cadence, token changes happen in pull requests nobody reviews.
Drift reports beat dashboards
A monthly report of raw values found in code, mapped against the token set, tells you more than a coverage dashboard. Drift is the metric that predicts whether the system is alive.
A practical checklist
- Name one owner for the token set
- Replace appearance names with intent names
- Version tokens like an API
- Ship a monthly drift report
- Review drift with product and marketing leads
Tomas Berg
About the author
Design director
Treats systems as an operations problem: naming sessions, version numbers, drift reports. Designs in the open with weekly walkthroughs so the first review is never the first look.
Profile
Next step
Put this into practice
If a note maps to a problem you are facing, send it to us as a question.