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.
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:
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.
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.
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:
If you’re reading this book, you’ve probably already heard about the benefits of creating a design system:
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:
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:
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.
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!