Adoption is a common hurdle for design system teams and maintainers. However, encouraging adoption can be easier than you think with little effort.

What’s your adoption goal?

Adoption can mean different things for different companies and even different things between disciplines or teams. Some common adoption goals include getting people to

• Use design or coded components in their work
• Reference the documentation
• Contribute to the design system

Determine your adoption goals to help identify your audience and where and how you channel your efforts.

Approaching the adoption effort

You can break down the effort into three parts:

• Visibility—creating awareness of the design system as a way to get people ready to use it
• Adoption—getting people to use the design system and make it part of their workflows 
• Impact—measuring how well your system is adopted

As you consider the adoption effort, remember that people have different learning styles. And when creating change, people may need multiple ways of learning and understanding the new process.

Visibility: Go where the people are

The easiest way to gain visibility on your design system is to go where the people are. This means talking about your design system at existing meetings you may have or ones where you can be a guest. 

Some kinds of meetings or events include:

• Monthly team/department meetings
• Quarterly kick-offs
• Design critiques
• PM, engineering, or design-specific meetings
• Scrum team meetings

Even if you have people who appreciate the design system and work, don’t expect them to invite you to a team meeting. It’s not that they don’t want to provide visibility, but it’s more that they don’t know adoption includes creating a lot of visibility around the design system. So, where you can, ask if you can join a meeting to share information. Most of the time, people are happy to have you.

Visibility: Make it an event!

People typically are more engaged with something when it’s a big “to do.” When I was a music promoter, our themed events were always much better attended than non-themed shows. 

If you have the budget, you can create a launch event to introduce your design system and spur adoption. Consider working with your marketing department for ideas on how you can make your event memorable. If you have a distributed team, you can take your launch “on the road” and do a road show. When doing road shows, consider virtually (or in-person) visiting the team during a time zone that’s friendly to them. Have a presentation that gives a high-level overview of your design systems and how you’d like them to adopt it (based on the goals you identified earlier.)

Many of our customers have recently created events to celebrate and create more awareness with their design system. For example, some create half-day conferences, where they showcase new aspects of the design system, host hands-on activities, and have guest speakers join to get everyone excited about the design system. Others have set up exhibit booths for internal events to demo their styleguides and promote their usage. Events don’t have to be immense. Some will set up an info booth in the office entrance with giveaways to champion the design system. Feel free to get creative with your events to catch people’s attention!

Adoption: Create champions

After you’ve created visibility around the design system, it’s time to get people to adopt it. One way to do this is through design system champions. These champions might be guild members, maintainers, or senior-level teammates. Whoever you choose, their goal should be to advocate and remind people to use the system. 

People adopting the system might need coaching on the available components. Champions can mentor and remind designers and developers to leverage components during design/code reviews and critiques. It’s also an excellent opportunity for senior-level teammates to mentor other designers.

Champions should also lead by example, where they can call out which components they’re using and why. If your system is open for anyone to contribute, your champions can suggest when other designers or developers might want to contribute a component, an update, or a variation.

Find ways to celebrate your champions or highlight when team members lead by example in adoption. It’ll help inspire others to adopt it too. You can consider gamifying usage and providing giveaways, swag, etc.

Adoption: Build it into the process

Building the habit of using a design system might take effort until it becomes part of your organization’s natural process. One fundamental way to help with adoption is to document your design system well. When people can rely on your zeroheight styleguide and feel confident with it, they’ll use your design system more. (Which is also why it’s essential to keep it updated!)

Places where you can build it into the process might not be immediately apparent, so here are a few ideas to consider:

Add a line item in review checklists

Design and code reviews can include a line item to double-check that the designer/developer used components from the design system. A quick line item can help get people into the habit.

Answer questions by providing links to the zeroheight styleguide

As design system makers, we like helping others and know there can be a learning curve when adopting a design system. So when people ask questions, we’re happy to answer them. How we respond can impact adoption. For example, if someone asks, “Can I put three buttons in a button group?” rather than provide the direct answer, provide a link to the page where they can find the answer. For example, you can reply, “Full details on button group guidelines can be found on this page [link]. Let me know if you have follow-up questions, and I’ll be happy to help.”

There are two benefits to this approach. They’re reminded about the documentation and start to build the habit of using it. And they will hopefully reference it on their own, reducing the time design system makers have to spend answering basic questions. The design system team can focus on other essential tasks but still be available for more challenging questions.

Include links to the zeroheight styleguide in tools

Think of the different teams’ tools and see if there’s a place where you can add links to documentation. For example, when you create a component in Figma, there’s a field where you can include a link to its documentation.

There is a balance to strike between over-linking and not linking enough. Too many links can add extra effort or cause people to overlook them entirely. (Similar to banner blindness, the links become seen as noise). For example, providing a design system link in a Jira ticket might be helpful initially. But over time, you may only want to provide a link if the work includes using a new or unfamiliar component.

Highlight existing and new components in reviews and discussion

When designers and engineers review or discuss designs, have the designer call out any new or existing components that the team might need to be more familiar with. Even if it might sound redundant, ensuring everyone is on the same page is a good idea. Engineers should also feel empowered to ask if design elements are new or existing components. Both approaches can prevent engineers from accidentally creating new components.

Check with the teams for feedback

As you build the design system into the process, ask what’s working and what could be improved. This can identify tailored solutions that are even more helpful.

Adoption: Onboarding

Consider including an overview of the design system as part of the onboarding process for new hires. This ensures that new team members build good practices right away. Onboarding can take many forms depending on the size of your organization and the number of new hires.

Some onboarding ideas include:

1. Matching a designer or engineering peer to help the new hire get set up with the design system. And they continue to be available for the new hire as they contribute to projects.
2. Hosting a monthly orientation for designers or engineers from the design system team about the design system.
3. Providing a recorded overview of the design system available on the company’s learning platform.
4. Providing a getting started guide in your documentation that new hires reference.

A combination of these ideas works well, too. People often have different learning styles, so providing multiple ways can be helpful as long as it’s manageable to create and maintain.

Impact: Measuring your adoption

You can set goals based on how many (scrum) teams have fully adopted the design system. But to help articulate the value of your design system, capture how well your design system has been adopted and the business impact that makes. Before you start your adoption effort, measure a baseline of its current usage. Then as time passes, check in with these measurements. 

For design teams that use Figma, you can use their analytics to get a sense of component usage, detachment, and more. You can conduct code audits to see component usage on the developer side. For zeroheight, you can connect analytics tools to see how frequently people access areas of your styleguide.

Overall, you can measure adoption impact based on how quickly new hires onboard with the system and can start coding/design. Consider what metrics your organization values and tie in ways to measure based on that.

Not only does capturing this data help you understand how well the adoption process is going, but it also helps demonstrate the value of the design system overall.

What are other ways to increase adoption?

We’d love to hear how else you might have inspired adoption with your design system. Feel free to let us know here or on zheroes, our zeroheight Slack community. If you’re having trouble or facing other challenges, let us know. We’re happy to help!