The organization was a market leader. Had been for years. International presence, long institutional history, multiple divisions — some of them acquired, some of them grown from within, all of them generating revenue in enough quantity to have opinions about how the company should be run.
Then the market shifted. New entrants arrived. Startups that took the complicated processes the organization had built over decades and made them frictionless. The kind of competition that does not beat you on features. It beats you on ease. And the organization, whose competitive advantage had always been scale and reputation, suddenly found that both of those things were slower than the market needed them to be.
Leadership decided to transition to design thinking. An agency was brought in. Twelve months. Training for every division. A shared language, a shared methodology, the beginning of a shared design system. Everyone in the room. Everyone aligned. The agency was very good at their job.
Each division built their own version. Not in defiance of the shared system — in the absence of any structure that made the shared system worth maintaining. The division with the highest revenue moved fastest. They had the leverage to make their own decisions and they used it. The other divisions watched and concluded, correctly, that the shared system was aspirational rather than operational. Within eighteen months the organization had more design systems than it had divisions.
This is not a story about a design system failing. It is a story about governance that was never built — only borrowed from an agency for twelve months and returned when the engagement ended.
Why Drift Accelerates
Design drift is not a design problem. It is a governance problem that expresses itself through design.
It begins with an exception. One component extended beyond its original scope because the deadline was real and the governance process was slow. One token overridden because a stakeholder had a strong preference and the cost of the argument was higher than the cost of the exception. One division building a parallel pattern because the shared system did not cover their use case and nobody was responsible for covering it.
None of these decisions feel significant in the moment. Each one is defensible. Each one is made by a rational person under real constraints. The drift is not the result of carelessness. It is the result of a governance structure that makes the exception cheaper than the standard.
When the exception is cheaper than the standard — everyone takes the exception. This is not a culture problem. It is an architecture problem.
A design system without governance is not a system. It is a suggestion with a Figma file attached.
Figma libraries are not a governance layer. They are a distribution layer. A designer can detach a component in Figma in three seconds. The library has no mechanism to make detachment expensive. It can record the detachment — Figma Analytics will show you the detach rate — but recording drift is not the same as preventing it. The governance layer has to sit somewhere that makes the drift structurally costly, not just visible.
The Dependency Architecture
The strongest governance mechanism in design systems is one that most governance conversations never reach. It is not a policy. It is not a review process. It is not a contribution model or a deprecation framework or a committee with decision rights.
It is a production dependency.
When the design system's primitives — the tokens, the base components, the spacing and typography scales — are published as versioned packages and consumed by product teams as production dependencies, forking the system is no longer a design decision. It is a technical one. A product team that wants to override a token is not opening a Figma file and changing a color. They are modifying a package they did not write, forking a dependency chain they have to maintain, and accepting the cost of staying out of sync with every future update the design system ships.
Drift becomes expensive before it becomes visible. That is the only version of governance that holds when the external authority leaves and the highest-revenue division starts pulling in its own direction.
This is dependency governance. Primitives published to a package registry — npm for web teams, equivalent registries for other stacks — free infrastructure already in use by most engineering organizations. The design system becomes a versioned dependency in the product team's package.json. Updates are opt-in but visible. Forks are possible but expensive. The governance mechanism is not a rule. It is an architecture that makes the standard path cheaper than the exception.
The version history lives in GitHub. Every change to the primitive layer is a commit. Every product team consuming the package can see what changed, when it changed, and what upgrading or forking would cost them. The transparency is structural. Nobody has to enforce it. The architecture enforces it.
Policy stops drift until someone with enough leverage ignores it. Architecture stops drift until someone with enough budget rebuilds it. One of those is significantly more expensive to override.
Three Rules for Governance That Holds
Rule 1 — Make Primitives Production Dependencies
Publish your token layer and your base component primitives as versioned packages. Not as a Figma library. Not as a documentation site. As actual packages that product teams import into their codebase.
This is not an advanced infrastructure decision. It is the baseline for any design system that intends to govern rather than suggest. npm handles this for web teams — free, standard, already in use by every engineering team consuming any external library. A private package registry for organizations that need internal-only distribution. GitHub Packages as the zero-configuration option for teams already on GitHub. The package exists. The version history exists. The cost of diverging from it is now a technical conversation, not a design one.
The moment the design system is a dependency — it has leverage. Not political leverage. Technical leverage. The kind that does not require a committee to enforce.
Rule 2 — Audit the Exceptions
Every exception to the design system is a governance signal. A component extended beyond scope. A token overridden for a stakeholder preference. A division building a parallel pattern. Each exception should be recorded, reviewed, and classified: is this a product team workaround, or is this a design system gap?
A workaround is a governance failure. A gap is a roadmap item. The distinction matters because the response is different — a workaround needs a governance conversation, a gap needs a design system update. Without the audit, every exception looks the same and gets ignored the same way. Track exceptions in Notion for teams that need something lightweight — free tier covers everything an exception log requires. Confluence for organizations already in the Atlassian stack. The format is secondary. The discipline of recording every exception before it becomes a pattern is primary.
Rule 3 — Define What Governance Survives
The governance structure that depends on a specific person, an external agency, or a leadership mandate is not a governance structure. It is a temporary condition. The test of a governance model is what happens when the person leaves, the agency finishes the engagement, or the mandate loses its political support.
Built governance into the architecture before the external authority leaves. The dependency layer. The exception audit. The version history. These mechanisms do not require a committee. They do not require a mandate. They require an engineering decision to publish the system as a package and a discipline decision to record every exception. Both of those decisions can be made before the agency books their flights home.
The organization I described did not fail because the agency was bad at governance. They failed because the governance they built was not transferable. When the agency left, there was nothing for the divisions to inherit. Only a methodology and a certificate.
The Quick Win: Classify Your Last Five Exceptions
This week: identify the last five times a product team deviated from the design system. For each one, answer two questions.
Was this a workaround — the system had the answer and the team chose not to use it? Or was this a gap — the system did not have the answer and the team had no choice but to build their own?
If all five were workarounds — you have a governance problem. If all five were gaps — you have a roadmap problem. If the answer is a mix — you have both, which is the most common answer and the one nobody wants to write down.
Write it down anyway. The exception log is the most honest document a design system team can produce. It is also the one most likely to never be created — because it makes visible the gap between what the system claims to cover and what it actually covers. That gap is not a failure. It is the roadmap.
The Argument
Design drift is not stopped by better documentation, stronger culture, or more frequent reviews. It is stopped by making the standard path cheaper than the exception — architecturally, not politically. A governance structure that requires a person, an agency, or a mandate to hold it together is not governance. It is temporary alignment. Build the dependency layer before the alignment disappears. Because the alignment always disappears. The architecture does not have to.
Disagree loudly. Inspire boldly.
And remind me — falsely if needed — that somewhere a design system governance model survived the departure of the agency that built it.
Before you go, entertain this for a second
If the person most responsible for your design system's governance left tomorrow — what would the system inherit? And what would disappear with them?
