Component lifecycle

The maturity lifecycle of components in Ariane.

Component lifecycle

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)

Global and local scopes

Local components

Our design system coverage is still low. Many components and use cases are not yet part of Ariane. Teams need to expand that coverage as new needs arise independently. Local components are the result of that work.

Although ideally, we will reduce the number of local components as the system matures, there will always be new needs in our products that we will need to build fast. The Design System team must avoid bottlenecks and guarantee space for teams to develop their ideas. Design systems are an infinite game and always have a tricky balance of tradeoffs.

Global components

The Design System team will refine and transform the team’s work into global components: official parts of Ariane with guaranteed quality, scalability, and detailed documentation.

Maturity stages

Pre-Alpha, or Ariane Legacy

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.

Stewardship and communication

A single team’s makers—designers and developers—are typically the stewards of this component. The Design System 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.

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

Minimum 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.
The Design System team must validate any uncovered scenarios in the tokens before going to production and offer alternatives to ensure Ariane foundations’ integrity.

In the same way, the Design System team must evaluate new assets and ideally incorporate them into our Design Tokens before production. If that’s not possible, they will track them and strategize to make that process happen as soon as possible.

Artifacts, versioning, and measurement strategy

Design

  • Location: Shared Local library → Specific Team Name page.
  • Versioning: Non-existing, but components’ names will be pre-pended with teamName- to prevent accidental usage and organize things.
  • Measurement: Quarterly audit performed by the Design System team.
    Figma inserts and detaches in the last 90 days (requires Figma Organization plan).

Code

  • Location: Local components folder in the relative package/feature area
  • Versioning: None
  • Measurement: TBD

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 System team.

Stewardship and communication

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

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

Minimum requirements

  1. The responsive behavior has been reviewed and validated by the team.
  2. All the possible state attributes are defined.
  3. It has essential documentation with at least primary usage.

Artifacts, versioning, and measurement strategy

Design

  • Location: Shared Local library → Shared components page.
  • Versioning: 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.
  • Measurement: Monthly audit performed by the Design System team.
    Figma inserts and detaches in the last 30 days (requires Figma Organization plan).

Code

  • Locationshared-components
  • Versioning: None
  • Measurement: TBD

Release candidate

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

Stewardship and communication

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

The Design System team should respond rapidly to guarantee the adoption and control of rogue uses. However, this rapid response doesn’t mean they will introduce changes quickly, but we will always offer short, and mid-term alternatives. The Design System team prioritizes quality over speed, as delivering quality—so others can build fast—is our primary mission.

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

Minimum 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.

Artifacts, versioning, and measurement strategy

Design

  • Location: Standalone Component library we can contain, branch, and revert changes easily.
  • Versioning: Versioning
  • Measurement: Monthly audit performed by the Design System team.
    Teams using the library (requires Figma Organization plan).
    Figma inserts and detaches in the last 30 days (requires Figma Organization plan).

Code

  • Location: Part of the Ariane package
  • Versioning: Versioning
  • Measurement: TBD

Stable

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

Stewardship and communication

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

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.

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

Minimum 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.

Artifacts, versioning, and measurement strategy

Design

  • Location: Standalone Component library we can contain, branch, and revert changes easily.
  • Versioning: Versioning
  • Measurement: Bi-monthly audit performed by the Design System team.
    Teams using the library (requires Figma Organization plan).
    Figma inserts and detaches in the last 60 days (requires Figma Organization plan).

Code

  • Location: Part of the Ariane package
  • Versioning: Versioning
  • Measurement: TBD