Component Status

Component Status communicates the maturity, readiness, and intended usage stage of each component across both Design and Development workflows.

This ensures teams understand what is safe to use, what is experimental, and what should be avoided. Statuses are applied at both the Design Status and Development Status level to maintain alignment between design intent and implementation readiness.

---

Minimum

Design Status: ✅ Allowed Development Status: ❌ Not Ready

Minimum components meet baseline structural and accessibility requirements for design exploration and layout composition, but are not production-ready for engineering handoff.

Use when:

• Component structure is defined but behavior is incomplete

• Tokens or variables are still being finalized

• Interaction patterns are not yet validated

Purpose:

• Enable early design consistency

• Prevent premature development dependency

---

Production

Design Status: ✅ Approved Development Status: ✅ Ready / In Progress

Production components are approved for implementation and represent the current standard for use across products.

Use when:

• Component meets accessibility requirements

• Tokens, variants, and responsive behavior are finalized

• Engineering implementation exists or is actively in progress

Purpose:

• Provide stable, reusable building blocks

• Serve as the default component tier

---

Loveable

Design Status: ✅ Enhanced Development Status: ✅ Optimized

Loveable components go beyond baseline usability and have been reviewed, tested, and refined for delight, polish, and advanced interaction quality.

Use when:

• Motion and micro-interactions are validated

• Usability testing feedback has been incorporated

• Accessibility has been refined beyond minimum compliance

Purpose:

• Elevate experience quality

• Support flagship flows and high-visibility surfaces

---

Deprecated

Design Status: ❌ Do Not Use Development Status: ❌ Do Not Implement

Deprecated components are no longer supported and should only exist for backward compatibility during migration.

Use when:

• Component has been replaced by a newer system pattern

• Structure or logic no longer aligns with system standards

• Redundant functionality exists elsewhere

Rules:

• Do not use in new designs

• Plan replacement in existing implementations

• Reference migration notes when applicable

Purpose:

• Prevent system fragmentation

• Maintain long-term scalability and maintainability