Design system governance is the ongoing set of decision rights, contribution rules, versioning, and ownership that keeps a shared system consistent while many people change it at once. It is not a one time cleanup. A design system audit measures drift on a single day. Governance is the process that keeps that drift from building back up.
Governance also assumes you have a system to govern, not a bare component library: tokens, components, and the usage rules around them. This post covers one workflow that spans both Figma and code, because most governance advice only ever covers one side.
Pick a Design System Governance Model, Not a Vibe
Most teams pick a governance model by copying whatever their last company did. That is a vibe, not a decision. Here are the four real options.
Solitary. One person owns every decision. Works only at very small scale.
Centralized. A dedicated core team owns the system full time. Everyone else requests changes through them.
Federated. Contributors across many product teams add components directly, with light central review.
Hybrid. A core team owns tokens, review, and release. Product teams propose and build components.
Match the model to real signals, not preference.
| Signal | Recommended model | |---|---| | One team, one product | Solitary or centralized | | 2 to 4 product teams, low design maturity | Centralized | | 5+ product teams, strong shared decision culture | Federated, with real central investment | | Mid size org, several products, mixed maturity | Hybrid |
Design systems consultant Nathan Curtis has written for years that a federated model rarely holds up unless the center still gets real staffing and authority. Skip that investment and federated turns into five component libraries wearing the same name.
Most mid size organizations end up hybrid. A small core team holds tokens and review steady, while several product teams keep moving at their own pace.
Run One Contribution Workflow Across Figma and Code
Here is the part most governance guides get wrong. They write one process for Figma and a separate one for code, as if a component lives in only one place.
Run a single RFC driven flow instead. One proposal, one review thread, two sets of gates it has to clear before release.
An RFC does not need to be long. A workable shape:
- Problem. What is missing or inconsistent right now.
- Proposal. The component or token being added or changed.
- Scope. A one off for a single product, or a system wide addition.
- API surface. Props, variants, tokens it consumes.
- Migration impact. What breaks, and who has to update.
A written RFC does not need dedicated tooling. A shared doc, or a single Figma page with the five fields above, is enough to start. The discipline is what matters, not the software.
Set a review SLA up front, a turnaround the core team commits to, not a number pulled from research. A few business days is a reasonable default for most teams. Without a stated SLA, proposals stall in a queue nobody owns.
Brad Frost, who created atomic design, has argued for years that a system's parts matter less than the process that keeps people contributing to them instead of building around them. That process is what the RFC actually protects.
On the Figma side, a proposal moves through library branching: build it on a branch, request review before merging into the published library, and get explicit component approval before it counts as system. On the code side, it moves through pull request review gated by CODEOWNERS, a CI step that lints for hardcoded values and off token usage, and a semver release once merged. I've covered the mechanics of keeping those two sides honest in the Figma to code workflow.
A team I worked with had a disputed button variant proposal. A product team wanted a fourth size for one dense screen. The RFC forced the real question into the open: was this a one off, or a system need. It shipped as a scoped one off with an owner and an expiry date, not a new system wide variant, and the core team never had to revisit it in a meeting.
Make Ownership Tangible with Real Artifacts
"Owner" and "maintainer" are titles until they are tied to something real. Tie them to artifacts instead.
Concretely: CODEOWNERS entries that name who must approve a pull request. Figma library permissions, editor for the core team, viewer or branch only for everyone else. The account that actually holds merge rights on a breaking change.
A compact mapping helps here.
| Decision type | Who decides | |---|---| | New component | Core team approves, contributor can propose | | Breaking change | Core team only, with a stated migration plan | | Token change | Core team only | | Deprecation | Core team approves, any contributor can flag |
Keep the split simple. A core team maintains, approves, and releases. A contributor proposes and builds to spec. Blurring those two roles is where governance quietly breaks down, because a proposal with merge rights stops going through real review.
Version and Deprecate with a Warn, Wait, Remove Policy
Version the system the way you'd version any shared package. A breaking change bumps a major version. An additive, backward compatible change bumps a minor. A fix bumps a patch.
Deprecation needs its own phasing, or components never actually leave.
| Phase | Action | Default duration | |---|---|---| | Warn | Mark deprecated, add a lint or console warning | Starts immediately on release | | Wait | Keep it working, publish a support window | One release cycle, team's choice | | Remove | Hard removal once migration is done | End of the stated window |
Warn means a developer sees a warning the moment they use the old component. Wait means it still works, but consumers know the clock is running. Remove means it is actually gone, not just discouraged.
Back the warning with a lint rule and a codemod where you can, not just a line in a changelog nobody reads. A codemod that rewrites the old import gets migration done in an afternoon instead of a quarter of nagging.
Handle Snowflakes and AI Generated Component Drift
A snowflake is a one off component built outside the system for a specific need. Not every one off is a governance failure. An ungoverned one is.
Grant a snowflake when a product need genuinely cannot wait for the RFC cycle. Give it a named owner, and set an expiry date the moment it ships. Log it in the backlog so someone revisits it: either it gets systemized because other teams want it too, or it gets removed.
Here is the part almost nobody writing about design system governance covers yet. AI design tools and agentic code generation now ship components fast, often faster than any review process. A generated screen can carry a button with a hardcoded hex value, or a spacing value that never touched a token, and it ships clean because nothing forces it through the system.
Treat AI generated UI the same as any other proposal. Route it through the same RFC gate before it counts as system. Run the same CI lint that flags hardcoded colors and off token spacing, whether a person or a model wrote the component. Add a periodic drift sweep, a scheduled scan of the codebase for exactly this pattern, because AI generated one offs accumulate quietly between audits.
A one off is not the enemy here. An owner and an expiry date are what keep it from becoming permanent drift, whether a person typed it or a model did.
Keep Governance Alive with a Monthly Sync and Adoption Metrics
Governance written down and never revisited decays fast. Keep it alive with a short recurring sync and a few numbers that actually track drift.
Track component adoption rate: the share of UI actually built from the system versus one off code. Track detached instance count in Figma. Track off token usage flagged by CI. These three numbers tell you whether governance is holding or slipping.
A monthly sync can run in thirty minutes: open proposals waiting on review, adoption numbers since last month, upcoming deprecations, and any snowflake nearing its expiry date.
If the numbers show real drift building up across the whole system, not just a stalled queue, that's the signal to run a full design system audit instead of another routine sync. An audit measures where things stand. Governance is what you do with that measurement every month after.
This is the same discipline behind the design engineering work I run for clients: systems that stay consistent because the process, not a person's memory, keeps them that way. When governance stalls and nobody has the bandwidth to run it, that's the gap our design system consulting work closes.