Design systems have massive impact at scale, especially with organizations that manage dozens, hundreds, or thousands of digital products. But that scale brings its own set of problems.

The most general misconception I often see at scale is that, once a design system is established, every product must then use it. “100% adoption” is the goal, meaning design system work isn’t done until every product at the organization has been migrated to use the design system.

This is nonsense.

For starters, migrating just the codebase of hundreds or thousands of digital products would take years.

The solution is a more pragmatic point of view: only some of an organization’s products should use the design system.

Which begs the question: which products should use the design system and which ones shouldn’t?

This is a question I’ve spent time on with every single organization I’ve consulted with.

A design system prioritization matrix

Luckily, I found a handy guide a few years ago that I use every time:

This is a super useful matrix by design system consultant Nathan Curtis entitled “Must/Should/Could a Product Adopt a System?” The two axes are Product Stage and Upcoming Investment, a smart combination that juxtaposes two of the most important factors of valuable design system work.

The green “Must” and red “Avoid“ areas make obvious what many teams struggle with without a matrix like this to help them:

• New products with more upcoming investment compared to the prior period must use the design system. Launching a new flagship website or app that’s gonna get a lot of executive and/or marketing attention? Use the design system for sure.

• Legacy products with no upcoming investment compared to the prior period should avoid using the design system. That old Lotus Notes-based application approaching end-of-life in 2 years? Don’t bother migrating that over.

The “Should“ and “Could” areas get trickier, so spend more time here. An emerging product with less upcoming investment? Hmm. It should probably use the design system, but it’s worth a few conversations to make sure. An established product with the same investment as last quarter? It could use the design system, but it’s worth considering if there are higher priority places to spend your time.

Level up your prioritization

Here are a few not-so-obvious ways I’ve used this chart before.

I’m reminded of renowned investor Warren Buffett’s 25/5 rule for prioritization: make a list of 25 things you’d like to work on and prioritize them. Then ignore the bottom 20 and work on the top 5. Design system teams often want to put every product on the migration/adoption roadmap. That’s fine! Do it. But then prioritize them and work on the top 5. The chances are pretty high that your top 5 will intersect with the areas of this matrix in green. Once teams do this enough to realize it, they learn to turn their attention to the green areas by default: new and emerging products where organizational investment is trending upward.

Another pattern I’ve spotted is that, as a design system team gains more adoption and/or influence, they can actually use that influence to affect product roadmaps. They can do this by increasing the amount of investment a product has, just by their endorsement. For example, an established product with the same investment as last quarter could use the design system, although there’s probably a better place to spend time. Unless the design system team reports that, say, it would be very easy to migrate this product in a few days or weeks because of the existing components in the system. This is the kind of unanticipated opportunity that may get that product some additional attention that actually increases its level of executive or organizational investment.

In other words, a beginner level for using this chart is to help you identify where a particular product or feature can sit in a design system migration/adoption roadmap. An advanced level might be identifying how you can change a product’s or feature’s position to move more toward greener areas.

This chart has been invaluable to me in my consulting work over many years. I’m grateful to Nathan for publishing it, and all of the knowledge he shares. Nathan recently opened his new consultancy Directed Edges and offers a spectrum of options for teams who need design system help. These are incredible ways to work with someone who’s been one of the best for a long time at shepherding design system teams. (This isn’t a sponsored post or anything like that, and Nathan doesn’t have any idea that I’m writing it; it’s simply a way to give him his flowers for the ways he’s helped anyone interested in design system. Go check out more of the things he’s written about design systems.)