Design & UX · master area
Design System Governance
When to add a component. When to diverge. When to delete. The system's own ADR-equivalent — written down so the next cycle doesn't re-argue what this one settled.
Owners: Designer, PO, Tech Lead Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: Technical debt is unresolved decisions in the chain.
Where it lives in the chain
- How We Build · Design Execution — where the governance shows up at execution time
- What We Shape · ADR — the artefact pattern this borrows
How to do this
- Practice — every system change (new component, removed component, token change) is a small PR with a one-paragraph rationale. Why now, why this shape, what it replaces.
- Practice — divergences from the system are named. A bespoke component in a feature has a
// system-divergence: <reason>comment and a follow-up task to fold back in or formalise. - Cadence — system review every two cycles. What's drifted? What's been duplicated? What should be deprecated?
What good governance looks like
| Decision | Process |
|---|---|
| Add a component | A pattern shows up 3+ times in shaping. Designer proposes, Tech Lead reviews the API shape, PO confirms the use case. PR includes Figma + Storybook + visual baseline. |
| Diverge intentionally | One-paragraph rationale on the PR. Named follow-up. Never silent. |
| Deprecate | The component is marked deprecated with a successor named. Removal happens after the last consumer migrates — not before. |
| Update a token | Visual regression flags every consumer; review reads the diff page by page. |
A system that grows without governance becomes a graveyard of dead components and conflicting patterns. The cost is paid by the developer who can't find the right button, the designer who has three nearly-identical hovers to choose from, and the client who sees three slightly different products inside one app.
Related crafts
- Design System
- Storybook
- ADR — the technical-side equivalent