Design Systems

I read a lot about various front end things, I want to see what others are thinking and I hope when I start a book or article that I’ll learn something or be pushed to think differently. That doesn’t always happen, but I have a few books which have transformed the way I think about working on the web. Anna Debenham’s Front End Style Guides was the first. I went on to read as much as I possibly could about style guides and even wrote an article about my own process. Ethan Marcotte pushed me in the same way when he wrote his second book, Responsive Design: Principles & Patterns, which I read, pouring over the patterns he used and how they worked. Are you sensing a pattern here (see what I did there?)? If so, you’re right, it’s all about patterns and systems for me. And Alla Kholmatova’s book, Design Systems has got me thinking and wondering how I can best use her wise words in my current work.

I’d by lying if I said I hadn’t grown weary of some of the writing surrounding design systems lately. So many people are writing about how they’re doing things as if that is the only way to do them, making Kholmatova’s voice a refreshing one. She makes it clear, over and over and over in the book, that there are many ways to do things. You can be strict with your design system, or extremely loose, it isn’t that you have to do things a certain way, but rather that you figure out a way to make it work for your team and organization.

I firmly believe that when a team does the hard work to come up with their own naming conventions, their own process, and their own way of maintaining a design system, they will reap the rewards because the system will work well for them. It will make their work easier and be supported by everyone. With her book, Kholmatova shows us how to do that hard work with exercises and then she gives examples of teams and how they work with their system. And guess what? The teams do things differently and yet still have a functioning, workable system.

What Kholmatova does so well is stress how much design, content, and development need to work together to make a system successful. The underlying design principles support both the functional and perceptional patterns. And she ends with reminding us that we’re making things for people, we have a duty to remember that people are at the end of all this and how we design and create products affects them.

If you’re interested in or wanting to create a design system or improve the one you have or get buy in to take your side project at work and make it part of the normal work flow, read this book. And even better, get your colleagues to do the same, so you’ll have a shared understanding before you begin the hard work to build your own system.

My highlights come from the ebook, so I’ve broken them up by chapter. Please remember, these are the things that struck me, you should read the book yourself to get the full context.

Introduction

…by design system I mean a set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product.

Chapter 1

The choice of design patterns is influenced by many factors. Some of them come from the domain the product belongs to, and from its core functionality: those are functional patterns.

The ethos of a product (or the brand, depending on your definition of a brand) also forms patterns which together shape how a product is perceived; throughout this book I’ll refer to them as perceptual patterns.

There are many kinds of patterns at play when it comes to creating a digital product. That’s why design is hard. Patterns need to interact, connect, yet still work seamlessly together.

A pattern is a recurring, reusable solution that can be applied to solve a design problem.

What makes a product distinct from its competitors is not the novelty of patterns it uses, but how those patterns are executed and applied, and how they interconnect to achieve a design purpose. A set of interconnected patterns forms the design language of your product’s interface.

If you need to get a group of people to follow a creative direction consistently, reliably and coherently, patterns need to be articulated and shared.

When the design language is shared knowledge, you can stop focusing on the patterns themselves and instead focus more on the user.

Functional patterns are represented as concrete modules of the interface, such as a button, a header, a form element, a menu. Perceptual patterns are descriptive styles that express and communicate the personality of the product visually, such as color and typography, iconography, shapes and animations.

Having a shared language would mean that we have the same approach to naming interface elements and defining design patterns, or that the same names are used in design files and front-end architecture.

It’s not only about developing a shared language — we need also to develop a shared use of language. It’s not enough to have a shared understanding of the term button. People must also know why and how to use a button, in what contexts, and the purpose a button can serve.

With all the automated tools and style guide generators available today, setting up a library of components can be done much quicker than in the past. But without a foundation of a coherent design system that integrates the patterns and practices, its impact will be limited. When a pattern library is used to support a solid design language foundation, it becomes a powerful design and collaboration tool. Until then, it’s a collection of modules on a web page.

To make sure the purpose of the product is expressed clearly through everything we do, we would need to establish a few grounding principles and values. They might be discussed informally or written as a manifesto — what’s important is that the people involved in the creation of the product agree on those values and commit to them.

Let’s say we come up with a warm, earthy color palette, hand-drawn icons, typography with a focus on readability, quality photography of healthy food, and a few simple interface elements and controls. These styles will become our perceptual patterns.

Chapter 2

How do we make sure that the purpose of the product is manifested through design? By establishing a few grounding values and principles.

In the context of this book, design principles are shared guidelines that capture the essence of what good design means for the team, and advice on how to achieve it; in other words, agreed criteria for what constitutes good design in your organization and for your product.

What would make them more helpful is knowing exactly what those words mean to your team and your product.

Good principles don’t try to be everything for everyone. They have a voice and actively encourage a designer to take a perspective.

The choice and execution of the patterns and their unique combination are influenced by a product’s purpose, ethos and design principles. You can view design principles as grammar rules for creating patterns and combining them in ways that make intrinsic sense. Equally, as the brand and functional patterns evolve and become more refined, they shape the design principles. Principles and patterns are refined and influenced by one another continuously.

Chapter 3

When a pattern is not defined and shared in the team, you start recreating it to accomplish similar goals: another promotional module, another news feed, another set of sharing links, another dropdown. Before you know it, you end up with 30 different product displays and pop-over menus.

Being conscious of the purpose of your key patterns can help you understand how your system works and prevent it from fragmenting as it evolves.

To see how your patterns fit into a bigger picture, try to map some of your core modules to the sections of a user journey.

To understand the purpose of a pattern, try focusing on what it does rather than what you think it is. In other words, try to find an action that best describes the behavior a pattern is designed for. Describing a pattern with a verb rather than a noun can help you to broaden potential use cases for a pattern and define its purpose more accurately.

To get a shared understanding of how a pattern works, draw its structure: the core types of content a module needs to be effective.

Content structure is closely linked to the purpose of a pattern, as these examples have shown. Knowing how a module is structured helps us understand how it works.

Placing patterns on a scale can help make sure they’re used appropriately and don’t compete for attention across the system. It also helps prevent modules being recreated needlessly, since you can see when you already have a module at the same “volume.”

When we don’t start with the purpose and the structure, we can end up with modules that are too closely tied to their content.

If functional patterns are objects in the interface, then perceptual patterns are more like styles — they describe what kind of objects they are and how they feel.

Chapter 4

Perceptual patterns express the brand through the interface and help to make it memorable.

In modular systems, achieving visual coherence and seamlessness can be tricky. Modules are created by different people for different goals. Since perceptual patterns permeate through different parts in the system, they connect the parts. When the connections are effective, users perceive the unity that links the modules together.

If functional modules reflect what users want and need, then perceptual patterns focus on what they feel or do intuitively. Rather than coming from user behaviors and actions, they are influenced by the personality or ambience a product strives to project.

Just as introducing too many exceptions can weaken a brand, too much focus on consistency can also stifle it.

In digital products, signature moments are not always seen as a requirement, and some teams struggle to prioritize them.13 But it’s the small details that can add an additional layer of depth and meaning to the experience. In our efforts to systemize and structure design it’s important to be conscious of the details that make something feel distinct. In a design system, there always needs to be space to nurture and evolve those moments.

When exploring new styles, try them out on a small area of the site. Be aware of what you’re doing differently, the patterns that are outside of the system, and the reasons for trying them. If they work, gradually fold them into the system by applying them in other areas of the site. Be conscious of the role they play.

Chapter 5

The language can empower people to create products that feel whole, even when multiple contributors work on different parts. Naturally, some people will be steeped in it more deeply than others, but the idea is that everyone — designers, developers, researchers, product managers, content producers — should have some degree of fluency, and that the fluency improves over time, as the team continues to learn, use and evolve the language.

A well-chosen name can become a powerful tool for shaping your design system, since names affect how patterns will be used. And, of course, it is not only about the names themselves, but a shared approach to naming within your team.

The best names offer guidance or inspiration for where to use a specific pattern. It’s easy to remember there can be many minions (on a page) but only one boss. People enjoy using them and we don’t need to enforce guidelines because they come with the name. Even a few names like this can help make your vocabulary more compelling, and the team will be more likely to use it and contribute to it.

Like with any language, you need to use it to keep it alive. It needs to be part of day-to-day conversations. That’s why it’s important to make a conscious effort to keep referring to the patterns by the names you agreed on — no matter how bizarre this might sound.

In any team there will be people who are more fluent in your pattern language and more enthusiastic to work on the system, and they might naturally gravitate towards working with each other. But try to encourage them to work with everyone, so that they have an opportunity to share their knowledge and enthusiasm with people who are less immersed in the system. By spreading out the knowledge across an organization, a design system becomes more resilient.

The value of a glossary is not only in the tool it provides: it is also in the language practices it cultivates. By establishing and keeping a glossary, you get into a habit of vetting, discussing and articulating your language decisions as a team — you acknowledge that words matter.

Part One Summary

A design system is not built overnight, but shaped gradually, through our daily practices. If you are working on a digital product, the foundations of your system probably already exist. One way or another, interfaces are designed and built, and end up in front of users. Unless this process is entirely random, you have a system. The question is, what kind of system is it? Is it flexible and adaptable, or is it designed for one specific purpose? Is it cohesive or fragmented? Is it easy to work with, or is it time-consuming? Does your system thrive on freedom and autonomy, or is it strictly hierarchical?

Different design systems work in different ways. Your organization, team culture, design approach, the project, and even the physical space you’re in, will shape your system.

Chapter 6

A design system doesn’t start or end with building a pattern library. There are many factors that shape a system: the structure of your organization, your team culture, the type of product you’re working on, and your design approach, among other things.

Their goal is to reuse around 90% of the existing modules, so creation of new patterns is relatively infrequent.

The design language is documented on the internal website, DLS Guidelines, generated from the master Sketch file. Airbnb’s tools team built an automated process that generates screenshots and metadata about the components, and publishes them to the guidelines site. Needless to say, documentation is fully in sync with the Sketch file and the code.

There’s a lot of scope for creative experimentation with this kind of system. Because each page can be fine-tuned, it can adapt to specific contexts and use cases. The designs such a system generates can be coherent, but they’re not necessarily perfectly consistent.

…they emphasize that even with a pattern library in place, patterns are not going to drive the design. “Design acumen and sensitivity to context will always come first, even if it means that in some cases patterns will be ignored or modified,” says Michael McWatters.

It can seem that strictness is related to company size — younger smaller systems tend to be (and can get away with) being looser, to allow more freedom and experimentation. As a system grows, it becomes stricter. But maybe it’s not as simple as that. I once worked in a small team with a brilliant but authoritarian creative director, who closely monitored all design output. It was a small but very strict system. On the other hand, you can imagine a larger company having a loosely set up system, to encourage each team to experiment and make their own decisions. Perhaps it’s not so much to do with the size, but a team’s approach and their priorities.

People need to understand the rules and be able to challenge them. If there’s no understanding, rules will be ignored or overridden.

To have a simple, flexible system like TED’s, everyone on the team needs to be fully aligned on a product’s purpose and the design approach, which both need to be ingrained deeply into their culture. Even a loosely set up system needs a solid foundation.

Our conversations about design systems on the web have been in favor of modularity and standardization of components. We talk about how patterns should be modular and reusable, how everything should be just like Lego. But the extent of modularity should depend on your team and your product.

…more modular is not always better. The extent of modularity should depend on what you’re trying to achieve.

With modular design the expectation is that you can mix and match the parts, and they should fit perfectly together. But sometimes people combine modules in ways that don’t work as a whole. And paradoxically, even though there is a lot of consistency across the modules, there is little coherence in the overall experience. To prevent that, we should focus not only on the modules, but also on the connections between them: the rules of how they relate to one another, their relative importance (such as visual loudness), their role in the overall user journey, their hierarchy in the overall composition.

…it wasn’t only a change in direction — it was also a cultural shift.

At the heart of every effective design system aren’t the tools, but the shared design knowledge about what makes good design and UX for your particular team and your particular product. If that knowledge is clear, everything else will follow.

Chapter 7

But to make a real difference, working on a design system as a side project is not enough. You need widespread support — not only from your peers but the senior stakeholders in the business.

In the long run, modules should get better the more they are used. Different teams come up with different use cases and solutions to meet them. By improving individual components, the whole system becomes more robust and easier to maintain. And the less time a team spends fixing bugs and untangling messy code, the more time they have to work on things that bring value to their users and the business.

Having clear goals and milestones also helps manage expectations in the rest of the company. A design system is a long-term investment — its value increases gradually over time. It’s important that people expect to see gradual and steady improvements rather than quick dramatic ones.

Documenting your progress in an open and honest way is a powerful way to help your team learn and stay motivated.

…we consider the big picture first, and then deconstruct the interface into smaller parts. Approaching it this way helps us think not only of individual modules but also how they work together, and how they help to achieve the purpose of the product.

Chapter 8

Even if a screen supports several behaviors, the most important actions should be clear and not in conflict with one another.

Behaviors should be meaningful and work from the user’s perspective, as well as the business’s.

With variants, you would normally have a default pattern with the core styles. Variants would have additional styles. It’s important to know which features are core to the pattern, and which are specific to the variants. Then you can predict how a change in one of them will affect the others.

Sometimes modules are named in the front-end but naming is also a UX decision and should be made collaboratively at the design stage. Names need to take the content type into consideration but shouldn’t be based solely on the content. Effective names guide usage and reduce the chances of duplicate patterns.

To avoid confusion and misuse of these essential elements, it’s important to agree on their definitions. What are the shared meanings of “button” and “link” in your team? What are the basic guidelines for their usage?

In Marvel’s design system11, “flat” buttons are used to signify “necessary or mandatory actions”; “ghost” buttons are used to signify “optional, infrequent or subtle actions.” Flat buttons can be used alongside each other, when actions are equally important. I like this distinction because it’s simple, clear, and specific to the button’s purpose.

Chapter 9

A set of shared colors is not enough — you also need a shared use of color in the context of the product.

Think not only about the properties but high-level principles, combinations of different elements, and the relationships between them. For instance, instead of simply listing the colors, describe the proportions between them…

What matters is that you agree on the use of color across the interface.

Considering purpose first means that you’re not only adjusting variations of the same color, but sometimes will change the way color is used.

Sometimes you need to have more options, particularly if there are multiple themes, or if you’re dealing with data visualization. But it’s important to avoid including the colors just to add more variety to your palette. The more choices there are, the more complex the system is, then the harder it is to achieve consistent use of color. Start with only what you need and build on it.

To make sure voice and tone are expressed consistently and purposefully, design, brand and marketing teams need to coordinate their efforts when defining patterns.

Each style should be approached as a system in its own right — typography system, layout system, color system, and so on. They should be interconnected and directed towards achieving a larger purpose — to help shape how a product is perceived.

Chapter 10

In the experience of every team I spoke to, multidisciplinary pattern libraries are more resilient and enduring. They facilitate a shared language across the organization and bring value to everyone. Conversely, a pattern library built to serve the needs of one discipline is more fragile.

Similarly, patterns designed without the content discipline’s perspective can fall apart in everyday use. We end up designing patterns that are too closely tied to specific content, such as a module where an extra line of copy would push an important call to action below the visible area. Or we force content into patterns that aren’t designed for it, compromising both content and design.

Switching our focus to the content of the library made a big difference — both to our progress, and the team’s morale.

The team was able to get down all the core patterns and their definitions quickly, instead of being held back by build and design constraints.

The findability of modules is one of the greatest barriers to pattern library adoption. If team members don’t know that a pattern exists or can’t find what they need, they are likely to create a new one or go outside the pattern system.

But it’s important to remember that atomic design (or any other methodology) might not be right for you right out of the box.

Find a structure that’s right for your team. If it doesn’t work, if people struggle to find what they’re looking for, continue experimenting with different approaches. This can take time. The phrase I hear the most from all the teams with effective patterns libraries is that their “work is never done.

Elements are added only when they’re reused. Some teams add modules only on the second, or even third use. The idea is that an element has to prove itself as a pattern before being added to the system, which helps to keep the pattern library lean. With this approach it’s important to have visibility of everything being created and effective communication across teams. A log of undocumented patterns should also be kept, so the team has full visibility of what’s available, even if it’s not in the pattern library.

If there’s a dedicated design systems team, it’s important to agree on their role, as well as the process for managing contributions. A systems team can have the role of a curator or a producer, and many companies use a combination of both.

In both cases it’s important that the systems team are seen as partners, rather than police.

Code, design and the pattern library are facets of the same system. Treating it that way makes it more robust, because the system is supported from multiple angles. This doesn’t necessarily mean that the patterns must be fully synchronized. What’s important is that the team practises the same approach across the facets — to naming, structure and understanding of the purpose.

Conclusion

Many aspects of our lives can now be managed online, from buying groceries and paying bills, to finding a date or completing a degree. As architects of design systems, we play an important part in shaping the digital world. Pattern language gave us a format for thinking about design — and it also gave us a challenge: do the patterns we create have a positive impact on human life? How do we know if they do? How do we continuously test that?