The maturity lifecycle of components in Ariane.
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.
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.
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.
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.
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.
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.
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.
The Release candidate components meet most maturity criteria, and their use is encouraged for most scenarios.
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 will be discussed in the Design System Glue with the team and communicated through the #design-system-announcements Slack channel.
The Stable components are significantly mature, and usage is strongly encouraged, with long-term support expected.
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.