Advanced Design skill
Govern a design system
Govern a shared design system through accountable contribution, release, adoption, exception, and retirement.
When to use
- Use for a multi-team system with shared code, design assets, tokens, documentation, or standards.
- Use normal component ownership for a small local library with no cross-team governance risk.
Preconditions
- Confirm sponsor, maintainers, consumers, decision authority, funding, repositories, release channels, and product obligations.
Procedure
- Define system scope, user outcomes, principles, supported platforms, service promise, and ownership model.
- Build a consumer inventory and dependency record with versions, criticality, contacts, and adoption evidence.
- Establish contribution governance covering intake, problem evidence, design and engineering review, accessibility review, and decision records.
- Define maturity states, acceptance criteria, release evidence, semantic versioning, distribution, and support.
- Create change classification for compatible, breaking, urgent, experimental, deprecated, and retired work.
- Govern exceptions with scope, rationale, compensating controls, owner, exception expiry, and convergence plan.
- Provide communication, migration, training, office hours, and response targets proportional to capacity.
- Measure adoption, duplication, quality, accessibility, satisfaction, support burden, and time to change.
- Rehearse a breaking change, urgent fix, failed release, unavailable maintainer, and consumer rollback.
- Review funding, roadmap, decision rights, and system health with consumers on a fixed cadence.
Failure plan
- Do not force adoption when the system cannot meet a consumer's evidenced need.
- Stop releases on unowned breaking impact, failed accessibility gates, or unavailable rollback.
- Never let an exception become permanent through silent renewal.
--- name: govern-a-design-system category: design description: Govern a shared design system through accountable contribution, release, adoption, exception, and retirement. Use when many teams depend on common interface decisions and unmanaged change could create product, accessibility, or delivery risk. --- # govern-a-design-system ## When to use - Use for a multi-team system with shared code, design assets, tokens, documentation, or standards. - Use normal component ownership for a small local library with no cross-team governance risk. ## Preconditions - Confirm sponsor, maintainers, consumers, decision authority, funding, repositories, release channels, and product obligations. ## Procedure 1. Define system scope, user outcomes, principles, supported platforms, service promise, and ownership model. 2. Build a consumer inventory and dependency record with versions, criticality, contacts, and adoption evidence. 3. Establish contribution governance covering intake, problem evidence, design and engineering review, accessibility review, and decision records. 4. Define maturity states, acceptance criteria, release evidence, semantic versioning, distribution, and support. 5. Create change classification for compatible, breaking, urgent, experimental, deprecated, and retired work. 6. Govern exceptions with scope, rationale, compensating controls, owner, exception expiry, and convergence plan. 7. Provide communication, migration, training, office hours, and response targets proportional to capacity. 8. Measure adoption, duplication, quality, accessibility, satisfaction, support burden, and time to change. 9. Rehearse a breaking change, urgent fix, failed release, unavailable maintainer, and consumer rollback. 10. Review funding, roadmap, decision rights, and system health with consumers on a fixed cadence. ## Failure plan - Do not force adoption when the system cannot meet a consumer's evidenced need. - Stop releases on unowned breaking impact, failed accessibility gates, or unavailable rollback. - Never let an exception become permanent through silent renewal. ## Done - A governance charter records scope, ownership, decision rights, and service promise - A contribution and release evidence package verifies quality and compatibility - An exception register and retirement record prove bounded divergence - Consumer health review and failure rehearsal are recorded