Maturity scale

The maturity scale is divided into 3 major categories:

Use

Use with caution

Don’t use

Within each of those categories there are 2 levels:

Use

• Deployed
• Best practice

Use with caution

• Candidate
• Available

Don’t use

• Proposed
• Deprecated

Components and patterns start out as proposed, are filed in Github as users of the system contribute, and then, typically, progress up the scale as we gain confidence in that component or pattern. That level of confidence is measured by a number of criteria which are outlined below.

The full maturity scale goes in this order:

1. Proposed
2. Candidate
3. Available
4. Deployed
5. Best Practice
6. Deprecated

Definitions

Don't use: Proposed

A team has filed a request for a component or pattern but it has not yet been reviewed by the Design System Team or Design System Council. You will not see this status in the system but it is included here to give a complete view of the lifecycle of a component.

• The Github issue may link to supporting research, a Figma (or other tool) mock-up, or a functional instance on VA.gov.

Use with caution: Candidate

Design System Team and/or Design System Council have evaluated the proposal.

• The Design System Team will be creating documentation for the component or pattern.
• The component or pattern may be in limited use (i.e. it may have already been shipped by a team). This could also be known as: “In work”, “Draft”, “Beta”, or “Give it a go! YMMV”.

Use with caution: Available

The component or pattern is:

• Complete and ready to be used but may or may not have been deployed to production.
• The team that proposed the component can now use it from the system.
• There is some research that backs at least the default variation.

By “complete” we mean that the documentation of the component or pattern is complete and in sync across the Design System (design.va.gov, Storybook, and Figma library).

Use: Deployed

The component or pattern:

• Is deployed in production for more than 3 months
• Is in use by more than one application/project
• Has sufficient research backing one or more of the current variations

In other words, it’s out there and we have some degree of confidence in it.

Use: Best Practice

The component or pattern:

• Has been out in production for a year or more
• Has no significant issues filed against it (accessibility and usability are solid)
• Is in use in multiple projects and works well in multiple contexts
• Has supporting research

Given all of the above, the component or pattern is now considered best practice.

Don't use: Deprecated

A previously available or deployed component or pattern is now considered lacking and should not be used. The component or pattern:

• May be no longer in production
• May have significant issues filed against it and/or now be considered an anti-pattern
• Teams may have moved to a different solution
• Research may have proven our design or implementation was not effective

Components or patterns in this state will direct users to preferred components or patterns and stay in the system for 3 months before being removed.

How components and patterns move through the scale

Principles

Once a component or pattern is “in the wild” the Design System Team will track the following determining factors in maturity:

1. Stability
   • Is it in production and for how long?
   • Are there any significant issues filed against it (how solid are the usability & accessibility?)
2. Research
   • Are there any additional usability tests or other research that directly or indirectly covered this component?
3. Adoption
   • How many teams have adopted this component?
   • How widely is it used across VA.gov?

The Design System team will be auditing components & patterns on a regular basis, evaluating them for movement within the scale

A component or pattern is proposed

Any additions to the system, either new components or patterns, updates to existing entries, or requests for replacements are requested via the Experimental Design Process.

Proposed to Candidate

The Design System Team and Design System Council have evaluated the proposal and the Design System Team is now working on the component or pattern.

Candidate to Available

The Design System Team has completed documenting and building the component or pattern.

Available to Deployed

• Deployed in production for more than 3 months
• Is in use by more than one application/project
• There is sufficient research backing one or more of the current variations

Deployed to Best Practice

• Out in production for a year or more
• Has no significant issues filed against it (accessibility and usability are solid)
• Is in use in multiple projects
• Has supporting research

An example of deprecating a component

Let’s use the Wizard pattern is an example. It was once considered “state of the art” and would have been categorized as “Use: Best Practice”. However, over time some issues were revealed that made us reconsider and we moved to bring the pattern back to “Use with caution: Available”. Essentially, the pattern was “under review”. After review, we now consider the pattern to be “Don’t use: Deprecated” and it has been replaced by other patterns.

In short, a component or pattern may not move backwards through the scale in a linear fashion. In fact, a component or pattern may be deprecated from any other status, if necessary. When we decide to deprecate a pattern, the Design System Team has a process it follows to do so.