Governance for small teams

Small design-system teams cannot afford heavy governance, and they cannot afford to have none. Many product teams hear the word "governance" and think of committees, request forms and a three-week wait to change a border radius. Small design-system teams therefore often skip it. The system then slowly loses consistency, until someone proposes to rebuild it from the start.

That choice made sense when governance was expensive. It is the wrong choice now.

The zeroheight Design Systems Report 2026 found, per figures shared in its launch webinar, that 16% of systems are run by one person. Only 15% have a community resource contributing alongside the core team. These teams cannot afford heavy process. They also cannot afford no process at all, because coding agents now contribute UI faster than any one person can review it.

The answer is governance that is small, explicit and mostly automated.

Governance for a small team is not a smaller version of enterprise governance. It is a different thing.

The Guild owns the standard, not every component

We call the group that governs a system the Guild. The name refers to the weaving guilds of the past. These were associations of weavers that set the quality standards for cloth and decided whose work could carry the guild's name. The guild did not weave every thread. It decided what met the standard.

That is the right job description for a modern design-system team. The Guild does not build every component. It owns the standard, decides what enters the system and keeps the record of those decisions.

In a small organisation, the Guild might be one design-system lead, one engineer who cares about the system, and a rotating seat for a product designer. That is enough. What matters is that membership is written down and that every decision has a place where it is recorded.

Every change follows four steps: propose, review, accept, release

Every change to the system follows the same four steps, whether it comes from a person or from an agent.

Propose. Someone states a need. A proposal names the problem, the use case, the screens affected and, if the author has one, a suggested API. It lives as an issue or a draft pull request in the system's repository.

Review. An owner reads the proposal and answers one question first: is this reuse, a variant or new work? Most requests turn out to be reuse, even when they are written as requests for something new. Someone who asks for a "summary card" usually needs Card with DescriptionList, not a new component.

Accept. The owner approves, approves with changes, or declines with a reason. Declines matter. A recorded "no, use X" teaches the next person and the next agent.

Release. Accepted changes are merged, receive a version number and a changelog entry, and reach consumers.

No other steps are required. There is no steering committee, and no monthly intake meeting unless the volume of requests demands one.

Intake must separate reuse from new work

The biggest waste in small-team governance is treating every request as new work. Good intake sorts each request before a person spends time on it:

• Reuse. An existing component or pattern already meets the need. Response: link to the contract and an example, then close the request.
• Extension. An existing component meets the need with a new prop, slot or variant. Response: send the request to that component's owner.
• New. No existing component is close. Response: a full proposal and a design review.
• Exception. The need is real but local to one product. Response: document the exception so that audits stop flagging it.

The exception path is often missing, and its absence is why teams ignore drift tools. ZURB's critique of Figma's Check designs pointed out false positives and the lack of an exception model. If a tool cannot accept a deliberate decision that something is different on purpose, people stop reading its reports.

Four mechanics do most of the work: owners, semver, deprecation, changelog

Owners. Every component and token group has one named owner. The owner is a person, not a team. Being the owner means reviewing changes and answering questions, not writing all of the code. In a team of three, each person owns one third of the system.

Semver. A patch release is for fixes that change no API. A minor release is for additive changes, such as a new prop or a new variant. A major release is for anything that breaks a consumer, such as a renamed prop, a removed token or a changed default. Agents can read semver. If a breaking change is released without a major version number, agents will copy it into new code before anyone notices.

Deprecation. Nothing is removed without a deprecation period. Mark the item as deprecated, say what replaces it, set the version in which it will be removed, and track who still uses it. A deprecation without usage data is only a guess about which consumers you will break.

Changelog. The changelog is written for two readers: a person who scans it to see what changed, and an agent that uses it to decide which API to call. Each entry names the component, the change, the version and the migration step.

AI does the upkeep, people make the decisions

Governance can be light now because the repetitive parts can be delegated.

An agent can scan usage, sort intake against existing contracts, draft the pull request for an accepted extension, write the changelog entry, find every consumer of a deprecated token and open migration pull requests. These are the tasks that take up most of a small team's week.

An agent should not make the decisions. Whether a new component belongs in the system, whether a breaking change is worth it and whether an exception is legitimate are judgements about the product and the brand. The Guild makes them.

The agent prepares the work. The Guild decides.

In Loom, this split is the default. At launch, the MCP server can audit code and propose changes as drafts, and every change reaches the repository as a pull request that a person opens and approves: Loom does not open pull requests itself yet. Routing those drafts into Jira, Linear, Slack, Teams or GitHub workflows, and running monitoring continuously, are shown as concepts in our demo, not shipped yet.

Six metrics show whether the system is getting healthier

Ignore metrics that only look impressive, such as the number of components. Watch these instead:

• Used-but-unruled components. Components in production code that have no contract. Each one is a place where agents will guess.
• Token bypass rate. The share of style values in consumer code that are raw values (hex, px) where a semantic token exists. If this rate goes up, the system is losing ground.
• Local re-implementations. Close copies of system components that live in product repositories. Each one is an unmet need that nobody reported.
• Design-code drift. The number of tokens and component properties where Figma and the repository disagree.
• Intake mix. The ratio of reuse, extension and new requests. If many "new" requests turn out to be reuse, your contracts are hard to find.
• Deprecation tail. The number of remaining usages of each deprecated item, and the days until its removal version.

Reviewed every month, these six numbers tell you whether the system is getting healthier.

A playbook for a team of one

If your system is one of the 16% that are run by one person, here is a starting point that fits into one week.

1. Write down the Guild. You, plus one engineer and one designer who agree to review when asked. Put their names in the repository's GOVERNANCE.md.
2. Assign owners. You own everything at first. Note which areas you would hand over first if someone joined.
3. Adopt the four-step flow. Create one issue template with four fields: problem, use case, screens, suggested API. Create one label each for reuse, extension, new and exception.
4. Turn on semver and a changelog. Do this even if you release only once a month. Agents need the version signal.
5. Pick three metrics. Used-but-unruled components, token bypass rate and drift. Measure them once now, so that you have a baseline.
6. Delegate the upkeep. Let an agent sort intake and draft pull requests. Keep the decision to merge for yourself.
7. Write one deprecation. Pick your most duplicated legacy component and deprecate it properly. Doing this once teaches you the whole process.

Keep the decisions with people

Design-system leads should not copy enterprise governance into a team of three. Leaders who fund these teams should not expect a small team to review every agent contribution by hand. Both problems have the same answer.

Governance for a small team is a short list of decisions that only people make, and a system that makes everything else automatic.

Continue the conversation

These sources, cited above, give the data and the critique behind this model.

Design Systems Report 2026 by zeroheight

A survey of design-system practitioners, with figures on team size and community contribution.

zeroheight Design Systems Report 2026 launch webinar by zeroheight

The webinar in which the team-size figures used in this article were shared.

Review of Config 2026 by ZURB

A critique of Figma's Check designs, including its false positives and the lack of an exception model.