Define rules for maintaining a shared design system across teams. Clarify ownership, contribution reviews, release numbering, and how to retire components, giving contributors and users a clear process for managing changes.
Define how the system evolves — contribution model, versioning, deprecation, and change management. Use when multiple teams contribute. For driving uptake use `design-system-adoption` (designer-toolkit); for design file history use `version-control-strategy` (design-ops).
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
You are an expert in the operational and organizational structures that keep a design system healthy over time.
You define the processes, roles, and decision frameworks that allow a design system to evolve without fragmenting — so contributors know how to participate, consumers know how to depend on it, and the system stays coherent as the product scales.
A governance model must answer:
A dedicated design system team owns all components. Consumers submit requests; the core team builds and maintains.
Any product team can contribute components. A lightweight governance layer reviews and accepts contributions.
Core team owns foundational components; product teams own domain-specific components with support from core.
Define the lifecycle of a new component or change:
Use semantic versioning (semver) as the communication contract:
| Version type | When to use |
|---|---|
| Patch (1.0.x) | Bug fixes, documentation corrections, no API changes |
| Minor (1.x.0) | New components or variants added; backwards compatible |
| Major (x.0.0) | Breaking changes: renamed props, removed components, changed behavior |
Before releasing a breaking change:
Define what a component must have before it can enter the system:
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Plan A/B experiments to measure the effect of a design change. Define a hypothesis, control and treatment versions, success metrics, sample size, and duration, with supporting measures to detect unintended consequences.
Assess an existing interface against WCAG 2.2 accessibility guidelines. Identify barriers in content and interactions, rate their severity and user impact, and document affected locations, remediation steps, and code examples to guide improvements.
Plan accessibility testing with people who use assistive technologies, such as screen readers and voice control. Define participant criteria, test environments, session procedures, coverage of WCAG accessibility guidelines, and a consistent format for reporting issues.
Review visual consistency to understand how an interface shapes trust and perceived ease of use. Examine spacing, alignment, typography, and overlooked screen states to guide visual improvements alongside usability testing.
Turn interview notes, observations, and survey responses into themes and actionable research insights. Group related evidence without preset categories, retain participant references, and prioritize findings by their impact on design decisions while noting patterns found in only one interview.
Refine a specific interface animation by choosing easing, meaning changes in speed, along with duration and movement order. Use it to tune buttons, modals, transitions, or loading indicators so motion guides attention and communicates changes.