← Writing

Design System Governance: Choosing the Right Model

Originally published on Substack

August 1, 2026 · 8 min read

Every design system starts the same way: a handful of people notice the same problem everywhere — inconsistent components, duplicated patterns, engineers and designers quietly reinventing the same button for the fifth time — and they decide to fix it. They build the case, win over skeptical stakeholders, and ship a system. It's a genuine win.

Then, a year or two later, the same inconsistencies start creeping back in. Not because the system failed, but because nobody decided who was responsible for keeping it alive. As designer Heldiney Pereira put it in his Schema by Figma talk on the topic, once a design system exists, the answer you usually get when you ask who owns it is "everybody" — it's a shared asset. A shared asset with no clear owner, though, is much harder to evolve than one with a designated, even imperfect, owner.

This is what governance actually is: not a bureaucratic layer on top of the design system, but the answer to "who decides, and how, when something needs to change?" Every design system already has a governance model, whether or not anyone chose it on purpose. The goal isn't to find the one correct model — there isn't one — it's to pick deliberately, based on your team's size, maturity, and resourcing, and then build a contribution process that matches it.

The models, reconciled

Design systems writing tends to circulate around three models popularized by Nathan Curtis — centralized ("overlord"), federated, and hybrid — sometimes with a fourth, standalone, added for teams that haven't consolidated at all. Pereira's talk uses different labels — overlord, centralized, federator, and decentralized — and it's easy to assume these are two competing frameworks. They're not; they're the same underlying spectrum, described with slightly different cut points.

The practical takeaway: "federated" and "hybrid" are often the same idea wearing two names. Pereira's federator model — splitting ownership by product or component domain — is essentially what most teams mean when they say "hybrid": a center that sets direction, with distributed people doing the work closest to their own product context. Where his framing adds something useful is the decentralized end of the spectrum, which industry writing usually treats as a pre-system state ("standalone") rather than a deliberate governance choice for a system that already exists. Pereira's version says: yes, you can run a mature system this way — but only if you invest heavily in onboarding and shared conventions, because there's no safety net.

Comparing the models side by side

Naming them is the easy part. The harder question is what each model actually costs and buys you day to day. Here's the same five models compared across the dimensions that matter most in practice:

No row in this table has a "winning" model — it's a set of trade-offs you're choosing on purpose, or inheriting by accident.

From idea to system: the contribution workflow

Choosing a governance model is only half the job. The other half is the actual mechanism by which a new component or pattern moves from "someone's idea" to "part of the system everyone can rely on." Here's a workflow that works well across most of the models above, adapted from common design-system practice:

1. Identify a component or pattern that doesn't currently exist in the system. This usually surfaces from real product work — a designer or engineer hits a gap the system doesn't cover.

2. Research it and document its proposed use. Look at how similar problems are solved elsewhere in the product (and outside it), define the use case clearly, and write down what the component needs to do and where it's needed.

3. Build it using the existing technology and framework. The prototype should use the system's actual design tokens, components, and code conventions — not a one-off built in isolation — so it's a real candidate, not a mockup.

4. Use it and test with users. Ship it in the context it was built for and validate that it actually solves the problem, with real usage and real feedback, before anyone else is asked to adopt it.

5. Propose it for experimental use — available for other teams to consume, but explicitly not yet an officially approved part of the system. This lets it get real-world mileage without prematurely locking in a design that hasn't been stress-tested.

6. A design system orchestration group reviews the proposed experimental component and pressure-tests it against how it's actually being used across the teams that picked it up experimentally.

7. After testing for accessibility compliance, usability, visual coherence, code scalability, and similar criteria, it gets approved and formally incorporated into the design system — at which point it moves from "experimental" to a supported, documented, versioned part of the system others can depend on.

This pipeline has a useful property: the risky, uncertain part (steps 1–5) happens close to a real product need, with real usage as the validation — not a committee's best guess. The centralized, higher-scrutiny part (steps 6–7) only kicks in once there's something worth formally adopting. That ordering matters, because it means governance overhead is spent on things that have already proven useful, not on every idea someone floats.

How this workflow shifts under each governance model

The steps stay roughly the same across models — what changes is who does steps 6 and 7, and how much friction exists getting there.

• Overlord: Steps 1–5 look identical. Step 6 is just the one owner reviewing it personally, whenever they have time — which is both the fastest and the most fragile version of this process, since there's no "orchestration group," just one person's judgment and availability.

• Centralized: The core team is the orchestration group. This is usually the cleanest version of steps 6–7, since there's a standing team with the accessibility, usability, and code-scalability expertise already in place, and an established cadence for reviewing proposals.

• Federator / hybrid: Step 6 gets more interesting — the "orchestration group" is often a cross-functional council with representatives from each domain that owns a slice of the system, rather than one central team. This is closer to what many orgs mean by a design system's "core team" plus "guild": domain owners bring proposals from their area, and the group collectively pressure-tests for cross-domain consistency before anything gets promoted out of experimental status.

• Decentralized: Steps 1–5 happen the same way, but step 6 requires the most explicit tooling and documentation to work at all — automated accessibility and token-compliance checks often substitute for a human review group, because there may not be one standing body with the authority (or bandwidth) to pressure-test every proposal manually.

The practical implication: if you're building this contribution pipeline from scratch, the pipeline itself doesn't need to change much as your governance model evolves — but the step 6 review body is exactly where you should point your governance decision. Deciding "who sits in the room for step 6, and how much authority they have" is, in effect, deciding your governance model.

Design system drift — and how AI accelerates it

"Drift" is what happens when the product stops matching the system, even though nobody consciously decided to break the rules. A button gets a one-off padding tweak to fit a tight layout. A color gets hardcoded because the right token wasn't obvious. Multiply that by dozens of teams and a few years, and the system on paper and the system in production quietly stop being the same thing. This has always been a governance problem — it's exactly what steps 6 and 7 of the contribution pipeline exist to catch before drift gets baked in as "the new normal."

Two forces are making drift both more common and harder to catch: AI-assisted coding, and multi-framework product estates.

AI amplifies drift because it's very good at imitation, not connection

AI coding assistants are excellent at producing a component that looks like it belongs in your design system — matching spacing, colors, and typography closely enough to pass a casual glance — without actually being wired to the system at all. Instead of importing the real Button component and consuming its tokens, an AI assistant asked to "build a button like the ones in this app" will often infer the visual properties from surrounding code or screenshots and regenerate them as hardcoded values or a new, parallel component. The result looks right today and is structurally disconnected from tomorrow: when the system's token values change, this component doesn't update, because it was never actually plugged in.

This is a different failure mode from a designer knowingly cutting a corner under deadline pressure. It's drift that's generated at scale, quickly, by default, often without anyone realizing a "new" component was created rather than the existing one reused — because the output is visually convincing enough to pass a quick review. A single engineer manually copy-pasting styles is a known, containable risk; AI tooling that does this instinctively across many teams and PRs simultaneously is a multiplier on that same risk, and it can outpace the cadence at which a step-6 review body is used to catching problems.

Multiple frameworks turn "one system" into several similar-looking systems

The same dynamic shows up when a design system has to be implemented across React, Angular, Vue, and Tailwind-based codebases at once. Each framework has its own component model and its own idioms for consuming design tokens — a token distributed cleanly to a React component library doesn't automatically stay in sync with an Angular implementation maintained by a different team on a different release cycle. Tailwind is a particularly easy place for this to happen invisibly: because utility classes make it trivial to recreate "system-looking" spacing, color, and typography using arbitrary values or a locally configured theme, a component can be visually indistinguishable from the real system component while having zero actual connection to its tokens. It looks compliant. It isn't.

The practical effect is the same as the AI problem: components that resemble the system without being derived from the system, so a single source-of-truth token change doesn't propagate everywhere it should, and nobody notices until a visual audit turns up inconsistencies that have been accumulating for months.

Why this is a governance question, not just a tooling one

Both of these drift sources exploit the same gap: a review process built around "does this look right" rather than "is this actually connected to the system." That gap is exactly what governance model you're running determines how well you can close:

• Overlord and centralized models are somewhat protected by default, since one person or team reviewing everything is more likely to notice a component that isn't actually importing from the system — but only if that reviewer is explicitly checking for connection, not just visual similarity.

• Federator/hybrid models are more exposed, because domain-specific review may not catch a Tailwind or AI-generated component that looks fine locally but was never built against shared tokens — cross-domain, framework-level compliance needs its own explicit check, not just the domain owner's sign-off.

• Decentralized models are the most exposed of all, since there's no standing review body positioned to catch this at every point of entry — which means automated tooling isn't optional here, it's the only realistic defense.

The concrete mitigations worth building into step 7 of the contribution pipeline, regardless of model: distribute tokens in a platform-agnostic format (tools like Style Dictionary exist for exactly this) so React, Angular, and Tailwind configs all pull from the same source rather than each maintaining their own copy; add automated visual-regression and token-usage linting that flags hardcoded values instead of token references; and, for AI-assisted code specifically, treat "imports and uses the real system component" as a hard pass/fail check rather than relying on a visual read of the output. A component that looks identical to the system but doesn't consume it isn't a contribution to the system — it's drift wearing the system's clothes.

What this means for designers

If you're a designer working in a system someone else governs, the model in place determines how fast you can get a component approved, and who you need to convince. Under an overlord model, that's usually one or two named people — fast if they're available, dead in the water if they're not. Under centralized governance, there's a clear intake process, but expect a queue. Under federated/federator models, figure out who owns the specific area you're touching — a shared button component and a product-specific pattern may have entirely different owners. Under decentralized governance, the responsibility shifts to you: you're expected to know the conventions well enough to extend the system correctly without asking permission, which only works if onboarding was actually good.

The practical move: before proposing a new component or pattern, find out explicitly which model you're operating under, and where in the seven-step pipeline above your organization actually starts requiring sign-off. Don't assume "shared asset" means "anyone's call" — Pereira's point is that this ambiguity is exactly where systems quietly decay.

What this means for product managers

PMs often experience governance model choice as a roadmap and velocity question, even when it's framed as a design or engineering concern. A centralized model gives predictable quality but can become a dependency your team has to wait on — worth factoring into estimates the same way you'd factor in a shared platform team's backlog. A federated/hybrid model can move faster locally, but only if someone senior enough has actually protected the ~25% of time embedded contributors need for system work; if that time isn't protected on paper, it won't happen in practice, and the system will silently drift out of sync with your product.

The experimental-use step (step 5 above) is particularly useful for PMs to understand: it means your team can often start using a promising new pattern before it's officially approved, which unblocks a roadmap item without waiting for a full governance cycle — as long as everyone's clear that "experimental" isn't the same guarantee as "approved."

If you're sponsoring a design system initiative, the most useful question to ask isn't "which model is best" — it's "who is explicitly accountable for this, and have we given them the time to do it?" An unowned system isn't free; it's a cost that shows up later as inconsistency, rework, and slower onboarding for new hires.

What this means for engineers

Engineers usually feel governance most acutely at the boundary between Figma and code: who decides when a component's API changes, who reviews a pull request against the system's design tokens, and who owns deprecating an old pattern. Centralized and overlord models tend to keep design and code tightly coupled to a small group, which is good for consistency but can create a release bottleneck if that group isn't resourced for both design and engineering review. Federated models distribute this, but require genuinely clear documentation of which team owns which part of the codebase — otherwise you get duplicate implementations of the "same" component built by different squads who didn't know who to ask.

Step 3 (build using existing technology and framework) and step 7 (code scalability testing) are where engineering involvement is non-negotiable regardless of governance model — a component that only passes design review but wasn't built against the system's actual token and component architecture isn't really a system candidate yet, just a well-designed one-off.

If your organization is decentralized, the engineering equivalent of "strong onboarding" is a well-maintained contribution guide, linting/tooling that enforces token usage automatically, and a lightweight review process — because there's no central gatekeeper catching drift before it ships.

Choosing a model deliberately

A few questions worth asking as a team, regardless of role:

• How many people are actively maintaining the system today, and is that number a deliberate choice or an accident of who happened to be around when it was built?

• If the current maintainer(s) left tomorrow, would the system survive? If not, you're running an overlord model whether you meant to or not.

• Is ownership split anywhere — and if so, is it split cleanly (by product, by component domain), or is it just informal and undocumented?

• Do the people expected to contribute have the time explicitly protected, or is system work something they do "when they get a chance"?

• Would a new hire know who to ask, or what the conventions are, without tribal knowledge?

• Does your contribution pipeline have a real step 6 — a body with the authority and expertise to pressure-test proposals — or does everything get approved (or ignored) informally?

• If someone — or an AI assistant — built a component that looks like it belongs in your system but doesn't actually import from it, would anything catch that before it ships?

None of the models are inherently right or wrong. An early-stage system with three designers is probably fine as an overlord model — trying to federate it prematurely just adds coordination overhead nobody needs yet. A system serving hundreds of contributors across many product lines almost certainly needs federated or hybrid governance, because a single team or person genuinely can't keep up — as Curtis put it, overlords don't scale. What actually damages systems isn't the choice of model — it's not choosing one at all, and letting "everybody owns it" stand in for an actual answer.

The point Pereira closes on is the most useful: having a design system doesn't mean you have good governance, any more than shipping a product means you have good UX. If you haven't consciously decided how your system is governed, you already have a model — it's just not necessarily the right one for where you are. The work that matters most now isn't building the system; it's deciding, on purpose, who keeps it alive, and building a contribution path that reflects that decision.

Sources

All links below were checked and confirmed working as of this writing.

• Heldiney Pereira, "The Governance of Design Systems", Schema by Figma, 2021. Source for the overlord / centralized / federator / decentralized framing, the "hero's journey" narrative, and the "shared asset" ownership problem.

• Nathan Curtis, "Team Models for Scaling a Design System", EightShapes / Medium, September 17, 2015. Origin of the solitary ("overlord") / centralized / federated taxonomy and the "Overlords don't scale" line.

• zeroheight, "Design system governance models and which is right for your organization", updated May 15, 2025. Source for the federated, centralized, and hybrid model definitions used in the comparison table.

• Andrew Martin, "Managing Teams for Large-Scale Design Systems", UXPin, January 25, 2026. Source for the hybrid-model description and the ~25% embedded-contributor time-allocation figure.

• UXPin, "Design System Governance: A Guide to Prevent Drift", January 20, 2026 (updated May 9, 2026). Background on federated/mixed governance models and on design drift as an industry-recognized concept (variant sprawl, token overrides, AI-generated layouts constrained to approved components).

• Karolina Szczur, "Against design system federation", July 14, 2026. Critical perspective on the federated model's practical failure modes, including a discussion of AI tooling and frameworks like Tailwind being used to generate system-adjacent UI — reflected in this article's drift discussion.

• Style Dictionary, an open-source, Apache-2.0-licensed build system for distributing design tokens across platforms (iOS, Android, CSS, JS, etc.) — referenced as an example of platform-agnostic token tooling for mitigating cross-framework drift.

All claims and figures drawn from these sources are paraphrased in this article's own words rather than quoted; short phrases in quotation marks (e.g., "Overlords don't scale") are direct attributions to their original authors.

A small favor

Was anything I wrote confusing, outdated, or incorrect? Please let me know! Just write a few words below and I’ll be sure to amend this post with your suggestions.