Design System Discussions: Adoption

November 3, 2021

According to the Sparkbox Design System Survey 2021, adoption is one of the biggest problems facing design systems teams across the world. Optimizing your system for adoption, avoiding common pitfalls and defining what good adoption is are all on the table for our expert panel in our first webinar event.

November 3rd saw the first in our Design System Discussion events happen on Zoom. I was joined by three amazing panelists, Amy Hupe, Josh Clark and Michael Haggerty-Villa, to answer questions about one of the biggest areas of concern for design systems, adoption. We recorded the session to make sure it wasn’t lost to posterity forever, so here it is. We’ll be pulling out some highlights from it in the coming weeks.

We had an overwhelming response to the first webinar, so we’re already lining up the second one for December, which should be announced in the next few days, so keep your eyes peeled.

“Quality over speed. Do not inject crap into the arteries of your system because you cannot get it out.”

Key Takeaways

This is a summary of key takeaways from the discussion, the main points were shared between Amy, Josh, Michael and Luke. The takeaways are a mix of quotes and summarized conclusions based on the panelist’s answers. We hope you enjoy and get a lot from it!

Measuring Adoption

Amy — Adoption can be defined broadly through awareness, and the different usage levels, following the standards, visual style, guidelines, and principles set up in the design system and code usage. By agreeing that there are different levels of adoption, planning, and dependency, a first step would be getting the team to actually build the design system into their roadmap; This is, in itself, a form of adoption. The team should be following the visual styles, using core components, and using the complete library. It’s helpful to think about all those layers of adoption rather than considering only one of them.

Josh — There is a lifecycle to building a design system that deals with awareness, adoption, and understanding what the user is going through trying to adopt it into their design processes. There are goals behind the design systems. As adoption occurs more gradually, things to consider are:

Is the Design System fulfilling those goals?
Is this actually getting used?
Is it helping to inform the product?
Are the teams working faster because they have usable components?
Is the quality and experience better?
Is the design working better together?
Are there fewer bugs?

Michael — The goals of what a design system should provide include speed, quality, better experience, conversion, collaboration, coherence, and consistency. We are working towards those things, but we cannot do any of those things if people aren’t using what we’ve built, including the code, the designs, and the guidelines, to bring it all together. The most important things around measuring adoption are the awareness, usage, and contribution to the Design System.

Common blockers to adoption

There is a lack of stakeholder buy-in, specifically buy-in to prioritize adoption that weighs against the delivery of product roadmaps. The design system has to be built into the roadmap for adoption to come more naturally and have less friction.

Design System versus Delivering Product

Companies want the product deliverables to happen and the design system to be complete, but there is a tradeoff since the Design System needs to be built before the product is delivered. Because of this, the time needed to invest in building and handing off the design system for teams suffers. Companies want both to happen, but in reality, something has got to give.

Another problem is the chicken and egg nature of when to build components. Teams often bias towards doing components in isolation first, but components are far more useful if they are geared around solving specific problems. Waiting until you know the full context of a component is often a better way to build your design system from the ground up.

Technical Compatibility

Technical compatibility can be an issue if people are using different tech stacks. It would be best for companies to standardize the tech stacks across the teams to support technical compatibility. Getting engineering buy-in to the system is just as crucial as stakeholder buy-in to ensure they want to use and contribute to the system. Although it must be said, that technical challenges, although often thought of as more complex, are usually more simple than people challenges.

Building and maintaining a System

It boils down to trust and authority, which is what Design systems are all about. They are a platform for collaboration. You need to align all the people who contribute to the product, including designers, engineers, product, and business leaders (especially since they are paying for it). Understanding these incentives and needs from these groups is vital for how the design system can solve their problems.

Contribution – Curation over invention

It’s important to understand the why but firstly focus on the current problems that are being solved. When putting a design system together, the core focus should be on curation rather than invention. Make sure that objects built in the system solve a problem rather than just being created for an idea. There needs to be a hierarchy with someone in charge deciding whether what has been designed is normalized and generalized to be a good enough pattern to serve other products.

Open conversations

Encouraging conversations between product teams and the design system team regarding what is working within the system or what is not working and asking others to help build it out is essential. Find a way to invite contribution and collaboration in a way that you are in control of. For instance, Amy worked at a company where they published the component roadmap that had what they were working on and then had a repeating meeting where the team would invite people to showcase what they were working on and facilitated an open discussion. At the end of it, they would create an action item list of things they would work on regarding the received feedback.

Working contribution models

If the design team is then collecting, curating, and blessing those solutions, then that contribution model is working and is vital to maintain. The contributions should represent a demonstrated solution for a problem, whether standards, code, or design patterns. In most cases, 90% of teams do not want to contribute to the design, it’s usually a one-way street of people using the system rather than contributing to it, but there will be people excited about the system.

Setting expectations

Curation and consolidation are where the standards and the expectation settings come in because it can be jarring when a design system team needs to update and change from one system to another. It’s about setting expectations and designing reusable system solutions versus product-specific solutions. When those expectations are not set up, then there can be some conflict. The thing about a contribution is that you have to treat it differently in the early days until it evolves. In the later stages of the design system, once it’s a little bigger, you can afford to be more reactive in how you handle contribution to maintain order.

Federated Teams versus Centralized

Michael suggests having a design system council. The danger of having a federated team is that once that person is out there in the wild, they can get swamped by whatever product team they are in. A hybrid is a good approach where there are some centralized resources.

AUDIENCE QUESTIONS

What are your favorite adoption metrics? How do you gather them?

At the top level, it mainly revolves around usage, with platforms like Figma starting to have some stats about how much things are used and where they are used. The data and usage reinforce the value the components provide and a notion of who is using what. The effects of adoption are significant, affecting how the design system has on the teams that are using it. The metric to focus on is, is the team getting the value from the design system? The value it can provide can contribute to work happening faster, less maintenance, higher quality, and that does not always work that way if the design system does not cater to the team’s habits or the team’s workflows or toolkit? The design system needs to reach a certain level of maturity paired with continuous usage before you can best measure adoption.

Let the audience and your community drive those discussions since they probably have a lot of questions. Talk to the community about their needs and find out how you can support them. sometimes it may not be a Design System thing it might be coming together to solve a design problem and seeing how the design system components and pieces can help. It comes down to treating the design system like a product, ensure you talk to the users find out their problems, try and address those dilemmas while building it.

What happens when you simply cannot standardize tech stacks fast enough for the adoption of the design system to happen?

The tech stack not being able to be standardized has been a common problem among most design systems. What can help to allow flexibility with your definition of adoption is thinking about placing value on people following the standards and styles and the things that you set even if it means that they are creating their own local system that serves them. It’s empowering for the Design System team to not be afraid to have an opinion about technology if they communicate that using a certain technology can lead to a slightly superior experience. People are more interested in figuring out how to architect and build a multi-platform design system because the reality is teams do not usually unify their tech stacks before building design systems.

It seems like design systems are ideally positioned to be agents of culture change in an organization. How do you balance that obligation? Mandate to change culture against the tendency for folks to look at design systems (and their teams) as “design cops?”

Design systems teams don’t make laws, they make guidelines (guidelines allow conversations, they don’t police). That’s how they get out of being the police of the design system. We want people to innovate and go out there and experiment on things. Hopefully, they can use the system as a foundation to build on. There are two levels of authority; for instance, there are unchangeable laws you often see; a baseline standard that certain things are fixed (i.e. brand colors). The other is more flexible because it needs to bend in order to be useful this applies to tools, workflows, processes, and job requirements that, with the right governance, fit like a glove to support the design system.

How does content design come into play in Design Systems?

It’s important to integrate content design as early as possible because language is a part of your system and language is a part of your user experience as much as the visual design and the technical implementation. It needs to be treated like that. There are different levels you can incorporate content design and treat it as part of your design standards and guidelines and apply them to content. Including the code for certain components, consider the constraints you may have like setting character limits, sizing, localization in the code, and related things. Include content demo points. For instance, having button labeling (what makes a good label vs a bad label). With these, try to use real examples in your component examples. Avoid Lorem Ipsum! Some content patterns have reusable, repeatable formats, and guidelines can exist in multiple places within the design system. Try and find a way to make your content guidelines reusable, but failing that, try and have a single source of truth, and link off to that where you need to reuse.

If you could give one tip, recommendation, on something or someone to check out or read what would it be?

“Talk to your users and when eventually when you get them in the office, buy them donuts! It’s about building a community.” – Michael Haggerty-Villa

“Quality over speed. Do not inject crap into the arteries of your system because you cannot get it out.” – Josh Clark

“What is the essence of your system and its core should stay the same. Don’t get attached to your pattern library, design tools, your implementation, or your code libraries; hold any of those very loosely and think about what you want to ultimately achieve.” –Amy Hupe