Navigating Adoption: Driving Design System Usage & Engagement — Q&A Follow-up

How can you convince product designers and developers to use the design system? How do you measure usage and adoption of the design system? What do you do if people are using your design system incorrectly?

We answered these questions and more in our expert panel “Navigating Adoption: Driving Design System Usage & Engagement” with industry leaders Andrew Clark (Head of Design at H&R Block), Cintia Romero (Senior Product Designer, Design System at Pinterest), and Maya Hampton (Senior Product Manager, Design System at REI Co-Op).

If you missed the live panel, you can watch the recording or read the takeaways from the discussion. We got a ton of audience questions that we weren’t able to answer during the talk, so our panelists have graciously shared their insights below.

Let’s dive in!

Q: How much time and human resources do you put towards education?

Cintia: Design system education is part of our team OKRs, which means we dedicate a considerable amount of time to ensuring our consumers know how to use our system. We do onboarding, accessibility training for designers, tutorials, lunch and learn sessions, events, and a set of documentation folks can rely on to get the best of our system. Our team members are ALL part of it.

I can't say precisely the time we put towards education, but I risk saying that at least 30% of our work is related to that, considering the office hours and Slack support we do as part of education. 

Maya: It does ebb and flow, but we always allocate some time for user support. When we were first launching our system, we did a lot of training and education sessions to build awareness and drive adoption, and we just started to create forums to talk to designers and engineers about what the system could offer them. A few years later, when we had a big hiring surge, we dedicated time to improving our onboarding documentation to be more self-service so our education could scale with the larger audience. 

Andrew: Currently, not enough. Our team is aiming to host (4) training sessions this fiscal year as a start in our education effort.

Q: What are some key metrics you think a design system team should measure?

Maya: Adoption is the big one — looking at both where and how components are being used in the products you support. From those numbers, you can get lots of insights around how well the system is delivering on your value prop, and learn where you need to improve to increase usage. 

Andrew: They vary from lagging to leading indicators. We started measuring NPS in March ‘23. This is a lagging indicator that we’ll pulse annually. We have smaller KPIs like unit/branch coverage, velocity, and primary product adoption that we’ll review each sprint or quarterly.

Cintia: It will depend on the design system goals. I believe metrics should be relative to your system's needs. But one thing I suggest is instead of focusing on numbers, try to understand the details behind the numbers, for example, why folks aren't using specific components. Also, consider measuring (design and engineering) sentiment.

Q: Would you take into consideration the amount of implementation tickets and resolution time as success criteria?

Andrew: Sure thing. Velocity or throughput are keys to understanding the squad/trio’s effectiveness. Getting your system into the hands of the user is where value is actualized. Shipping fast means faster return on investment and satisfaction (success or failure)

Maya: I would say that’s one factor to take into consideration, but output for the sake of output does not necessarily deliver value to your consumers. It could be important in the early stages of a design system though, if you have consumers waiting to adopt until there are more components available. 

Q: When asking for users' opinions or feedback about a certain feature or process, how do you make sure designers don't get fed up with the amount of surveys sent?  😅

Cintia: We (Gestalt) noticed it is tough to get folks to answer surveys, not because we often send them, but because combining our surveys with the company and other teams' surveys can get super heavy! We know time is precious. 

We try to make our surveys simple and short to answer, with only two main surveys per year (H1 and H2), and we also benefit from group discussions, 1:1 convos, and Crits to get qualitative feedback. 

Maya:  It’s very good to be aware of this, we try to limit the frequency of our surveys (e.g. 2x/year). There are other ways to get feedback in between those survey periods, such as sharing in demos or critiques, offering up time during Office Hours, or just reaching out to individuals to have a conversation. If you take action on the feedback from the surveys, over time designers may inherently see the value in participating so their voice is heard. You can always try to incentivize surveys as well, with even a raffle for a $10 gift card to one of the entrants. 

Andrew: Yeah, survey fatigue is real. It’s also a way to listen. Designers need to be great listeners. Without the expectation, it’s actionable.

Q: Any best practices when taking a newer design system and wanting to backport across the product to increase adoption?

Cintia: Firstly, it is important to ensure that the design system is modular and scalable so that it can be easily implemented across different parts of the product. Secondly, conducting user research can help to understand how users interact with the product and identify design elements that are confusing or difficult to use. This can help prioritize which parts of the product to update first and the core components you need to focus on. In addition, it is essential to communicate the benefits of the new design system to stakeholders and users and provide training and resources to support adoption. Evangelizing best practices is a great way to create a cohort of systems advocates.

Maya:  Expect to spend some time here working with the product owners in these areas to help them understand the value of adoption; as well as providing education to designers and engineers about system benefits and how to use them, so that they become advocates within their own teams. 

Q: Are you usually sharing a roadmap on how to get there when creating or revising/extending the design system? So everyone can see the short and long-term outcome, building it iteratively?

Maya: Absolutely share your roadmap — it’s a great way to validate you’re building what people want, and hopefully build some excitement for people to adopt. 

Andrew: We’re building out our first roadmap in over 12 months. And it’s essential to gaining support on where we're heading. It reduces fear and uncertainty and elevates vision and ambition. We saw ineffective results when we focused on just near-term problem-solving and lost the forest.

Cintia: Yes! We have a roadmap page in our web docs so everyone can see what is coming. We try our best to keep it up to date. We build our roadmap based on our company goals, team OKRs, and customer requests.  

Q: Do any of you have a specific anecdote about a time when a designer used the system incorrectly, detached a component, etc., and how you got them back on track?

Andrew: Humans tend to react negatively to feedback. Getting them back on track is how we rewire their behaviors around positive/successful events. Affirming decisions of not detaching or kudos when they use a component effectively is the space where we’ll see more improvement.

Cintia: I believe that communication is key to staying on track. Understanding the root cause of any issue is crucial in order to effectively address it and prevent it from happening again in the future. Educating designers (and engineers) on how to properly use our components can also go a long way in maintaining consistency and avoiding errors.

Q: When are you involved if a new project (might) require a new component or new variant, or when a pattern is created or revised?

Cintia: It varies from project to team, but ideally, the design systems should be involved earlier during the design process so that we (systems folks) can advise from the systems perspective and plan to assist as necessary. At Pinterest, If a new component is identified as a need, we recommend designers join our systems during office hours so we can consult and direct. 

Q: How do you manage the design systems and the specific details across multiple languages/platforms? Ex: Flutter, React

Cintia: While we strive to maintain consistency across all platforms, it's important to recognize that each platform has its own unique set of standards. The best thing we can do is provide comprehensive documentation and take the time to understand the specific requirements of each platform. By doing so, we can ensure that our content is optimized for each individual platform and provides the best user experience possible.

Q: To what extent are your design system teams held formally responsible or accountable for managing a roll-out of new components by consuming teams, for example, with a new brand identity?

Andrew: Our design system team influences the brand identity evolutions. We’re stewards of the brand expression, and it’s essential our brand identity is great in digital spaces. This is where most customers connect with how we look and feel. We’ve created feedback loops and intake sessions to aid in the evolution of the system/brand. 

We’re currently under the hood with a larger brand identity evolution rolling out in 2024! Exciting to see the design system team informing and leading key elements.

Cintia:  I'm not sure if I'm getting the question right, but the success of a "roll-out" depends on the collaboration and communication between the design system teams and consuming teams. When a new brand identity is introduced, for example, it is the responsibility of the design system teams to ensure that all components are updated to reflect the new branding guidelines and that all-consuming teams are aware of the changes. This may involve providing training and support to consuming teams to ensure that they are able to implement the new components effectively. 

Maya: In our organization, we do want to be seen as the digital expression of our branding, and we try to work closely with the brand team to ensure we’re aligned on any changes. I think the rollout of a new brand identity, or even smaller incremental updates to branding, is where the value of the design system and widespread adoption can really shine since it should be much, much easier to manage a rebrand through a design system than teams having to make changes individually. While you are likely only able to be formally responsible for implementation within the system components, you may also be the only ones tracking progress across the product as a whole, so it’s a great opportunity to step up and show how the system can keep everyone aligned to the same branding.