Built for Whoever Builds Next

Where things stood

The old system had stopped being maintained long before anyone said so out loud. It didn't announce itself — it showed up as friction. Every new feature became a decision about whether to use what existed or build around it, and around it kept winning.

By then the system needed to serve more than one team. Multiple apps built on top of it, each with its own pace and its own reasons to skip it.

What I worked on

Two-tier tokens: primitives hold values, semantic tokens hold intent. A token that says destructive and irreversible survives a rebrand, a theme, and a designer who wasn't in the room. One that says red-600 survives nothing.

That structure paid off almost immediately. The platform had only ever shipped in dark mode, and introducing light theming meant every semantic token needed a second value without anyone touching where it was used. A token that says surface-primary or text-secondary doesn't know which theme is active — it just resolves differently underneath. Every component built on it inherited light mode for free. Nothing needed a rework, because nothing had hardcoded an answer to a question the token was supposed to own.

Interactive elements needed the same separation between structure and color, so I built a recipe system on top of the tokens. A recipe like Solid defines a component's states — background, text, hover, focus ring — as a mapping to palette slots, not to specific colors. Define the recipe once, then run any palette through it: Neutral, Brand, Success, Danger, Info, Warning, Orange, and Purple all come out correct without a single one being designed by hand. It's a pattern that translates cleanly into code, too — a recipe is a style function, and a palette is just the argument you pass it.

Governance had to match that intent. Anyone could propose a change — deliberately, since a system only a small group can touch calcifies fast. But nothing shipped without design and engineering reviewing it together, and nothing waited for a release window. Approved changes landed continuously.

I also spent real time on how the system meets AI. We structured Figma so generation produces accurate code without Code Connect — naming, layer structure, and token application readable as intent rather than decoration.

Designing for a third contributor

The system now has three kinds of contributors: designers, engineers, and models generating from it directly. The first two get a design review. The third doesn't ask permission before producing something — it just produces, and what it produces is only as correct as the intent it can actually read off the system.

That's the real argument for two-tier tokens, beyond maintainability. A model generating a delete confirmation doesn't need to be told the button is destructive — it inherits that from the token, the same way a new designer would if the naming did its job. Semantic naming stopped being documentation for humans and started being the interface a model reads before it writes anything.

It also meant testing the system against actual generation instead of assuming it would hold up. Before finalizing conventions, we ran components and tokens through AI-assisted generation and checked the output against what the system intended — closer to an audit than a demo.

Governance covers this too. A model can draft a component variant as easily as a person can sketch one, but it still needs design and engineering to agree before anything ships. AI didn't get a shortcut into the system — it got the same door everyone else uses.

What changed

The clearest proof is the review model itself: nothing waits for a quarterly release anymore. That tells you what the system used to cost in time — a backlog nobody could estimate — and what it costs now.

Anyone can start a change. Nobody ships one alone. And it holds whether the first draft of that change came from a person or a model — the tokens don't know the difference, which is exactly the point.

Adoption tracks it too. Seven front-end engineers found their way through the system on their own, without a shepherding process — the two-tier structure was legible enough to self-serve. Designers grew with it in a different way: working inside a token system this detailed, built around intent rather than raw values, changed how they approached a component from the first decision, not just at handoff.

What carries over

Systems don't fail because they were built badly. They fail because nobody owned them after launch. The build is the cheap part.

Encode intent, not appearance. Every token, every component, every review gate should answer why this decision, not just what it looks like. Appearance changes. Intent is what you're maintaining — and it's what makes the system legible to a new designer, a new engineer, or a model.