Chapter 5. Managing Design Systems

A good design system helps you improvise. Think of it like cooking: if you’ve done all the prep work ahead of time—chopped your vegetables, measured your spices—then you can start improvising as you assemble your ingredients.

Following this metaphor, your design system is your pantry, not your cookbook. You have space to create your own recipe, to add more garlic or less salt if you want to, but you won’t switch to an entirely different cuisine because you won’t have those ingredients.

How do you build a system people want to use? One that helps people improvise? That empowers but doesn’t constrain? If we focus on what people need, it makes our systems stronger.

The best example I’ve heard of what it feels like to use a bad design system is this: “It’s like having to use a hammer when you actually need a screwdriver.” We don’t want the users of our system stuck using the wrong tool for the job.

The Right Tool for the Job

The worst thing we can do with a design system is create a bunch of tools that don’t solve our team’s problems. Take care to choose the right component hierarchy for the scale of your team.

Let’s pretend we’re in the business of making chairs instead of digital products. If I give my team pre-cut pieces of a chair, in the shape of a seat, a back, and legs, with an instruction manual telling them how to put the chair together, they will all build the same chair. But what if I just give my team the materials—oak planks, nails, paint—along with some guidelines about how to make a comfortable chair? We may end up with several chairs that look different, but they will still feel like they’re part of the same family because they’re built with the same materials and the same guidelines.

If you’re creating a design system for several teams, each with its own designers and developers, you’ll want to give those teams the freedom to design their own chairs. The system shouldn’t limit them from creating the best possible experience. Basic components with guiding principles about how to craft good experiences give teams that flexibility.

Should your system contain more basic components or more composite components? That depends on the size of your product team, the breadth of your products, and the reach of your design system. If you look at Bootstrap, a system used by teams around the world, you’ll see that it mainly has basic components (Fig 5.1). These components are flexible and general, which allows teams to combine components in a much more flexible way.

At the opposite end of the spectrum, you may have a small team working on a system to make building and maintaining a single product more efficient. The team maintaining the system may be the same team that uses it to build products. In this case, having a small collection of composite components, tailored to the team’s product objectives, might be enough.

Mailchimp’s design system has a handful of patterns that repeat throughout their product. Seven of their eleven components are composites (Fig 5.2). It would be difficult for a team outside of Mailchimp to drop one of these components into their product, because they are so specific to Mailchimp’s product needs.

If you fall somewhere in the middle—if you have multiple teams building multiplatform products, say—it’s best to start with basic components and expand from there. If you make components that are too large, too inflexible, or too singularly focused, users will end up creating their own patterns.

You also need to think about the types of product teams that will be using your system. Some product teams within your organization may have more design and development resources than others. A team with more designers and developers will be able to modify and create new components more easily than a team with limited resources. If this is the case for your team, consider providing product teams with options: either consume existing composite components out of the box, or assemble a component using a set of basic components.

Evolving Patterns from Products

Design systems shouldn’t be static, especially if you start with a narrow scope. After you’ve released a system, it’s important to monitor how it’s working in products. Good systems evolve from real-world contexts.

The best way to evolve your design system is to test it in real products. Product teams are deeply knowledgeable about solving specific user problems. The systems team has the ability to see across product teams, finding common patterns and building scalable solutions. As Christopher Alexander said in A Pattern Language, “Patterns stay alive because the people who are using them are also testing them.”

Let’s take a look at this real-world testing in action. My team at Shopify was approached by a product team that had found a limitation to a design-system pattern. The logistics team at Shopify needed a way to warn users that they had to finish setting up their account details before they could use a payment service. So the team used a component for displaying the user’s information (a card) and a component for displaying a warning (a banner). There was just one problem: the banner component hadn’t been tested within a card, so the spacing around it was too generous (Fig 5.3).

A designer on the logistics team came to the Polaris team with the question, “How can we adapt banners in cards to keep the same style, but not lose out on so much space?” They proposed a change, then paired with a designer on the Polaris team to refine the styles. They iterated designs together in Sketch via video call (the Polaris team is remote) before coming to a solution for a simplified banner that would work in a card (Fig 5.4).

The logistics team then created a fork of this component to test in their product. After the component was deemed successful, it was folded back into the system for the benefit of other teams.

It’s impossible to anticipate all of the features your system will need up front. If you’ve set up a clear feedback loop between a systems team and a product team, then you will be able to evolve your system organically. A good feedback loop starts with clear communication across teams.

Getting Buy-in

Introducing a design system means that some of the choices individuals were responsible for making before will now be handled by the system. More specifically, it means that you are now responsible for making decisions that people have been used to making themselves. Some people will be excited by this; others may resent losing that control.

However, if people feel like their needs are reflected in the system—if they feel like they were included in the process of creating it—then they’ll be more likely to use it.

• Include people in your planning exercises. The planning exercises in the beginning of the book were designed with buy-in firmly in mind. Involving people from product teams to take part in the mission statement exercise will give you an idea of where they think the system could add the most value. The ecosystem-mapping exercise is also useful for group alignment. It helps draw connections between lack of consistency and a confusing user experience.
• Change your approach for different disciplines. I’m going to make a generalization here: developers tend to care about efficiency more than designers do. The software principle of “Don’t repeat yourself” (DRY) aims at reducing repetition of software patterns and translates very well to the concept of a design system. Because of this, I’ve found it much easier to sell developers on the concept of a design system. It’s not that designers don’t care about efficiency, but our core need to be creative sometimes trumps efficiency. When selling a design system to designers, focus your messaging around how a design system can help them make better user experiences and free them up to focus on more innovative problems.
• Keep up your onboarding. You’ve done all of this work to sell people on the value of a design system at the very beginning of the project. Everyone is on board. Except teams aren’t static. What do you do when new people join and they don’t understand why the system exists? You need to plan for how you want to introduce your design system to new team members. Creating some onboarding material that introduces the concept of the system, why it’s valuable, and how to use it will help you get buy-in every time a new person joins the team.

Governance and Feedback

Some say the greatest risk to a design system is lack of adoption—but rapid adoption without a plan for how you’ll maintain the system is just as dangerous.

Part of this challenge lies in the fact that the skills it takes to build a design system are different from the skills it takes to maintain a system. After you’ve finished your planning, you get into a flow state of creating and documenting new components. The design-system team is almost in pure making mode. Once you release a system for other teams to use, this making mode diminishes. Suddenly you have to be in support mode. You could see your configuration of time go from a hundred percent making to sixty percent support and forty percent making. This rapid shift can sometimes come as a shock.

• Decide what skills you need to maintain the system. How do they differ from the skills it took to make the system? When you’re making a system, most of the work is design and development. Once you’re maintaining a system, especially one that’s gotten widespread adoption and needs to function as a product, then you need some different roles. Product management to manage a backlog and maintain a roadmap. Community management to handle community support, like communicating releases and answering questions. Data and research, to understand adoption rates and see how well your system is doing.
• Rotate people. You may also find that the people who were really excited about creating the design system are less jazzed about needing to spend most of their time supporting people using the system. Rotating people from the product teams to the systems team and from the systems team to the product teams can be healthy. By moving someone from the systems team to a product team, you have someone well-versed in the system who can advocate for it on the other side. Product team members, in turn, have all of the context about how to use the system to ship products. Rotating them onto the systems team can help make the system stronger because they know the low points of using the system.

Design-system ambassadors

One way to evolve your system is to have systems thinkers work on products. People who are invested in the growth and success of the system can be your eyes and ears on the ground—identifying gaps in the system and bringing that knowledge back to the systems team.

Companies like Etsy, GOV.UK, and Sprout Social have all created a version of a “design-systems ambassador program.” In an interview with me, Ben Lister, design-systems lead at Sprout Social, outlined the benefits they’ve seen from their design-system ambassadors program:

Our Design System Ambassadors are designers from across the organization that act as liaisons between their embedded teams and the design systems team. They are our eyes, ears, and voice across the company. Design System Ambassadors not only define and document their team’s design patterns and components, but they also take ownership of them, keep their team synced on design system initiatives, and uncover ways to include design system work on their team’s roadmaps.

The GOV.UK design system has a “design-system working group” composed of multidisciplinary representatives from across government (http://bkaprt.com/eds/05-01/). Formed to ensure that the design system effectively represents its users, the GOV.UK working group:

• reviews proposals and contributions against the contribution criteria
• makes recommendations to help contributors improve their work
• advocates for the needs of colleagues across government

The goal of an ambassadors group is to decide on the roadmap for the design system. Ambassadors should vote on what the design systems team will work on next.

To set up your own design-system ambassadors group, focus on people in your company who show a marked interest in your design system. Are some people always asking questions and adding contributions? Start with the folks who are the most invested.

Governance models

After a system is in place, who is responsible for it—for maintaining it, evolving it, and providing support for it?

Nathan Curtis (http://bkaprt.com/eds/05-02/) and Jina Anne (http://bkaprt.com/eds/05-03/) have written in depth about the various types of governance models for a design system. They’ve broken governance models into four categories:

• Solitary: A solitary model works well for a design system built by one team, primarily to serve its own needs.
• Centralized: A centralized model is a single, central team that produces and supports a system used by others. A centralized team can identify broader systems needs affecting many product teams, but may lack sufficient context into the day-to-day work of creating products.
• Federated: A federated model has designers from multiple product teams deciding on the system together. A federated team has context, but lacks the clear ownership that a centralized team has.
• Cyclical: This model is a combination of a centralized and federated model, where you have a centralized team whose primary responsibility is to maintain the system, but you welcome and encourage contributions from product teams.

The cyclical model sounds ideal, right? You get all of the benefits of using the system in context but also the ability to see across product lines to identify system needs.

Making this work, however, is harder than it seems. For starters, it can be very difficult for the systems team to get that perspective on every product team roadmap, and thus difficult for them to identify recurring problems. Also, product teams are focused on shipping their individual products quickly. They use the system because it’s efficient, but they may not have the time or energy to contribute back to the system.

In order to make the cyclical model work, you need to be thoughtful about how you’ll maintain the system—how you’ll build trust, find advocates, and encourage contribution.

Providing support

The systems team needs to play an active role in supporting product teams. It’s not enough to publish a component. You need to enable product teams to provide feedback on the component’s performance, and use that feedback to evolve components iteratively over time.

Part of building a community around the design system is helping product teams know how they can collaborate with you. If you’re a centralized systems team, you should set up some communication channels so people know where to go when they have questions:

• Choose a channel for quick questions and conversations about the design system. For instance, you could set up a Slack channel for ad hoc feedback, ideas, and questions.
• Organize bigger collaboration sessions. These could take the form of office hours, open-door policies, or training sessions. At Shopify, the Polaris team has design-system office hours every Monday; people can sign up for a short session to walk through how they can solve a problem using the design system.

These communication channels are all about building trust with the teams using your system. The design system grows stronger when people contribute to it—and people are more likely to contribute if they feel invested in the success of the system. Decide on which contribution models make the most sense for your team and then clearly broadcast them.

A word of warning: it’s also easy to over-index here and give people more support than they need. In some cases, you may not want to walk someone through all of the ten steps they need to take to solve a problem. Suggest a first step, point them toward the documentation, and empower them to solve the problem themselves.

Encouraging contribution

If you’re on a design-systems team, one of the main things you’ll have to deal with is helping people understand how they can contribute to the system. The design system shouldn’t be a barrier to creating the best possible user experiences. It’s important to clarify how the system can evolve.

At the beginning of this book, I mentioned that expressive design systems should inspire use. In order for your design system to evolve, product teams need to be using patterns in their products and contributing back to the system. One way of contributing back is by shipping code into the system, either via a bug fix or by submitting a new component. But developers aren’t the only ones who can contribute to a system. Designers, researchers, content strategists, and others can contribute by providing feedback when they find inconsistencies. They can make a suggestion to improve a component if they’ve done their own user testing. They can suggest a revision to documentation if existing content is unclear. Communicate to your teams that contributions can take many forms and can come from anyone.

Be mindful of the reasons people might not use or contribute back to a system. Teams are busy pushing on their own roadmaps and may not have time to contribute back. They may lack the confidence, motivation, or permission to contribute. Perhaps they perceive the systems team as gatekeepers.

Answering a few questions will help solicit more contributions:

• Why should you contribute? “Isn’t maintaining the system the system team’s responsibility? I’m busy over here trying to ship this update to my product.” Help people understand that their expertise and context are critical to maintaining a strong system. Remember, you don’t need to do this alone. If you’ve done a good job at getting buy-in from stakeholders, especially discipline leadership, you can lean on their support to advocate for why contributing back to the system matters. At Shopify, contributing back to the design system is baked into people’s job descriptions, so the expectation for collaboration is set from the very beginning.
• How should you contribute? “I have something I want to contribute. What do I do with it?” Point people in the right direction. The GOV.UK design system contains a “Community” section with information about how to propose a new component or pattern (Fig 5.5). They also include contribution criteria that help people decide if they should pitch a new pattern. The criteria specify that a pattern should be useful for several teams and not replicate an existing pattern.
• Make a big deal when someone contributes. Remember that you want to get continual buy-in for your design system. When someone contributes something meaningful back to the system, celebrate it. That could include making contribution stickers or making an announcement in Slack. Emphasize that this was a shared win. People will want to be part of the celebration.

  

Start with a Simple System

When you create an expressive design system, you’re not just creating reusable components—you’re operationalizing design across an organization. Successful design systems have three major parts: components, guidelines for how the components can be used, and a governance model that unifies the teams that use and contribute to the system.

Instead of focusing intently on just one of these areas—like, say, shipping a UI library with hundreds of components—build your system by starting small in each.

Remember Gall’s law, which John Gall suggested in his book Systemantics as a rule of thumb for building systems:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

A working simple system contains a few components (with guidelines on how to use them) that have been integrated into products. Until you complete the cycle of designing, building, releasing, and integrating the components, you won’t have a complete system. Once a few components are functional and integrated, you can evolve from there.

This is especially important because you want people to evolve the system. A system that feels too robust or complete may intimidate teams. They may feel discouraged from adapting it. Instead, focus on providing a core simple system and allow teams to improvise. That way, your system will become a continual loop between the systems team and the product teams.

Design systems shouldn’t suppress creativity. In Thinking in Systems, Donella Meadows explains how the greatest complexities of systems arise at their boundaries: forest species extend beyond the edge of the forest into the field and field species extend into the forest. That leads to new species with unique compositions that inherit the qualities from both the forest and the field. Borders contain the greatest sources of diversity and creativity.

Pay attention to the borders of your design system. How are people combining existing system elements with custom styles to create new components? How are people using the system in unexpected ways to solve problems? How are people tweaking styles that exist? You may find that multiple teams have started to add another type heading style or a brighter variation on your primary color. Study those behaviors and use them to guide the evolution of your system. If you enable creativity at the boundaries, your system will grow and stay expressive.