Design leads, engineering managers and product leaders at fast-moving software and AI companies whose design system exists but keeps drifting.
- "We have a design system" and "our product looks consistent" are different claims. The gap between them is governance.
- Good governance reduces the number of decisions people make from scratch. It is not another approval layer.
- Rules must be specific enough to settle a disagreement: a minimum logo size in pixels, an approved colour pairing with its contrast ratio, a spacing scale with no arbitrary values.
- Define ownership, a contribution path, a deprecation path and a small set of health metrics.
- Design tokens - now standardised by the W3C community group's first stable format - make many rules enforceable in code rather than in review.
A design system without documented rules for how it is used tends to drift the moment more than one team ships against it. Not because anyone is careless, but because reasonable people make different reasonable decisions when nothing tells them otherwise. One team adds a slightly different button for a campaign page. Another hard-codes a colour because the token name was unclear. A third copies an old modal because it was easier to find than the new one.
For AI and software companies shipping weekly, that drift compounds fast. This article covers what governance actually has to do, how to structure it so it speeds teams up, and how to tell whether it is working.
What drift looks like in practice
A recognisable pattern: the foundational assets exist - logo files, a colour palette, a component library - but there are several variants of each in circulation, no usage rules for when each applies, and no guidance on how the brand should behave across web, product and marketing. The result is inconsistent implementation everywhere. The assets are fine; nothing governs how they are used.
Common symptoms:
- Three or more visually different primary buttons live in production.
- Hard-coded colour values appear in code reviews every sprint.
- Designers keep local "fixed" copies of library components.
- Nobody can say which version of a pattern is current.
- The same question ("which grey is the border colour?") gets asked repeatedly in chat.
Governance means fewer decisions, not more oversight
It helps to be explicit about what governance is for: reducing the number of brand and UI decisions an individual has to make from scratch. A well-governed system lets an engineer or junior designer apply the right pattern confidently without asking. That is faster, not slower, than routing every choice through a senior reviewer.
The payoff is measurable. When Figma's data science team ran a controlled study, designers with access to a design system completed their objective 34% faster than those without one. That gain disappears if the system is ambiguous enough that people have to stop and ask.
Write rules that settle arguments
Vague guidance ("keep it clean and modern") does not govern anything. It is an opinion restated as a guideline. Rules that work are specific enough to give one answer.
| Area | Vague guideline | Enforceable rule |
|---|---|---|
| Logo | "Use the logo appropriately." | "Minimum 160px wide on desktop, 120px on mobile; symbol only below 32px." |
| Colour | "Use brand colours for emphasis." | "The accent colour is used only for primary actions. Approved text pairings and their contrast ratios are listed; nothing else ships." |
| Spacing | "Keep layouts airy." | "Spacing uses the 4-64px scale only. No arbitrary values." |
| Components | "Reuse components where possible." | "If a library component exists for the job, use it. Variants are requested through the contribution process." |
| Accessibility | "Make it accessible." | "Text meets WCAG 2.1 AA contrast (4.5:1 normal, 3:1 large). Every interactive element has a visible focus state." |
| Copy | "Use a friendly tone." | "Buttons start with a verb. Error messages say what happened and what to do next." |
Each rule in the right-hand column can be checked by someone who was not in the room when it was written. That is the test.
The five parts of a governance model
1. Ownership. Name the people who maintain the system and approve changes. In a small company this may be one design lead and one front-end engineer. "Everyone owns it" means nobody does.
2. Contribution path. Teams will need things the system does not have. Give them a lightweight way to propose additions:
- Check the library and documentation for an existing solution.
- Propose the new pattern with the use case, a design and any accessibility notes.
- Review with the system owners - accept as a new component or variant, adapt an existing one, or agree a one-off exception with an expiry date.
- Build, document and publish, with a changelog entry.
3. Deprecation path. Old patterns need a way out. Mark them deprecated in design and code, give a replacement and a removal date, and track usage until it reaches zero.
4. Documentation that answers "when". A component page that only shows what a component looks like is half a page. Document when to use it, when not to, its states, accessibility behaviour and content guidance.
5. Health metrics. A few numbers, reviewed monthly, keep governance honest (see below).
Put rules in code with design tokens
The most reliable rules are the ones people cannot break by accident. Design tokens - named values for colour, type, spacing, radius and motion - let you enforce many decisions in code: if the only spacing values available are tokens, arbitrary values become difficult rather than forbidden.
Tokens have also matured as a standard. On 28 October 2025 the W3C Design Tokens Community Group announced the first stable version of the Design Tokens specification, giving teams a vendor-neutral format for sharing decisions between design tools and code. A practical token structure has three tiers:
| Tier | Example | Purpose |
|---|---|---|
| Primitive | color.orange.500 | The raw palette; rarely used directly |
| Semantic | color.action.primary | What the value is for; this is what components use |
| Component | button.primary.background | Optional overrides for specific components |
Governance then becomes simpler: change a semantic token once, and every component using it updates. Linting can flag hard-coded values in pull requests.
A lightweight RACI for governance
| Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Maintaining tokens and core components | Design-system engineer | Design lead | Product designers | All engineers |
| Approving new patterns | System owners | Design lead | Requesting team | Everyone via changelog |
| Accessibility standards | System owners | Design lead | Accessibility reviewer, QA | All teams |
| Brand and marketing templates | Brand designer | Head of marketing | Design lead | Sales, marketing |
| Deprecations | System owners | Design lead | Affected teams | All teams |
Metrics that show whether governance works
- Adoption: share of production screens using library components (sample a set each month).
- Detached or overridden instances in design files.
- Hard-coded values flagged in code review or by linting.
- Time to ship a new standard page compared with before governance.
- Open contribution requests and how long they wait.
- Accessibility defects traced to non-system components.
Track trends rather than chasing perfect numbers. If adoption rises and repeated questions fall, governance is doing its job.
Governance in AI products specifically
AI products add their own drift risks: new surfaces for model output, confidence indicators, feedback controls, citations and warnings appear quickly and often get designed ad hoc. Add them to the system early - with patterns for loading and streaming states, uncertainty, source attribution and human review - before each team invents its own. See UX patterns for data-heavy AI interfaces for examples.
I have never seen a fast-shipping team resent good governance. What they resent is bad governance dressed up as good taste. "Make it feel premium" is not a rule anyone can apply consistently. "Minimum logo size is 160px on desktop" is.
On the AI brand ecosystem work, the governance phase was not about restricting the team. It gave them a documented, componentised system they could apply without waiting on design review for every new page or feature. That is the measure of governance: shipping gets faster once it is in place, not slower.
Frequently asked questions
Who should own a design system at a startup?
Usually a design lead paired with a front-end engineer, with time explicitly allocated to the system. As the company grows, a small dedicated team makes sense.
Does governance mean every design needs approval?
No. Work that uses existing components, tokens and templates should ship without extra review. Only new patterns and exceptions need the contribution process.
How do we handle urgent one-off exceptions?
Allow them, but record them with a reason and an expiry date. Review exceptions regularly; repeated exceptions usually signal a missing component.
Do we need design tokens to govern a design system?
Not strictly, but tokens make rules enforceable in code and reduce drift between design files and production. The W3C community group's stable format makes them easier to adopt across tools.
How often should the design system be updated?
Small, frequent releases with a clear changelog work better than large annual overhauls. Many teams publish updates every sprint or two.
Design system drifting as your team scales?
Let's document the governance layer that keeps it consistent without slowing anyone down.
Sources
Every statistic in this article links to its original publisher. Figures were checked against these sources on September 29, 2026.
- Measuring the value of design systems - Figma
- Design Tokens specification reaches first stable version - W3C Design Tokens Community Group, October 2025
- Understanding SC 1.4.3: Contrast (Minimum) - W3C
