Overview

The component lifecycle results from the sum of its stages of maturity. Cycles range from their initial creation to their eventual stabilization. Maturity stages determine the quality scope.

Quality is the ability to meet or exceed the customer’s expectations. It results from the maturation process formed by design, content, and code. We’re all responsible for it.

In this document, you will find the requirements and stewards for each component’s maturation phase, and it will also function as a component roadmap checklist.

Stewarding contributions
Ownership is the actor’s right to possess something, whereas stewardship is the job of supervising or taking care of something. Something I own belongs to me, and I control it. Something I steward belongs to the community, and anyone can help take care of it.
— Hayley Huges, Trust between teams (Figma Config 2022)

Maturity stages

Pre-Alpha, or Ariane legacy

Pre-Alpha components existed before the founding of a dedicated Design Infrastructure team. These components do not pass the minimum Alpha requirements, and we have decided to gradually separate them to deprecate them.

Related content

Alpha

Alpha components are typically ad hoc, built for a specific project/use case or as a proof of concept without having reusability or scalability in mind. They may not contain all of the features that are planned for the final version.

Stewards

A single team’s makers—designers and developers—are typically the stewards of this component. The Design Infrastructure team might decide to take over an Alpha component to prevent further fragmentation.

If other team wants to reuse it, they must promote it to Beta together with the original makers to ensure conversations and agreement are happening.

Requirements

1. It uses the Ariane design tokens.
2. It uses the official Ariane assets (e.g., icons and illustrations) in one of the official sizes.
3. The text has a minimum contrast ratio of 4.5:1 with the background color.
4. All the possible user-triggered interactive states are defined.
5. Its interactive target areas are large enough for users to accurately select them, following the Fitts law.
6. Is responsive to different screen sizes.
7. Its name is agreed upon and shared between design and development.
8. It has 100% test coverage in code.

Communication

Discussions should be open in the #design-system Slack channel or the Design System Glue. The Design Infrastructure team can provide additional synchronous guidance and help during Office hours.

Artifacts

• Design: Shared Local library → Specific Pod Name page
• Code: Local components folder in the relative package/feature area

Versioning

• Design: Non-existing, but components’ names will be pre-pended with PodName- to prevent accidental usage and organize things. Learn more about the Local library.
• Code: None

Measurement

A quarterly audit performed by the Design Infrastructure team.

• Design: Figma inserts and detaches in the last 90 days (requires Figma Organization plan).

Beta

Beta components are ready for use by multiple teams. They only have partial documentation and likely contain several known or unknown bugs.

The Design System Guilds have reviewed and agreed on its primary use cases and interaction states, with partial support from the Design Infrastructure team.

Stewards

The Design System Guilds are typically the stewards of this component, with partial support from the Design Infrastructure team. The Design Infrastructure team might decide to take over an Alpha component to prevent further fragmentation.

Requirements

1. The Design Infrastructure team has reviewed and validated the naming.
2. The XD and engineering teams have reviewed and validated the responsive behavior.
3. All the possible state attributes are defined.
4. It has essential documentation with at least primary usage.

Communication

Breaking changes are expected but must be agreed upon in the Design System Glue and communicated in the #design-system Slack channel.

Artifacts

• Design: Shared Local library → Shared components page.
• Code: Shared components

Versioning

• Design: Non-existing, but components’ names will be pre-pended with beta- to set the right expectations when inserting or consuming, and have things clearly organized.
• Code: None

Measurement

A monthly audit performed by the Design Infrastructure team.

• Design: Figma inserts and detaches in the last 30 days (requires Figma Organization plan).

Release candidate

The Release candidate components meet most maturity criteria, and their use is encouraged for most scenarios.

Stewards

The Design Infrastructure team will be their steward. The Design System Guilds are encouraged to offer feedback, propose changes, or request additions.

Requirements

1. All the uses are audited and refined.
2. Its naming and properties are audited and aligned in design and code.
3. Its accessibility is manually audited, and any significant issues are fixed.
4. The implementation and production usage are audited and refined.
5. The documentation covers the most common use cases and basic content recommendations. It’s expected to be iterated during this phase.
6. Includes a Storybook playground of the component.

Communication

Any significant changes will be discussed in the Design System Glue with the team and communicated through the #design-system-announcements Slack channel.

Artifacts

• Design: Standalone Component library we can contain, branch, and revert changes easily.
• Location: Part of the Ariane package

Versioning

• Design: Versioning
• Versioning: Versioning

Measurement

A monthly audit performed by the Design Infrastructure team.

• Design
• Teams using the library (requires Figma Organization plan).
• Figma inserts and detaches in the last 30 days (requires Figma Organization plan).
• Code: TBD

Stable

The Stable components are significantly mature, and usage is strongly encouraged, with long-term support expected.

Stewards

The Design Infrastructure team will be their steward. The Design System Guilds are encouraged to offer feedback, propose changes or request additions.

The Design Infrastructure team will offer additional support during Office Hours to ensure everyone understands and incorporates significant changes.

Requirements

1. The component and its API remain stable, with no breaking changes for at least one month.
2. Usability feedback has been sought, reviewed, and incorporated from the Tech teams, to ensure everyone understands it and is comfortable using it.
3. Supports adaptive design via preference queries.
   https://youtu.be/NQ-FQvsR-gY
4. Detailed documentation exists for design, content, accessibility, and implementation, including do’s and dont’s.
5. Tooling (such as linters, codemods, etc.) exists to help with migrations and prevent further use of alternatives.

Communication

Any significant changes should be planned, formally presented to the team for feedback, and communicated in detail in the #design-system-announcements channel. They won’t happen fast, as the minimum requirements are high, and the scope is extensive.

Artifacts

• Design: Standalone Component library we can contain, branch, and revert changes easily.
• Code: Part of the Ariane package

Versioning

• Design: Versioning
• Code: Versioning

Measurement

A bi-monthly audit performed by the Design Infrastructure team.

• Design: 
• Teams using the library (requires Figma Organization plan).
• Figma inserts and detaches in the last 60 days (requires Figma Organization plan).
• Code: TBD

Acknowledgements

1. GitHub Primer's component lifecycle was a huge source of inspiration for v1 💙