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 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.
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.
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.
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.
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:
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.
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:
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.
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:
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.
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:
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.