I’m in the middle of a design tokens project and I thought I’d share something I’m learning that is probably obvious to everyone else; every design token is a feature.

A token is a magical contract between design and engineering, if we agree to use the same name to abstractly refer to the same value, it will produce a desired outcome. That bridge alone is probably worth the investment, but tokens solve even more organizational problems. The mobile app and the website can look the same by sharing a single JSON file. But wait, there’s more! If the blue a different team chose is not blue enough for you, you can make your own blue and apply it at the global scope or the individual element scope. Tokens as an organizational feature are a powerful concept but there’s tons of nuance packed behind it.

Like features, too many tokens can bloat your system. I recently learned –because I’m lucky to work with people who work on browsers– there’s a not-so-theoretical limit where the browser starts taking a performance hit based purely on the number of CSS variables. There’s no hard upper limit on the number of variables (we drew a line at ~500) because the limit ultimately depends on the size and the depth of your DOM. Style recalcs and tree walking are expensive problems for a browser. Alias tokens like --foo: var(--bar) compound the problem and the more static you can be, like --foo: #bada55, the better. Infinite customizability and peak performance are often at odds.

Like features, too many tokens can create organizational problems! This is the opposite of what I said above, how can that be? It’s possible to generate enough tokens that they become their own hyperobject, impossible to comprehend from the outside, so well-meaning people eject from the system. Detached instances. One-offs. Snowflakes.

Like features, tokens can create little piles of technical debt. “Is anyone still using --color-beefcake-primary-2?” you shout into the void of the team chat. No one responds because no one knows. The person who does know left the company five months ago. Alas, we’ll bolt on more until we find time to fix it. Always adding. Never subtracting.

Like features, some tokens are going to have a massive payoff if implemented and some tokens the user benefit is less clear. You’re passing organizational complexity on to the user. Like features, you can build over-complicated machinery around a simple concept like sharing values. Like features, people will build every part without considering whether they actually need each facet.

Generally speaking, if someone wants to implement hundreds or thousands of little features in an application, that’s probably a red flag. If-statements are expensive over their lifetime. But from my experience, a good system of tokens inside a cascade of meaningful componentry can make a product resonate with consistency across many surfaces, while providing just enough customizability to differentiate when necessary.