Design Tokens Are an Org Chart Problem

We get called into a lot of design system rescues, and there is a pattern so reliable I can predict it from the kickoff call. The team will show us their design tokens: hundreds of them, carefully structured, synced from Figma to code through a pipeline someone was very proud of in the launch blog post. And then they will describe the actual problem: designers do not trust the tokens, engineers override them, and the system produces consistency in the documentation and chaos in the product.

The diagnosis is almost never technical. Token tooling in 2024 is good. Figma variables matured, the syncing infrastructure works, the W3C community group is slowly blessing a standard format. The diagnosis is organizational: tokens are a decision-making structure wearing a naming convention, and most teams built the naming convention without building the decision-making.

What a token actually is

Strip the tooling away. A design token is a promise: "this decision has been made once, and you may rely on it." color-text-secondary is not a hex value, it is a commitment that somebody owns the question of what secondary text looks like, everywhere, forever, and that changing it is that person's job, not a free-for-all.

Seen this way, the failure modes explain themselves. When a designer creates color-text-secondary-alt-2, the token system has not failed technically. Someone needed a decision, could not find who makes it, and self-served. Multiply by fifty screens and two years and you get the archaeology we are usually hired to excavate: layers of tokens recording every moment nobody was in charge.

The three-layer contract

The structure we install is standard, but the point of it is not the structure, it is who holds the pen at each layer:

• Primitives: the raw palette, the type scale, the spacing ramp. Owned by brand and the system team. Changes are rare and versioned like breaking API changes, because they are.
• Semantic tokens: intent-level decisions like surface-raised or text-danger. Owned by the design system team, with a real intake process. This is the layer where ninety percent of daily design decisions should resolve.
• Component tokens: scoped exceptions where a component genuinely needs its own decision. Owned by whoever owns the component, inside boundaries the system team sets.

Every token names its owner. Every layer names its change process. When a product designer hits a case the semantic layer does not cover, there is a person to ask and a service-level expectation for the answer. That intake conversation, not the sync pipeline, is the actual design system.

The audit that tells the truth

If you want to know whether your token system works, do not count tokens. Run two queries. First: what percentage of color and spacing values in the shipped product resolve to a token? Second, and more revealing: how many tokens were created in the last quarter, and can anyone explain each one's reason for existing in a sentence? A healthy system has boring answers. Token creation should feel slightly bureaucratic. If minting a new token is easier than finding the right existing one, your search and documentation have failed, and the token count will grow until the system means nothing.

One heuristic we hold with clients: every token added is a decision the whole organization must now carry. The best design systems we have built shrank during the engagement.

Tools keep improving, and this year's crop is genuinely good. But no pipeline has ever answered the question "who decides?" Answer that on the org chart first. The tokens are just where the answer gets written down.