A design token is a product decision with a name attached.
Without an owner, it becomes a prettier hardcoded value. The name looks systematic for a while, then nobody can explain what it means, who may change it, or why two nearly identical tokens exist.
Role names age better than mood names. surface, surface-muted, border-subtle, text-muted, accent, and danger describe use. They survive a theme change better than names that only make sense while one person remembers the original palette.
Ownership is more than approving a hex value. The owner decides whether a token should exist, whether it belongs globally or beside one component, whether an existing token already covers the case, and how usage moves when the name changes. Sometimes the right answer is a local value for a one-off experiment rather than another global token.
Migration is part of the contract:
old token: --color-muted-border
new token: --border-subtle
plan:
keep old token as an alias for one release
update remaining consumers
remove alias when usage reaches zero
Changing a token changes screens. Review should show the affected surfaces, contrast impact, dark-mode behavior, focus states, usage counts, and migration notes. A raw token diff is not enough.
Exceptions are healthy when they stay close to their component:
.profile {
--profile-orbit-blue: rgba(59, 130, 246, 0.42);
--profile-orbit-amber: rgba(249, 115, 22, 0.36);
}
That signals that the values belong to the profile treatment rather than starting a new global color family.
AI-generated UI raises the same issue. A model can copy a token name while missing its meaning. Review has to inspect the resulting surfaces, not only whether the code compiles.
Unused aliases, stale names, and duplicate values make the system harder to reason about. Fewer tokens with clear ownership are more useful than a large catalog nobody trusts.
Somebody needs to protect the language. The title can be designer, engineer, or design-system lead. The responsibility is the same: keep the named decisions coherent enough that the product can change without forgetting what its values mean.
Related posts

About Jeremy London
Engineering leader and builder in Denver. I write about AI platforms, agents, security, reliability, homelab infrastructure, and the parts of engineering work that have to survive production.