For a long time, the holy grail of design system success has been adoption—how many components from a design system are used, and how often. The majority of results on the first page of Google results for “design system metrics” cite adoption as an “essential” or “most valuable” metric.

I’ve never really been a fan.

Adoption is a lagging indicator, which can only be measured after an event happens. Lagging indicators are relatively easy to measure—which is what makes adoption so attractive as a metric—but difficult to change… which is exactly why I’m not a fan. Design systems are most useful at the points of change, so why put so much stock in a metric that can only be measured after these crucial points?

More importantly, using adoption as the most important metric implies that the goal of a design system is to get used.

It’s not.

The goal of a design system is to help its parent organization achieve its goals more efficiently and consistently with the least possible burden.

Adoption is a part of that, but it’s equipment used for the journey, not the destination.

Nike’s co-founder Bill Bowerman wanted to help his track athletes run faster. That’s why he worked on better sneakers for them. From Shoe Dog, the memoir of Nike chairman emeritus Phil Knight:

There was one piece of gear [Bowerman] deemed crucial to their development. Shoes. He was obsessed with how human beings are shod… He always had some new design, some new scheme to make our shoes sleeker, softer, lighter. Especially lighter… Lightness, Bowerman believed, directly translated to less burden, which meant more energy, which meant more speed. And speed equaled winning… Thus, lightness was his constant goal.

Bowerman—hence, Nike—didn’t make sneakers so that they could be purchased. Design systems shouldn’t make components so that they can be adopted.

Sneakers need to be purchased in order to win races. Design system components need to be adopted in order to achieve the goals of its parent organization. But sneakers and components are just the equipment. Their adoption is a lagging indicator of the goal, not the goal itself.

Buying sneakers won’t make you faster. And design system adoption doesn’t indicate success. I’ve met with plenty of teams that have 90%–100% adoption of their design systems but still experience the same inefficiencies and inconsistencies in product and process that they had prior to adopting the design system.

What’s a better indicator? Specifically a leading indicator, something that can more accurately predict future conditions of success?

First, some context.

At many enterprise organizations, cross-disciplinary teams are formed around separate features (feature teams). The people who are dedicated to working on a design system are a separate team (the design system team.)

In my consulting work with various teams over many years, there’s one specific leading indicator that has emerged more than others. It’s the answer to this question:

How early does a feature team invite, involve, and/or include the design system team in their work?

If I could only track one metric regarding design systems, it would be this one. My anecdotal data shows that the earlier a feature team involves the design system team, the more successful the design system is.

Design systems teams that get invited to feature kickoffs or sprint planning exercises have the ability to be the most helpful than when they’re invited during a later implementation phase.

Why? My hypothesis and observation so far is that design systems teams that get invited to kickoffs are conceptually there to help come up with a solution, whereas design system teams that get invited later on are there to supply components. This distinction is important because it signals the strategic importance of the design system to any particular initiative at the company.

The next level to this is to evaluate a design system team’s presence in the conversations when a feature or product is being conceived, before it’s even officially kicked off when a team. This is a strong indicator that an organization sees a design system as part of their competitive advantage as opposed to a production tool with limited strategic benefit.

Another reason this is important is that these different positions often surface very different questions and conversations. It’s much more indicative of the kind of design system a company has:

• In implementation kickoff, the design system team is asked, “Do you have components that match what we have in this design?” Because of the timing of this question—later than it could be—the feature team has already missed out on half the benefits of a design system tool.

• In feature kickoffs and sprint planning, the design system team is asked, “What components are available in the system that we could use to make our process faster?” This question takes full advantage of the efficiency of a design system tool.

• In concept and strategy meetings, the design system team is asked, “What features and products can we create more easily for our customers because we have this design system?” This question leans into a design system as much more than a tool and instead more of a process and a practice.

So, next time your design system team asks how adoption can be increased, suggest instead working on having feature teams invite you into their processes earlier. The closer you tie your design system to feature value, product value, and ultimately organizational value, the more success you’ll see.