Expressive Design Systems

Here are some notes I made from Expressive Design Systems by Yesenia Perez-Cruz, a brief, straight-to-the-point guide to auditing, creating and managing design systems that are purposeful, meaningful, and scalable.

Introduction

Without a unified language, all products drift toward inconsistency. 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.

Terminology

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.

What does your team need?

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.

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.

What makes a design system expressive?

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

Zooming in and out

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.

Purpose and Principles

Unity & cohesion

Design systems create better products when they provide both unity and cohesion. Unity means that things feel complete—all of your brand elements work together as one. Cohesion is the quality that makes your user interfaces easy to understand across the experience.

Unity is easier to accomplish than cohesion, because it can be solved by creating tools: style guides, brand languages, shared components. Cohesion is more complicated because it can’t be solved with a tool alone. In order to create products that feel cohesive, you need to align teams around a shared definition of how your brand should look, feel, and behave. That’s why it’s important to set a purpose and establish principles.

Setting a purpose

Design systems are all about alignment. Early on, you need to align your team around why a design system matters. You can do this by defining a purpose statement for your design system.

Finding your purpose statement

Your purpose statement describes what your team is trying to achieve with the design system. It answers four questions:

What is the goal for our design system?
Why is that goal important?
How will the design system help us?
Who is the design system for?

Getting aligned on exactly what you want to accomplish—and how you’ll know you’ve succeeded—will set the design system on the right path from the beginning.

Listening to users

Successful design systems need to serve many audiences: designers, developers, content strategists, products managers, and, of course, end users. Interviewing these users will help you set a purpose.

Set up some interviews with the users of your design system. Be sure to talk to people from different disciplines, as well as people with different levels of experience.

Creating aligning principles

Designing products requires making hundreds of decisions quickly. A small team can rely on tribal knowledge to ensure that those decisions are consistent. But as teams grow, the ability to make aligned, consistent decisions becomes harder. Your products won’t feel cohesive if everyone is working from a different definition of “quality.” To address this, we need to create a shared framework for decision-making. These are our design principles.

Effective design principles should be:

Specific and opinionated
Grown from within your team
Decision-making tools

There are two types of principles: universal and specific. Universal principles are broadly applicable and can be used for all kinds of design. “Delightful” and “simple” are examples of universal principles. By contrast, specific principles map directly to a specific product and are used to align teams around a common language. To create expressive design systems, you need specific principles.

These principles should not only be specific to your product, but should also embody the qualities you want your user experience to have.

Often, these principles already exist within people’s minds, but need some work to define and document.

Listening to users

Uncover problems:

What are their biggest pain points?
Where are they currently duplicating their efforts in inefficient ways?
Where is communication between designers and engineers starting to break down?

Uncover goals:

What would a design system help them achieve?
What information do they need from a style guide?
How would they want this information presented?
What rationale would they need in order to trust the information in a style guide?

Decision-making tools

Good design principles help your team make decisions faster. Without clear benchmarks, design reviews can become subject to whim and opinion. Principles give structure to design feedback so you can make sound decisions more efficiently.

Establishing your principles

You don’t want to create principles in a vacuum and then drop them on your team. Instead, bring people together to craft principles collaboratively. Start by holding a principles workshop, either in person or remotely. The benefit of developing these principles in a workshop is that it generates momentum across your organization.

Once you go over five principles, people start forgetting them. Aim for five principles and focus on making the language as clear as possible.

Design principles can be considered a tool, just like a UI kit. They should be applied throughout the design process in order to create better experiences. Design your principles with adoption in mind.

Get insights from teams about how easy it was (or wasn’t) to use the principles. Did they feel tangible enough to apply to their work? These insights will help you refine your principles before you release them more broadly.

Turn your principles into decision-making tools

Put your principles into practice by coming up tools that make it easier to apply them. For example, you could create a design review template that has the principles baked in, or scorecards for teams to measure themselves against the principles in project retrospectives.

A strong foundation

Even though component libraries and style guides are the most visible outcomes of a system, it’s important to start with your purpose. A design system that has a solid purpose and principles, even with just a handful of components, will be more cohesive and dynamic than a system with hundreds of components but no shared purpose, principles, or foundation.

The process behind the system

Design systems, like cities, need proper planning in order to work well. A well-planned system is easy to use, inspires participation, and grows stronger over time. A poorly planned system feels disjointed, confusing, and difficult to use. And if you don’t plan your system well, people will start creating their own systems on the outskirts.

When you start developing a design system, you need to answer some big questions:

What products will this system serve?
Which people should we involve?
What is the scope of this system?

Evaluate your design language

How well does your design language express your brand? You need some way to measure whether your design language is effective—that is, how well it expresses your brand. Before you start evaluating, it’s helpful to come prepared with any documentation of your strategic brand guidelines. That could be a brand playbook, brand purpose statement, or design principles.

Is your design language consistent? While the first question is all about the quality of your design language, here you want to understand the quantity of your design elements. Are you using design elements in a consistent way? Are primary buttons always blue? Is the body copy 18px throughout the site? For each of your categories, add up how many variations currently exist. Type sizes and colour hex codes are common culprits of inconsistency.

Evaluate your components

For your first design-system release, you’ll want to choose a blend of both high-frequency (basic building blocks) and high-volume (unique to your product) components.

Chances are that in addition to basic components, your specific product has a few larger components that repeat often, like Airbnb’s listing cards, or the Guardian’s story cards. Consider these high-value components. They might not repeat as often as high-frequency components, but they have a huge role in defining the experience of your product. Improving the functionality and design of high-value components is a great way to improve the overall design quality of your products.

Group components by purpose

When components lack clarity and purpose, the result is inconsistency. If you don’t define a purpose, you may get designers and engineers making a new version of a component for a small visual change. An increase in the number of one-off components across your system will increase technical and design debt—the exact opposite of what you want.

Grouping components by purpose works best to help you understand your larger components, especially ones that display content. That’s because the variation on smaller components, like buttons, tends to be visual, not conceptual

Ask your auditors to work together to group components they think serve a similar purpose. This usually leads to some debate about each component’s purpose until people start to get aligned. Eventually, you’ll have a pile of components that seem like they’re solving the same problem. How do you know if components are solving the same problem? Ignore the visual design for a moment and focus on the content.

It’s very likely that you found a lot of redundant components in your audit. You can’t bring all of the existing components into your new system because your goal is to reduce design and technical debt. You need to determine whether a component adds value before you try to bring it into the new system.

Is your design system working well?

“Working well” means the product is upholding your design principles, the design language is communicating your brand voice, and the design system as a whole is responding to user needs.

What makes a good component?

Purposeful. All of your components should solve a specific problem. Define them by their purpose, not by how they look.

Reusable. Your components should work for multiple use cases. Reduce the number of components that only work for a singular use case.

Flexible. They should work in many different contexts. If you design components that are too rigid, people will create their own components and you’ll end up with a bloated system.

A big part of design-system work is gathering, consolidating, and documenting components until your first release.

Another benefit of basing components and their variations on their purpose (instead of on their visual style) is that it lets you iterate on them over time. Once a component is integrated into a product, product teams can measure how well the component solves the problem it is targeting. This allows teams to feel more confident about evolving and improving components.

Documenting components

Strong, clear, thorough documentation is an important part of any design system. A component or pattern is only as good as the guidance that explains how to use it. Your documentation should help everyone building products understand how to use your components to craft experiences. Explain the purpose of each component and the UX rationale behind it so that everyone involved with the system can use the components thoughtfully.

At a minimum, your component documentation should include these elements:

Name and description: A title and short description that helps users quickly understand what the component or pattern is.
Purpose: A scannable statement that explains the purpose of the component. You want designers and developers to be thoughtful about how each component fits into the bigger picture.
Example: Preferably an example of the component at work, both in design and in code.

You may also want to include:

When to use it: The situations in which a component or pattern should be implemented.
When not to use it: Specific situations where you know a pattern will not work, and what to use instead.
Content guidelines: How content should be written for this component based on what it needs to communicate to users.
Related patterns: Other patterns or components in the system that may be related in purpose, presentation, or content.

Naming components

The naming of a component should be as diverse and cross-disciplinary as your team is. In “The Language of Modular Design,” Alla Kholmatova explained the importance of collaborative naming: “It’s not so much about giving something a great name (although, of course, that’s an ideal to aspire to), but agreeing on the name. That determines how the element will be used and helps to ensure that it’s used consistently by everyone”

Designers, engineers, product managers, content strategists—all should inform the name of your component. Establishing a clear, shared language helps us make better decisions about the purpose of each of our components and how they should be used. It improves collaboration and speeds up design and development.

A good component name should be:

Purposeful. A name should describe the purpose of the component, not what it looks like.
Specific. A name should be as straightforward as possible.
Inclusive. Use language that everyone can understand.

Communicating your brand

Having consistent building blocks won’t guarantee a harmonious layout. The difference between a design language that feels complete and one that feels random is usually a judicious use of space. We won’t be able to predict all of the different combinations of components that will make up our pages. What we can do is think about our brand language as it applies to a component hierarchy. When we are thoughtful about how our brand gets expressed at each level of a component hierarchy, we achieve harmony.

Component hierarchy

Different teams define the hierarchy of their components in different ways. As a general rule, though, these are the different layers:

Basic components: Small, standalone components like buttons and icons
Composite components: A collection of basic components combined to make larger, more specific components
Containers: Areas of a page that contain a collection of components
Layout: How all of the pieces are laid out on a page

Basic components

The lowest layer in the hierarchy consists of basic components, sometimes called elements, basics, or atoms. Basic components are the smallest possible elements that can’t be broken down any further, like buttons, links, or text fields. They are the building blocks of your system, and because you will use them to create all of your larger components, they need to be modular. Basic components also need to be the most flexible; because they’re repeated so frequently in your interfaces, they need to work in a range of contexts.

At the basic component level, colour and typography should be functional.

Basic components need to be the most flexible; because they’re repeated so frequently in your interfaces, they need to work in a range of contexts.

The rationale you provide for how basic components should be used will set your products apart. Ideally, this rationale will explain how each component can serve the design principles you established at the outset.

Composite components

The second layer is more complex. Composite components, often called components , modules , or molecules, are collections of basic components that have been arranged in specific and opinionated ways. These components can also be reusable, but they often serve a more specific purpose, which makes them less flexible. While the main measure of success for a basic component is reusability, composite components are measured by how well they solve their chosen problem.

The choices you make at this level should build on the choices you made at the basic level. If you designed your buttons with generous spacing, then your larger components should also have airy spacing.

At the composite component level, you start to feel the design language more because you’re looking at a collection of components together.

Containers

Containers (or regions) are larger areas of a page that contain composite components. They are typically full-width horizontal elements; pages are then composed by stacking containers on top of each other. Containers are useful when you want to group content in a specific way, but need to provide flexibility in how those content chunks are arranged.

Layouts

Layouts (also known as templates ) determine how these components can be arranged on a screen. They are defined by how the information on a screen will be used and how content will be organised.

When you look at your design language at the layout level, you want to ensure that all of your branding attributes work well together.

Big levers & small dials

We not only need to think about design elements at each level, but also how they ascend the hierarchy. To do this, we need to explore our design language both globally and granularly.

Just as there’s a hierarchy to components, there’s also a hierarchy to the kinds of design decisions you make. Think about it in terms of big levers and small dials. Levers are broad, sweeping decisions about how our experiences should feel. Dials are small, detailed choices that enable those feelings.

There are four big levers that determine what a design will feel like: size, scale, density, and weight. If you squint, how should your pages feel? Compact or loose? Dynamic or evenly paced? Light or heavy

Defining the levers helps you make better choices about your dials. The dials define granular elements: typography, spacing, and colour values. If your design process is anything like mine, then you know the feeling of meticulously increasing and decreasing a font size by one pixel before finally landing on a size that feels right—it’s like turning a dial ever so slightly.

If you define your dials but not your levers, you risk ending up with design choices that feel arbitrary. You may have really tight spacing in one section and loose spacing in another.

Even though we won’t know all the ways components will be used to build pages, we can have harmonious layouts if our levers and dials are in tune.

Achieving Harmony

“Always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan,” said Finnish architect Eliel Saarinen. Remember that components aren’t used in isolation, but around and within each other.

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.

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.

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.

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.

When you create an expressive design system, you’re not just creating reusable components—you’re operationalising design across an organisation.

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.

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.