aditya-ariosity 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
Synthetic example: Button | 24 product instances | Shared component | Five colors; three focus treatments | Focus and loading | Missing focus | 17/24 use shared | UI platform
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, themes and aliases, accessibility-critical typography and motion, deprecation, and distribution.
Components and patterns
Read references/component-contract.md. Inspect anatomy, variants, states, semantics, keyboard and responsive behavior, API boundaries, escape hatches, and test coverage.
Documentation and tooling
Inspect discoverability, realistic examples, rationale, design-code linkage, migration guidance, release notes, and executable stories or tests.
Governance and adoption
Read references/governance-and-adoption.md. Inspect ownership, contribution and decision rights, release and deprecation, exceptions, support, adoption measures, 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
For a complete input-to-output demonstration, read references/worked-example.md. Use it to calibrate evidence sampling, system-level diagnosis, and migration detail; do not treat its fictional component inventory as a default.
System frame
State scope, maturity, evidence, exclusions, and source-of-truth assumptions.
Health summary
Use a table:
Layer | Health | Strong evidence | Main risk | Confidence
Synthetic example: Semantic tokens | At risk | Token package and compiled themes | Products bypass semantic aliases | High
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
Synthetic example: Two wrappers suppress focus | Keyboard users lose location | Focus is treated as optional | Make focus an invariant | Migrate wrappers, then remove override | Every variant retains visible focus
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.
Checkpoint: Re-check each finding against evidence, scope, confidence, migration, and acceptance criteria. Revise unsupported or unowned recommendations, then repeat until every Quality-bar item passes or is marked Needs decision.
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.