September 8, 2024

Design System Micro-Adoption

The Question: Episode 31 Wrap-up

On Friday, September 6th of 2024 we held the Episode 31 design system deep dive conversation as part of a series called The Question. Thanks for being part of it.

Davy Fung and Ben Callahan were co hosts for this episode of The Question, facilitating a deep dive on design system micro-adoption.

The Question was shared via email, on LinkedIn, and X and I received 61 responses. Review the FigJam file (which contains the raw data for this episode) and the opening music (“Supernatural” by New Jeans) from the Episode 31 deep dive. Major thanks to my friend and design system leader, Davy Fung, for co hosting this deep dive!

For the week’s question, we provided this context:

Davy and I have been noodling around about a topic to cover in The Question this week. We landed on a bit of a controversial one—the idea of “micro-adoption”. At its core, this concept is about whether you encourage (or allow) teams to adopt at different layers of your design system architecture. Teams who embrace this idea consider things like reading the accessibility guidelines or using a token forms of micro-adoption. In other words, if you embrace micro-adoption, teams don’t have to use fully fleshed out components to be considered a consumer of the system, they can adopt in many smaller ways.

As with any approach, there are pros and cons. This week, we want to understand your perspective on this concept. We want to hear if you’ve tried it and how it’s gone.

And, we’re switching things up on you (again). Instead of answering NOW in order to participate on Friday, you only have to register for the deep dive today. Then, come ready to answer The Question. Once we’re all in the call, we’ll give you a spot to add your answer and the conversation will flow from there!

See you on Friday!

The Structure

If you’ve been following along on this journey of The Question, you’ll have picked up on the fact that the structure of this week is unique. Where we usually require folks to answer The Question by Wednesday at noon Eastern in order to receive the invite to the deep dive, this week we chose to experiment with that format—we offered folks the opportunity to register without answering. That meant we had to gather the data during our deep dive. To do this, we offered three simple polls and one more open-ended question.

In preparation for the day, I began doing my usual research into what has already been said on this topic. I quickly realized that the answer was, “Not much.” Davy and PJ Onori talk about it a little bit in two of their episodes on Design System Office Hours:

Both are excellent conversations, but really only nibble at the edges of the micro-adoption idea. Beyond these two mentions, I couldn’t find much writing or speaking on the topic. If you know of articles, please send them my way!

What is Design System Micro-Adoption?

To get the conversation rolling, Davy and I opted to start with an explanation of what exactly we mean when we say “design system micro-adoption”. To do that, we leaned a bit on my Anatomy of a Design System model.

A diagram illustrating the context and layers of a design system. Beginning with the brand which feeds into the primary layers of the design system (foundations, tokens, core systems, and components), which enable recipes. Each layer is made of three parts: assets (tangible stuff people can include or use in product work), processes (the behaviors of the humans in and around the design system), and documentation (the what, when, where, why, how, who, etc.). A traditional approach encourages adoption from the top (ie., starting with components). Micro-adoption encourages the adoption of any part of any layer.

A traditional adoption approach encourages design system subscribers to start at the top of this diagram. If there’s a recipe or pattern that solves their problem, they should use it! If not, they should compose a recipe or pattern from the available components in the design system.

A micro-adoption approach encourages use at any layer in the system. That means it’s ok for a subscriber to adopt your foundational guidelines, a few tokens, or maybe just the layouts you offer. Any use of the system is recognized and valued.

PJ mentions that this mindset can lead to inflated adoption numbers:

“Using basic elements like a box (just a div) can inflate adoption stats without reflecting actual design system usage.”

There is some truth in this, for sure, but I think of it a little differently. Micro-adoption acknowledges the nuance of design system adoption—that it’s not a binary thing, but a spectrum of many types of use. That recognition gives us the ability to think beyond only whether a team is using the system or not, to consider the health of design system adoption, and to provide a path toward healthier adoption.

During the deep dive, Taylor pointed out that we (the design systems community) don’t actually have agreement on the language used to talk about design system architecture with real accuracy. When he saw the breakdown in the image above, he asked, “Do we have a shared understanding of foundations?” (…his mental model of foundations includes tokens, but my anatomy of a design system model separates tokens from the foundations layer). His point is valid. Each system uses the same words in slightly different ways. This certainly makes it difficult to understand each other in discussions like this one.

The Questions

With that conversation covered and some context established, we had prepared a few polls to ask of those who joined the call. The first was, “Do you allow micro-adoption in your design system program?” We gave folks four choices:

Yes
No
It’s complicated
Not applicable to me

All in, we had 27 responses with about 70% selecting “Yes” as their answer. Interestingly enough, we got ZERO responses for “No” and about 22% for “It’s complicated”. As folks were answering this poll, Maya pointed out that…

“Allow makes it seem like we can control all adoption ;)”

A fair point, to which Davy and I both agreed a better phrasing may have been, “Do you encourage micro-adoption in your design system program?”

Next, we asked for a gut check on the makeup of adoption—“What percentage of consumers of your design system are micro-adopters?” We gave folks six options for this one:

100% (that’s all we do)
75% (most of them)
50% (about half)
25% (not so many)
0% (we don’t do this micro thing)
Not applicable to me

We had one lone respondent stating “That’s all we do”, about 15% claiming most of their adoption was “micro”, around 30% selecting “half”, and about 22% selecting “not so many”.

Finally, we asked, “What’s the lowest level of adoption happening in your org today?” We offered six options for this one as well (and I forgot to add in a “Not applicable” answer—sorry!):

Using or Composing Recipes
Using DS Components
Using DS Core Systems (ie., layouts)
Using DS Tokens
Following DS Foundations
Adhering to Brand Standards

The bulk of the responses were for Tokes or Foundations, both around 35%.

The responses we gathered from the three polls we ran.

The Conversation

Everyone came ready to jump into the conversation this week. Davy kicked us off with the idea that, perhaps micro-adoption is one step on a path toward a more robust adoption. He (and others) suggested that encouraging micro-adoption is a way to get teams involved with the design system in a way that doesn’t require a massive effort. It’s much easier to pull in a few tokens than it is to refactor whole experiences using the system’s components. Nicholas pointed out that this is a less threatening stance—it helps empower product teams to do what’s right for their needs. I agree with this idea and it’s something I talk with a lot of my coaching clients about—offering product owners on subscriber teams a clear path of adoption can go a long way toward them feeling comfortable with the amount of work they are undertaking.

Then, Noelle piped up suggesting that it may not actually good for us to “graduate” consumers toward full adoption. Her point was that full adoption is not the best idea for every team. Most folks agreed with this nuance, but this sparked a great chat conversation.

The chat conversation spurred by Noelle's comment. Taylor explained his approach—that there are different types of consumers and that they should be considered differently.

Taylor shared his view on this, which is a slightly different idea than a “path of adoption”, instead opting to articulate that there are simply different types of consumers. Each team may need something a little different from the design system, and that’s ok!

Elyse suggested that the whole idea of micro-adoption is actually a very standard mental model for engineers. It’s quite normal to use only the pieces and parts of a dev framework that you need. She said, “just because you don’t use every feature of React doesn’t mean you’re not using React well.” In the end, we all agreed (and Guy stated well), that we need to be more articulate about what forms of adoption we actually encourage.

Another exercise we offered attendees was to share the pros and cons of micro-adoption. This turned out to be really valuable information. I’ve selected and summarized a few of the ideas expressed in this exercise here.

Pros of Micro-Adoption

Using tokens is still an efficiency gain from designing/defining/developing those base design decisions—and still promotes brand and UI consistency
Micro-adoption offers us detailed feedback/test data on what is being used and how to help inform next iterations of the DS offering
Micro-adoption allows us to meet designers and engineers where they are at, helping to bridge gaps in communication and create a common understanding of the system
Some use (micro-adoption) is better than none—at least you’re connecting teams to the DS Workflow
More adoption options and flexibility for consumers, positions the design system more as an enabler than the ‘design police’
Micro-adoption requires increased dialog between designers and developers—a great thing

I’m a big fan of micro-adoption for many of these reasons. Especially the idea of meeting teams where they are. This is how you begin to build trust with those users. Getting them involved in using the system in a way they can see will benefit them is a brilliant first step.

Cons of Micro-Adoption

Micro-adoption leads to compounding degrees of maintenance, training, and support by whoever owns/manages the system itself
It can be tricky to get a team to refactor custom implementation using foundational/micro parts if/when a design system component is available in the future
Micro-adoption can potentially cause inconsistencies if at the lower level it’s not being used properly
Micro-adoption can lead to designers being cut out of the process
It’s harder to track usage and more difficult to report on value to leadership (who may not understand the nuances of adoption)

This challenge of the complexity of maintenance when teams all use the system differently is very real. Taking this approach requires a level of communication between the system team and all consumers that is not common in most organizations. Similarly, the challenge of getting teams to refactor custom implementations once the design system offers something the same or better is very real. While I believe this is true of a micro-adoption approach, I also think this is true in other ways already present in many systems (ie., product teams creating their own recipes has a similar challenge if the design system team decides to bring one of those recipes into the system).

The Final Word

The conversation was lively and the number of folks participating continues to grow. All those who chimed in agreed, this is a fascinating topic and one for which there needs to be more research. If you haven’t thought much about micro-adoption, one big takeaway for you is that it is very likely teams are already adopting in this way. A really good first step down this path would be to setup a few interviews with your primary consumers. Sitting down to talk to them so that you can get a real sense for how they use the design system will expose you to so many areas to continue to evolve your system.

Of course, there were many more hot takes and fun rabbit holes. If you missed the deep dive, check out all the links from above and these additional resource shared by folks in attendance.

Additional resources

Thank you

Many thanks to all who participated.

If you missed out this week, sign up for The Question and be ready to answer next time.

Writing Design Systems The Question

Explore more of my writing and speaking.

Or, inquire about design system coaching