Governance Principles & Contribution Models

How an organization structures its design system team directly impacts its speed, adoption, and longevity. Nathan Curtis identified three primary team models:

1. Centralized Model: A dedicated core team owns, designs, codes, and documents the design system. Pros: High visual consistency, strict quality control. Cons: Easily becomes a bottleneck, risks detachment from product reality.
2. Federated Model: Product designers and engineers from different squads contribute to the system part-time. Pros: Deep product empathy, high buy-in across squads. Cons: Inconsistent quality, lack of dedicated maintenance time when deadlines hit.
3. Hybrid Model (Hub-and-Spoke): A small dedicated core team maintains infrastructure and tokens (the Hub), while active contributors from feature squads propose and build components (the Spokes). Pros: Combines centralized quality with federated scalability.

In mature engineering organizations, any significant change to the design system begins with an RFC (Request for Comments). An RFC is an open design document that describes a problem, explores alternatives, and proposes a specification before writing code.

The lifecycle of a design system RFC typically includes:

• 1. Problem Statement: What user or squad pain point does this address? (e.g., 'Squads lack an accessible multi-select dropdown').
• 2. Prior Art & Research: How do other systems (Shopify Polaris, Material, Primer) solve this?
• 3. Proposed API & Spec: Visual Figma specs, accessibility keyboard maps, prop types, and token dependencies.
• 4. Open Community Feedback: A 7–14 day review window for designers and engineers across the company to critique the proposal.
• 5. Decision & Merging: Approved proposals enter the system roadmap; rejected proposals clearly document why.

Not every component belongs in the global design system. If a team includes every one-off component in the core library, the system bloats into an unmaintainable monolith.

To decide whether a component belongs in the system, ask three fundamental questions:

1. Is it broadly reusable? Will at least three distinct product squads or user flows use this component over the next 6 months?
2. Does it contain business logic? If a component connects directly to specialized database queries, business APIs, or marketing campaigns, it belongs in product-space, not the design system.
3. Can it be composed? Can the need be met by combining existing atoms (e.g., a Card with an Avatar and Button) rather than inventing a new custom component?

How does an experimental idea become a canonical design system component? Mature teams use a staged Incubation Pipeline (often modeled after Node.js or TC39 stages):

• Stage 1 (Local / Experimental): A feature squad prototypes the component inside their own product repo, using official design tokens.
• Stage 2 (Candidate / Lab): If other squads request the component, it moves to the design system's @system/lab package. The API is tested in production with early adopters.
• Stage 3 (Promoted / Core): After rigorous [accessibility testing](/glossary/accessibility-evaluation), cross-browser validation, and documentation sign-off, the component graduates to the core @system/react package.
• Stage 4 (Deprecated): When an improved pattern emerges, the older component is scheduled for deprecation.

Design systems export code packages (npm, CocoaPods, Maven) and Figma libraries that other teams depend on. To prevent breaking hundreds of apps, releases must follow Semantic Versioning (MAJOR.MINOR.PATCH):

• PATCH (1.2.1 $\rightarrow$ 1.2.2): Backward-compatible bug fixes or accessibility improvements that require no code changes from consuming squads (e.g., fixing an internal focus trap bug).
• MINOR (1.2.0 $\rightarrow$ 1.3.0): New backward-compatible features, components, or optional props (e.g., adding a new size="compact" prop to Button).
• MAJOR (1.0.0 $\rightarrow$ 2.0.0): Breaking changes requiring manual squad refactoring (e.g., renaming prop onDismiss to onClose, or removing a deprecated component).

When you modify a foundational token like $space-8 or a base button CSS rule, how do you verify that you haven't unintentionally broken 40 other components that rely on it?

Manual checking cannot scale. High-performing design systems use Automated Visual Regression Testing in CI/CD pipelines:

1. Headless Browser Snapshots: Tools like Chromatic, Percy, or Playwright capture high-resolution screenshots of every component state and variant across Chrome, Safari, and Firefox.
2. Pixel-by-Pixel Diffing: The pipeline compares the new branch against the canonical main branch, highlighting changed pixels in bright magenta.
3. Human Approval Gates: PRs cannot merge until both a design lead and engineering lead review and approve visual diffs.

A design system without an active internal community becomes an unapproachable bureaucracy. Great governance pairs formal code reviews with informal human connection:

• Weekly Office Hours: The design system team hosts open drop-in hours where product designers and developers can get advice on structuring complex layouts, component selection, or RFC drafting.
• Design System Guild / Ambassadors: Appoint dedicated ambassadors within each feature squad who attend bi-weekly system syncs. They act as internal advocates who champion system adoption and alert the core team to emerging needs.
• Public Pairing Sessions: When a squad is building their first contribution, pair a core engineer with the contributor to review code and walk through the testing pipeline together.

Vague release notes like 'Miscellaneous bug fixes and improvements' destroy trust in a design system. Product squads need to know exactly how a release affects their work.

A high-quality design system changelog should always include:

1. What Changed: A clear, human-readable summary of the feature, bug fix, or visual update.
2. Visual Before & After: Screenshots or interactive GIF comparisons showing the update in both light and dark modes.
3. Impact Assessment: Does this require squad action, or is it a transparent fix?
4. Migration Code Snippet: If a prop or token changed, provide copy-pasteable before-and-after code blocks showing how to update.

Consider a high-growth fintech with 150 engineers across 12 product squads. The checkout squad needs a customized 'CountdownTimer' component for flash deals within two weeks.

Applying our governance principles:

• Immediate Squad Need: The squad builds the component locally in their checkout feature branch, strictly using design system tokens (color-bg-warning-subtle, space-12, font-mono-tabular).
• RFC Evaluation: The squad submits an RFC proposing the component for @system/lab. During review, the marketing and travel squads confirm they also need flash-sale timers.
• Promotion: The checkout squad authors the component in the Lab package with visual regression tests and accessibility documentation, where it is approved and merged.