Design System Review
Review the system as a product and an operating model, not a screenshot library. A healthy system creates shared decisions, accessible defaults, predictable behavior, and a credible path from design to production.
1. Define the system boundary
Establish:
- products, platforms, brands, themes, locales, and teams served;
- available evidence: token files, component code, Storybook, Figma libraries, documentation, usage analytics, product screenshots, issue logs;
- source of truth for tokens, components, content, and release status;
- expected consumers and valid extension points;
- maturity stage: inventory, emerging library, adopted system, or multi-brand platform.
Do not equate visual inconsistency with system failure until intent and ownership are known.
2. Build an evidence inventory
Sample real product usage, not only pristine documentation. Create:
Pattern | Instances | Intended source | Observed variants | State gaps | Accessibility risk | Adoption signal | Owner
Trace representative components from semantic token to design asset to code to product. Record drift at the layer where it originates.
3. Review four layers
Foundations and tokens
Read references/tokens-and-theming.md. Inspect semantic naming, primitive separation, modes, themes, aliases, units, typography, motion, elevation, density, breakpoints, deprecation, and distribution.
Components and patterns
Read references/component-contract.md. Inspect anatomy, variants, states, content, behavior, semantics, keyboard support, responsiveness, composition, APIs, escape hatches, and test coverage.
Documentation and tooling
Inspect discoverability, examples with real content, do/don't rationale, design-code linkage, changelogs, migration guidance, release channels, and executable stories or tests.
Governance and adoption
Read references/governance-and-adoption.md. Inspect ownership, contribution, decision rights, review service levels, versioning, deprecation, exception handling, support, usage measurement, and funding.
4. Diagnose causes, not counts
Cluster symptoms into system causes such as:
- missing semantic layer;
- overloaded component API;
- absent state or content contract;
- inaccessible primitive;
- design-code source conflict;
- undocumented extension path;
- weak contribution and release process;
- migration cost with no product incentive.
Do not recommend one mega-component to eliminate every variation. Preserve legitimate domain differences and standardize the decisions that are truly shared.
5. Calibrate findings
Rate each finding by:
- product and accessibility impact;
- reach across instances and teams;
- recurrence and future drift risk;
- migration cost and dependency;
- confidence in evidence.
Use Critical, Major, Moderate, and Minor only when the organization already uses those terms; otherwise use Blocker, Systemic, Local, and Opportunity. Keep effort separate from impact.
6. Produce the review
System frame
State scope, maturity, evidence, exclusions, and source-of-truth assumptions.
Health summary
Use a table:
Layer | Health | Strong evidence | Main risk | Confidence
Avoid an unweighted score unless criteria and evidence support it.
Prioritized findings
For each:
Evidence | Product impact | System cause | Recommended decision | Migration path | Acceptance criteria
Token and component plan
Show proposed semantic layers, component contracts, additions, consolidations, deprecations, and intentional exceptions.
Governance plan
Define owners, contribution flow, release and deprecation rules, support, and adoption measures.
Sequence
- Stabilize: accessibility, broken contracts, conflicting sources, high-risk drift.
- Consolidate: semantic tokens, component variants, documentation, parity.
- Adopt: migrations, tooling, product integration, measurement.
- Evolve: new patterns, multi-brand needs, experiments.
Quality bar
- evidence includes real product instances;
- appearance, behavior, semantics, and API consistency are reviewed separately;
- tokens express meaning, not only raw values;
- all consequential states are part of the component contract;
- accessible defaults are built into primitives;
- exceptions have explicit owners and rationale;
- design and code have a declared authority and synchronization model;
- recommendations include migration and governance, not only cleanup.
1---2name: design-system-review3description: Review a design system, UI library, token architecture, component inventory, Figma library, Storybook, or implemented product for consistency, coverage, accessibility, maintainability, adoption, and governance. Use when asked to audit components, tokens, spacing, typography, color, theming, variants, states, APIs, documentation, design-code parity, contribution, or migration. Produce evidence-backed system findings, a component and token remediation model, governance decisions, and a sequenced adoption plan. Do not use to police intentional product variation or to create a visual brand from scratch.4---56# Design System Review78Review the system as a product and an operating model, not a screenshot library. A healthy system creates shared decisions, accessible defaults, predictable behavior, and a credible path from design to production.910## 1. Define the system boundary1112Establish:1314- products, platforms, brands, themes, locales, and teams served;15- available evidence: token files, component code, Storybook, Figma libraries, documentation, usage analytics, product screenshots, issue logs;16- source of truth for tokens, components, content, and release status;17- expected consumers and valid extension points;18- maturity stage: inventory, emerging library, adopted system, or multi-brand platform.1920Do not equate visual inconsistency with system failure until intent and ownership are known.2122## 2. Build an evidence inventory2324Sample real product usage, not only pristine documentation. Create:2526`Pattern | Instances | Intended source | Observed variants | State gaps | Accessibility risk | Adoption signal | Owner`2728Trace representative components from semantic token to design asset to code to product. Record drift at the layer where it originates.2930## 3. Review four layers3132### Foundations and tokens3334Read [references/tokens-and-theming.md](references/tokens-and-theming.md). Inspect semantic naming, primitive separation, modes, themes, aliases, units, typography, motion, elevation, density, breakpoints, deprecation, and distribution.3536### Components and patterns3738Read [references/component-contract.md](references/component-contract.md). Inspect anatomy, variants, states, content, behavior, semantics, keyboard support, responsiveness, composition, APIs, escape hatches, and test coverage.3940### Documentation and tooling4142Inspect discoverability, examples with real content, do/don't rationale, design-code linkage, changelogs, migration guidance, release channels, and executable stories or tests.4344### Governance and adoption4546Read [references/governance-and-adoption.md](references/governance-and-adoption.md). Inspect ownership, contribution, decision rights, review service levels, versioning, deprecation, exception handling, support, usage measurement, and funding.4748## 4. Diagnose causes, not counts4950Cluster symptoms into system causes such as:5152- missing semantic layer;53- overloaded component API;54- absent state or content contract;55- inaccessible primitive;56- design-code source conflict;57- undocumented extension path;58- weak contribution and release process;59- migration cost with no product incentive.6061Do not recommend one mega-component to eliminate every variation. Preserve legitimate domain differences and standardize the decisions that are truly shared.6263## 5. Calibrate findings6465Rate each finding by:6667- product and accessibility impact;68- reach across instances and teams;69- recurrence and future drift risk;70- migration cost and dependency;71- confidence in evidence.7273Use `Critical`, `Major`, `Moderate`, and `Minor` only when the organization already uses those terms; otherwise use `Blocker`, `Systemic`, `Local`, and `Opportunity`. Keep effort separate from impact.7475## 6. Produce the review7677### System frame7879State scope, maturity, evidence, exclusions, and source-of-truth assumptions.8081### Health summary8283Use a table:8485`Layer | Health | Strong evidence | Main risk | Confidence`8687Avoid an unweighted score unless criteria and evidence support it.8889### Prioritized findings9091For each:9293`Evidence | Product impact | System cause | Recommended decision | Migration path | Acceptance criteria`9495### Token and component plan9697Show proposed semantic layers, component contracts, additions, consolidations, deprecations, and intentional exceptions.9899### Governance plan100101Define owners, contribution flow, release and deprecation rules, support, and adoption measures.102103### Sequence104105- **Stabilize:** accessibility, broken contracts, conflicting sources, high-risk drift.106- **Consolidate:** semantic tokens, component variants, documentation, parity.107- **Adopt:** migrations, tooling, product integration, measurement.108- **Evolve:** new patterns, multi-brand needs, experiments.109110## Quality bar111112- evidence includes real product instances;113- appearance, behavior, semantics, and API consistency are reviewed separately;114- tokens express meaning, not only raw values;115- all consequential states are part of the component contract;116- accessible defaults are built into primitives;117- exceptions have explicit owners and rationale;118- design and code have a declared authority and synchronization model;119- recommendations include migration and governance, not only cleanup.
Gonadotrophic-tangent41