Introduction

Without a unified language, all products drift toward inconsistency.

Teams don’t choose to be inconsistent. The drift goes hand in hand with scale. Today, technology companies have to solve increasingly complex user problems across a variety of channels, like apps and websites. As companies grow, it’s common for teams to form around discrete areas of a product, like the homepage, account management, and search. These individual teams, in an effort to work quickly, develop their own standards for quality—which leads to a weakened design vision.

You might not notice this sprawl until you look at all of your products together. Andreas Pihlström from Pinterest explains:

Over the years, the designs for our website, apps and marketing had all begun to drift, so they no longer felt like they had the same personality. A number of new features had also been added without a clear vision to how they fit into the overall design, so the interface had begun to feel cluttered and hard to understand. There was no visual hierarchy or system to help you understand what was important when you looked at any given page. As a result, all the inspiring ideas people save on Pinterest — by far the most important part of our experience — were getting lost. (http://bkaprt.com/eds/00-01/)

As Pihlström notes, the problem with this drift isn’t that products look different (though that’s part of it). The larger issue is what this inconsistency represents (and exacerbates): a lack of alignment and communication across teams, a diluted brand voice, and a disjointed user experience.

Modular building

To address the problem with drift, many companies try to design and build with reusable components. This modular way of building is commonly referred to as a pattern library, a style guide, or a design system. These names are often used interchangeably, but they refer to different things:

• A pattern (or component) library is a collection of reusable user interface (UI) building blocks that are shared across teams and assembled to build products.
• A style guide is documentation, often on a website, that contains your company’s brand language, your component library, and rationale about how these components should be used.
• A design system is the broadest of these tools, and explains how a team should create products. It encompasses the pattern library and style guide, but also includes underlying design principles, rules, and guidelines to help teams create cohesive experiences.

Style guides and pattern libraries are the most tangible outputs of a design system. Because of this, many teams begin their systems by focusing on UI components. But components alone won’t eliminate inconsistency.

What does your team need?

Design systems can take many forms, depending on the size of your team. If your team is small and your primary goal is to reduce inefficiencies in the design and development process, then a small set of documented components and patterns might be all you need.

At the other end of the spectrum, if you aspire to build a UI framework that definitively guides how a web application should be built, and that thousands of teams will use, then you need a more generic solution. Your patterns need to be generalized and open-ended so the product teams that implement the patterns in their work can customize them as they see fit.

However, if your goal is to improve the design and user experience of your products by enabling harmonious, integrated design and development work, then you need more. A pattern library alone can’t create alignment across multiple product teams that are all working toward their own objectives. And a generic design system isn’t going to focus on the common ingredients that make your organization and products special.

Throughout this book, I’m going to refer to the design systems team and the product teams. The design systems team is responsible for creating and maintaining the design system. The product teams are focused on specific products or features. In some organizations, that split might not exist. You may have the same people creating the system and using it to create products.

Design system principles

When you create a design system, you’re not just creating reusable patterns—you’re operationalizing how your company approaches design. Your team’s design system needs to be highly specific to your team’s needs. If you’re creating a design system for the first time, here are some guiding principles as you start your journey—adapt them as needed to fit your team:

• Design systems are intentional. A design system necessarily means being deliberate about how you approach creating, building, and maintaining the user experience of your product. What new habits do you want to introduce that can help your team build higher-quality products?
• Your team is already working in systems. Whether your team has a documented pattern library or not, it uses systems. Over time, teams develop a shared understanding about how they should work. Often, these systems live in people’s heads. A good way to start a design system is by identifying systems that you already have in place that are working well and documenting them. Then, critically evaluate your findings to understand which systems you want to change.
• Strong systems are collaborative. A design system should be cross-disciplinary and should represent how your teams build products together.
• The human aspects of your system are more complicated than the tooling. Many of the conversations around design systems focus on tooling problems. “Our lives will change once we have this Sketch UI kit that maps directly to code.” I get it. Tooling feels tangible. The problem is there are many intangible parts of a system that need to be defined before we can enable harmonious, integrated, and successful product development. Spend more time on creating a shared language and less time on tools.

What makes a design system expressive?

If you’re reading this book, you’ve probably already heard about the benefits of creating a design system:

• Faster builds, through reusable components and shared rationale
• Better products, through more cohesive user experiences and a consistent design language
• Improved maintenance and scalability, through the reduction of design and technical debt
• Stronger focus for product teams, through tackling common problems so teams can concentrate on solving user needs

In short, a design system can take on the easier, more repetitive problems so products can solve hard problems more readily.

Despite these benefits, some designers express frustration with design systems:

• Rigid systems that stifle creativity
• Monotonous systems that lead to generic, cookie-cutter experiences
• Overly specific systems that can’t be adapted to enough use cases
• Complicated, unexplained, and unsupported systems that lead to fragmented user experiences

In this book, I’m going to describe ways you can create a design system that makes your products feel cohesive across multiple touchpoints while still leaving room for meaningful experimentation and divergence. This is what I call an expressive design system.

Expressive design systems have three defining qualities:

• They are purpose-built. Your design system should align your team on a shared vision of your brand’s voice, visual style, and behavior.
• They support a range of expression. Your design system should enable meaningful experimentation and divergence while still retaining the spirit of the system writ large.
• They inspire use. Designers should feel motivated to solve complex problems with their design system, rather than feeling constrained by it.

What this book will cover

This book is not a step-by-step guide to building a design system. The purpose of this book is to help you integrate brand expression and range within an existing design system. Working on a design system isn’t a linear process. You need to continually zoom in and out, jumping between small elements and your entire product ecosystem. So, you’ll find that this book isn’t written in a linear fashion. Feel free to jump around and read things in any order you please.

• In Chapter 1, we’ll discuss how to set a purpose statement for a design system that will guide your work. Then we’ll look at how to establish principles that will align teams as they make design decisions.
• In Chapter 2, we’ll look at the process behind the system. How can you get a better understanding of your organization so you can make the most impact with a design system? After that, how do you go about unifying, consolidating, and documenting elements?
• Chapter 3 focuses on how to communicate your brand through a system. We’ll look at how to define your design language so that your brand’s voice feels harmonious throughout your products.
• Chapter 4 is about how to build in opportunities for variation. A huge part of creating an expressive design system is knowing when to allow for flexibility and experimentation. We’ll discuss some frameworks you can use to decide when, where, and how to allow for variation.
• Chapter 5 reflects on managing design systems. In order to keep our design systems purposeful and expressive, we need to evolve them from real-world use cases. We’ll discuss how clear governance and contribution models will keep our systems alive.

By the end of this book, I hope you’ll believe there’s plenty of space for creativity within design systems.

Let’s get started!