The governance document is seventeen pages. It has a table of contents, a glossary, and a section on exception handling. It was written during the engagement, reviewed by the client's design lead, signed off by the product team. Nobody on the current team has read it. Three of them don't know it exists.
The design tokens have been exported. There's a Figma file with 847 components. The handoff meeting happened. Someone took notes.
Six months later, the token for the secondary action color got changed in Figma and never propagated. A component got rebuilt from scratch because the team didn't know it already existed. A designer made a call that didn't match the system because the meeting to update it kept getting cancelled. Nobody did this deliberately. The system just isn't built to hold.
A design system can exist, fully built, with components and tokens and documentation, and still fail to hold. It fails to hold when there's no clear owner for the decisions it creates. When the update process requires heroism instead of routine. When engineers have learned to build around it because going through it is slower. When the system was designed for the product as it existed at handoff, not the product as it will exist in six months.
The question most teams bring to a design system build is whether it exists. Infrastructure answers a different question: not whether something exists, but whether it holds. Most design systems are built to answer the first one.
Components are the visible part: they're in Figma, they have names, and you can count them, screenshot them, put them in a slide deck for a leadership review.
But a component library without a governance model is a reference document, not infrastructure. It tells a team what exists. It doesn't tell the team what decisions to make when something new is needed, who holds the authority to make those decisions, or what happens when a decision made in Figma doesn't map cleanly to what the codebase can render.
Token architecture is where this becomes most concrete. A token named blue-500 is a value: it describes what color to render. A token named color-action-primary is a decision: it tells the system and everyone building with it what role that color plays. One of those tokens can be maintained. One of them is a number that will need to be changed everywhere the moment the product's primary action color shifts, and there's no structural way to do that consistently.
Good token architecture encodes intent, not appearance. It describes what things are for, not what they look like. That distinction sounds small until the first rebrand, at which point it's the difference between a two-week project and a six-month one. I've been inside both timelines. In the six-month version, the tokens were never asked to encode intent.
Token architecture built with intent doesn't just survive a rebrand. It becomes usable infrastructure for what's being built on top of the system now: documentation tools that can read and describe it, validation layers that check whether generated output matches the design language, interface tooling that treats the design system as a live constraint rather than a static reference. A token structure that's just a named list of values has to be translated at every handoff, and translation is where intent gets lost.
Governance is the word that makes design system maintenance sound like paperwork. Most governance documents describe what should happen, then get filed next to the component library in the same Confluence space that nobody checks.
Real governance is a set of answers to questions the system will definitely face. Who decides when a new component gets added? Who decides when a token changes? When there's a conflict between what design specified and what engineering shipped, who resolves it, and how? When a product team needs an exception, what's the threshold for turning that exception into a standard?
These questions happen in every design system within six months of handoff. The organizations that built governance answered them before they happened. The ones that didn't ended up setting them through escalations, undocumented workarounds, and exceptions that gradually became the de facto standard.
The team that built the system knew this would happen, though not always. Some genuinely believed the governance document would be enough. But most people who do design system work have seen this before. They've watched the token drift, the component rebuild, the governance page go unread. They built it anyway, because the engagement ended at handoff, and "ensure this holds for eighteen months" wasn't in the scope.
Getting it right means working relationships and a clear line between who proposes and who decides. A token change requires a person with both the design knowledge to judge it and the organizational authority to commit it. A component addition requires a review that asks not just "does this work?" but "does this belong in the system, and what does adding it say about the decisions we've made?" Those processes aren't complicated. They need to be designed, and they need to have names on them.
Governance that lives only in the system builder's head is its own failure mode. When the person who built the system also holds all the decisions about it, every update runs through a single bottleneck. When that person moves on, the system starts making its own decisions, which means no one is actually making them.
There's a person whose job includes knowing whether the system is drifting. Not as a monitoring function, but as a design function: noticing the exceptions that are accumulating, identifying the decisions that need to be made explicit, knowing when the system needs to evolve versus when the team needs to hold the line.
Staying in the system has to be faster than working around it. This is the test most design systems fail: when a team reaches for a workaround, it's not usually because they don't care about the system. It's because working within it takes longer than working around it, and they have a deadline. If the system creates more friction than it removes, it won't hold.
The token structure communicates intent to every consumer: designers, engineers, and the systems generating output from it. The decisions about hierarchy, role, and meaning are embedded in the architecture, not in a separate document that requires translation.
And the documentation describes the system as it is, not as it was designed to be. Updated the day a decision changes, not during the quarterly audit that keeps getting postponed.
None of this requires a large team. A design system with four hundred components doesn't inherently require more governance than one with forty. The complexity scales with decisions, not components, and each of those decisions needs someone with authority to make it.
Before any components are scoped or tokens are structured, the question worth asking yourself is: what are we actually building?
Are we building documentation of the design language, or are we building infrastructure for how design decisions get made and maintained over time? Both are real work, and only one of them holds.
Does this hold? It's the question worth bringing to every design system engagement, every governance review, every conversation about whether the team needs a new component or a decision about the existing ones. The seventeen-page document doesn't answer it. The 847 components don't answer it. The handoff meeting didn't answer it.
The question is answered by what was designed to happen after the meeting ended.
I started HeyHi because the question kept outrunning any single engagement: not just how to build a design system that holds, but how to build one that's actually useful for what gets built on top of it. The organizations that got this right had something in common: not a bigger team, but someone who owned the gap continuously and understood that the work wasn't finished when the system shipped.
Cody Clark is the founder of HeyHi. heyhi.design
More essays, twice a month.
Subscribe on Substack to get each piece when it comes out.
Keep reading
Living with a design system that keeps drifting? See how the Design Intelligence Audit works.