By Mehdi HassanHow do small teams govern and maintain a design system?
Small teams govern a design system with a handful of habits rather than a process: one person owns it, changes follow a short decision path, releases are versioned and noted, and the team reviews drift once a month. The goal isn't control. It's making sure the system stays the easiest way to build, so people keep using it.
Most design system governance content assumes a dedicated systems team with designers, engineers and a product manager. A startup with two designers and four engineers has none of that, and copying an enterprise model just creates meetings nobody attends. For when a startup needs a system at all, see our guide to design systems for startups. This article is about keeping one alive once you have it.
Enterprise governance | Small-team governance | |
|---|---|---|
Ownership | Dedicated systems team | One named owner, part of their role |
Contribution | RFCs, review boards | A short form or issue template, owner decides |
Releases | Scheduled versions, release notes | Version per change batch, one-line changelog |
Reviews | Weekly councils | 30 minutes monthly |
Metrics | Adoption dashboards | Count of one-offs and detached instances |
Documentation | Full docs site | Figma descriptions plus a short docs page |
Who should own a design system without a dedicated team?
One person should own the design system, and it should be written into their role, not added as a favor. The best owner understands both Figma and code: a designer who codes or a design-minded engineer. Their job is to decide on changes, keep Figma and code in parity and say no to unnecessary variants.
Ownership doesn't mean doing all the work. Anyone can build a component. The owner reviews it, makes sure it matches the Figma component library conventions and token names, and merges it. In a team of six, that's a small, regular slice of one person's week. Without it, the system forks within months.
How should design system contributions work in a small team?
Contributions should follow a three-way decision: use an existing component as is, extend it with a new variant or property, or propose a new component. Most requests should end at the first two. A new component needs to be reused in at least two places before it joins the system.
Check the system first
Before designing something new, the designer or engineer checks the library and docs. Our guide to design system documentation explains how when-not-to-use notes make this check quick.
Ask: is it a variant or a new thing?
If the need is a different size, style or optional part, it's a variant or property. If the behavior or purpose is different, it may be a new component.
Build it locally first
New patterns start as local components in the product file or feature folder. They only move into the system once a second screen needs them.
Open a short proposal
A simple issue template: what it's for, where it's used, screenshots, proposed props. The owner replies within a few days.
Owner merges and releases
The owner checks tokens, naming and states, merges Figma and code together, and writes the changelog entry.
How do you version a design system?
Version a design system with semantic versioning: patch for fixes, minor for new components or variants, major for anything that breaks existing usage, like renaming a token or removing a prop. Release the Figma library and the code together, with the same version number in both changelogs.
In a small team, versions don't need a schedule. Batch changes and release when there's something worth releasing. What matters is that a breaking change is labelled as one. Renaming a variable from color/text/secondary to color/text/muted is a major change, because every reference breaks, and it should come with a migration note. Our walkthrough of syncing Figma variables to code shows why token renames ripple so far.
- Patch: a fixed focus ring, a corrected padding token value.
- Minor: a new destructive button variant, a new empty-state component.
- Major: renamed tokens, removed props, changed component behavior.
How do you deprecate components without breaking things?
Deprecate components in stages: mark the old one deprecated, point to its replacement, give teams a release or two to migrate, then remove it. Deleting a component outright breaks every file and screen that uses it, and it teaches people that the system is risky to depend on.
In Figma, rename the component with a deprecated prefix and move it to a deprecated page so it stops appearing in search. In code, add a deprecation warning in development builds and a comment pointing at the replacement. Track remaining usages and remove the component when they hit zero.
Hypothetical example: retiring an old modal
For example, suppose a startup has two modals: an old one built before the system, and a new dialog component with proper focus handling. The owner marks the old modal deprecated in Figma and code in a minor release, with a changelog note: Use Dialog instead; the old modal will be removed in the next major version.
Each sprint, engineers who touch a screen with the old modal swap it. At the monthly review, the owner checks the remaining count. When it reaches zero, the next major release removes it. Nobody had to stop feature work, and nothing broke.
What rituals keep a design system alive?
A few short, recurring rituals keep a design system alive in a small team. The most valuable is a monthly review of one-offs: components built outside the system, detached instances and raw hex values in code. Those show you where the system isn't meeting real needs.
Ritual | How often | Time | What it catches |
|---|---|---|---|
One-off review | Monthly | 30 minutes | Detached instances, local components, hard-coded values |
Changelog post | Each release | 5 minutes | Teams missing new or changed components |
Design QA on new features | Each feature | Part of QA | Drift between Figma and production |
Token audit | Quarterly | An hour | Unused or duplicate tokens |
Office hours | Optional, weekly | 30 minutes | Questions that would otherwise become one-offs |
Pros
- Costs a few hours a month rather than a full-time role
- Drift is caught while it's still small and cheap to fix
- People trust the system because changes are predictable
- New hires learn conventions from the changelog and docs
Cons
- Depends heavily on one owner, who may leave or get busy
- Rituals get skipped under deadline pressure
- Light process means some inconsistency slips through
- Needs a deliberate upgrade once the team grows beyond it
When does a small team need more design system governance?
A small team needs more governance when the owner can't keep up, when several product teams or a separate marketing team depend on the system, or when you add a second brand or product. At that point, consider a part-time systems role or an external team that maintains it on a retainer.
The marketing site is a common trigger. When brand and product share tokens, the boundary between brand guidelines and the design system needs a clear owner on each side. Our guide to a design system for a Next.js marketing site covers how to share tokens without sharing every component. And if you're still choosing a foundation, our comparison of shadcn/ui vs a custom design system explains which needs less upkeep.
We maintain systems for teams that don't want to hire a systems role, as part of our $6,000 monthly retainer, or set the brand and design direction in a fixed $3,000 sprint, delivered as Figma files. Both are on our pricing.
