“A design system is a set of interconnected patterns and shared practices organized to serve the purpose of a digital product.” —Anna Kholmatova, Design Systems (2017)
These are my notes from Anna Kholmatova’s book, Design Systems (2017), a great guide for creating a design system for digital products.
You can purchase the book here: https://www.smashingmagazine.com/ebooks/design-systems-ebook/
A pattern is a recurring, reusable solution used to solve a design problem. We use patterns to create an interface: flows, interactions, buttons, text fields, icons, colors, typography, etc. Interface elements are instances of design patterns. Established patterns make use of people’s existing mental models, allowing them to intuitively understand the design.
Contrast established patterns to new patterns. New patterns require people to learn something before making use of them. This additional effort makes new patterns relatively rare. Introducing a new pattern is one way to distinguish a product. That said, what makes a product distinct from competitors is not necessarily the novelty of its patterns, but the way in which patterns are combined to solve a problem.
In the context of design systems, patterns allow teams of people to follow a creative direction consistently and coherently. Design systems define and share patterns across teams. While an initial design often originates with an individual, scaling a design across multiple people requires a system everyone can follow. Having a shared language for discussing design patterns creates a mental model of what we are trying to achieve, enhancing collaboration.
Before investing in a design system, we should articulate the benefits to the business. A design system brings value in the form of:
One of the ways in which we define and share a design system is through a pattern library. The library organizes patterns, along with principles and guidelines for using them. Together, the visual and textual aspects of the library communicate the how and why of each pattern.
Pattern libraries contain our design patterns as well as the live code used to build them. These “living” libraries allow designers to interact with the actual components that make up the product interface. Similarly, the library gives developers concrete examples of the code necessary to implement the patterns.
While valuable, pattern libraries are not interchangeable with design systems. A pattern library is a tool for discovery and reasoning about the design system. A pattern library does not guarantee a cohesive design, because it is merely an implementation of the underlying design system.
A design system has naming patterns to improve organization and makes patterns memorable. This, in turn, encourages reuse and the extension of existing patterns rather than creating new patterns that do a similar thing in a slightly different way. Once it becomes easier to add a pattern to the design system than it is to find an existing pattern, the design system is disfunctional. Memorable naming is an important tool in this effort.
Using metaphors to name patterns is one way to make them memorable. For example, naming patterns after architectural elements helps designers envision the purpose behind a particular pattern. Just as a foundation supports and forms the base of a building’s strength, if we name our pattern “foundation”, that pattern should have a role as the primary supporting structure. Naming a pattern “spotlight” is another example: a promotional element designed to draw attention to a specific piece of content. These names are memorable and express the intended purpose of the pattern.
Creative metaphors will inspire other, similar names. Using the movie “Despicable Me” as inspiration, a small button might be a “minion” and a large button a “boss”. Similarly, a “whisper box” component, named to indicate it is an element that is not too distracting, might inspire a “boom box” component, an element that is more prominent. When the team has a mental model of the design system patterns, they are apt to utilize existing patterns when designing new portions of the interface.
Since applying an existing pattern to solve a design problem is a central goal of the pattern library, organizing patterns in a way that promotes discoverability is paramount. For a pattern library, this translates into navigation. Depending on what is most useful for our design system, there are a variety of ways to organize navigation:
Functional patterns are the concrete components of an interface: buttons, headers, form elements, menus. On the web, functional patterns always have a basis in HTML.
Rather than defining what a pattern is, describe what it does. For example, the noun “Course banner” is more restrictive than the verb “Get inspired to join a course”. By describing what patterns do, we broaden the set of problems our patterns solve. This keeps the size of the design system manageable.
Place patterns next to each other to define the scale between them. For instance, on a loudness scale, we have different patterns depending on the volume at which we intend to communicate a message to the user. This prevents patterns from being needlessly created, since we see we already have a pattern at a particular volume.
Perceptual patterns are descriptive styles that express and communicate the personality of a product. These styles include color, typography, iconography, shapes, and animations. On the web, perceptual patterns are typically CSS properties.
Mood boards splice together colors, typography, images, and layouts to explore different visual themes. Mood boards can be assembled physically, using cutouts from magazines and other printed material, or digitally, using a product like Pinterest. Designers use mood boards to experiment with what a brand might feel like overall. We can also use mood boards to focus on exploring specific parts of a brand, such as color or typography.
After deciding on a general brand direction, style tiles offer specific alternatives. Styles tiles are useful for engaging with stakeholders to gauge their reaction toward various implementations of the brand. Comparing and contrasting style tiles helps choose one direction over another.
Just as a hodgepodge of patterns weakens a brand, overemphasis on uniformity can stifle it. Perfect consistency is generic and rigid. A good design system strikes a balance between consistency and creative expression of the brand.
Small interactions can serve as differentiators, giving the brand a distinct feel. Elegant animations or a catchy sound (e.g., “You’ve got mail!”) deepen the connection between users and the brand. This makes it worthwhile to invest in signature moments while being careful not to overdo it.
A design system contains patterns beyond functional and perceptual. These include user flows (such as the completion of forms with errors and success messages); domain-oriented design patterns (like learning patterns for educational systems); and persuasive sales patterns.
The first step in establishing a design system is to define the purpose and ethos of the product. The purpose is the reason behind creating the product, and the ethos is its characteristic spirit. If we are designing a 10-minute recipe product, the purpose is to cook creative meals in 10 minutes. Our ethos might be “simple and natural”. Our functional and perceptual design choices will flow from the chosen purpose and ethos.
Having decided upon a purpose and ethos, the next step is developing principles to inform our choices of functional and perceptual patterns. Kholmatova (2017) recommends four practices when determining principles:
One of TED’s design principles is “Be timeless, not cutting edge.” (Kholmatova, 2017). The word timeless captures TED’s brand and design approach. Therefore, TED is not going to adopt a new technology or design approach for the sake of following a trend. For example, TED will not introduce a parallax effect, even if it’s trendy, if the parallax effect has no proven benefits to users.
To get its point across, a principle should be defined in the context of an actual problem the design system tries to solve. Kholmatova (2017) gives the following examples in her book:
Vague: “Make it clear.” Practical: “No needless parts. Every element must have a purpose. If we can’t explain what an element is for, most likely it should not be there.”
Vague: “Make it simple.” Practical: “Make it unbreakable. Just like a children’s toy, make sure it is designed for exploration and impossible to mis-tap.”
Achieving a particular goal means saying no to other, competing goals. We must work out priorities, especially when there are competing factors to consider. Salesforce’s design system states its principles are: “Clarity. Efficiency. Consistency. Beauty.” (Kholmatova, 2017). These principles are ranked in order, communicating to the team what should take priority when design decisions conflict.
Another aspect of point of view is the voice of the product. Do we intend to communicate messages in a playful, summarized manner or in a professional, detailed tone? The voice of the product should be consistent among design patterns, text, audio, and video. Textual information should follow a consistent style guide, e.g., AP Style Guide.
The team should be able to define the design principles instantly. The ideal number of principles is three to five. Any more and it will be difficult to remember the principles or find balance between competing priorities. Limiting the number of principles helps unify the team without being a restrictive laundry list. Most teams and products benefit from room for creativity—our team is made up of people, not robots.
When it comes to designing the patterns themselves, a key choice is whether to be modular or integrated. Modular patterns are designed to be combined with each other. An integrated pattern is designed to solve a particular problem without worrying about how it might be used to solve other problems later.
Advantages of the modular approach:
Advantages of the integrated approach:
Disadvantages of the modular approach:
Disadvantages of the integrated approach:
The modular approach is best suited for products that:
Examples include large sites for e-commerce, news, e-learning, finance, and government—basically anything that needs to scale, evolve, and cope with changing user needs.
The integrated approach is best for products that:
Examples include websites for creative events, one-off marketing campaigns, and creative portfolios.
In terms of who builds the design system, organizations tend to fall somewhere between a centralized and distributed team structure. In the centralized approach, a dedicated team of designers and engineers develops and curates the system. In the distributed approach, anyone contributes to the system and there is no one specifically assigned to work on it.
The centralized approach has the advantage of strong ownership and creative direction. Because a dedicated team is responsible for the design system, people intimately familiar with the purpose, ethos, and principles veto patterns that do not fit. The resulting design system tends to be focused and opinionated. Design-led companies, such as Apple and Airbnb, employ a centralized team structure (Kholmatova, 2017).
The distributed approach relies on the entire team to contribute to and maintain the design system. The resulting system tends to be resilient and agile. If one team misses something, another one can fill the gap. Small teams, such as TED, often employ the distributed approach (Kholmatova, 2017) because they do not want to dedicate resources to the design system.
Each approach has its downsides. The centralized approach may suffer from bottlenecks since it is limited by the throughput of a dedicated team. This could slow down the entire product development lifecycle. The design system is also susceptible to significant revision after personnel changes since creative direction is concentrated in one or a few individuals. Even with a dedicated team, the centralized approach benefits from meeting with stakeholders for suggestions and feedback, as well as accepting submissions from across the organization.
The distributed approach suffers from diluted creative direction. Because everyone is responsible for the design system, this often means no one is responsible for it. As a result, the design system may lack coherence. With no one to veto contributions, the number of patterns explodes. Even though distributed contributions are an advantage of this approach, it can benefit from a nominating a curator. The curator has final say over whether a contribution fits into the design system.
To get started building a design system, it helps to conduct an inventory of what currently exists. This may be the actual product, or it may be sketches of a proposed product. This process should take place after the foundational UX work—user research, content strategy, information architecture, and design direction—has been worked out.
Establish a team of 4-8 people. The teams should include designers, frontend engineers, a backend engineer, someone with a content background, and a product manager. If a larger group needs to be involved, start with the smaller group and have breakout sessions, where a representative from the core team collects feedback from other stakeholders.
Identify no more than 12 screens without which the product would not exist. These can be sketches or actual screenshots of the interface. Print two copies of each screen. We will use the first copy to chart out a typical user journey and the second copy for grouping patterns.
Identify the key behaviors at each step of the user journey. In her book, Kholmatova (2017) uses the example of a library website, where the key behaviors are:
Note situations where multiple behaviors are present on the same screen. If a screen supports multiple behaviors, it should make the most important behavior clear. It may be necessary to pare down the displayed behaviors in order not to confuse or overwhelm users.
Having defined the high-level behaviors, next, break down each behavior into specific actions. Each action feeds into a behavior. Write down actions next to where they occur on each screen. For example, “book discovery” actions may be:
Look for inconsistencies between screens performing the same action.
Using the second set of printouts, cut out all elements that support the same action. For instance, “view a book” may be accessible from the recommendation list, the catalog search results, and in the user’s wish list. Similarly, we may offer a “refine list” action to filter data presented in a list, with various types of lists present on different screens.
Within each group of elements, decide how to divide them into patterns. Deciding how to group elements depends on how specific we want a particular pattern to be.
For example, the library may have unique exhibitions and it may also have recurring events. We could make a very generic “event” pattern, relaying the characteristics common to any event. Alternatively, we may choose to have a separate pattern for unique exhibitions, giving them a poster-like feel to draw attention to them. The choice depends on whether we want users to perceive exhibitions differently from events.
To keep the number of patterns manageable, we may combine variations of an action into a single pattern. Combining is determined by whether the existing variations need to look or behave differently. When the look and behavior differences are significant enough, we create two entirely separate patterns. As an in-between option, we may create a variant of a pattern. Keep in mind the more patterns we have, the more difficult the design system is to use. It is important to limit ourselves to patterns that have a truly unique purpose.
When identifying candidates for combination, ask yourself, “If I make a change to this page, do I want the other pages to change in the same way?” For instance, if we decide to add animation to books we want to showcase, do we want the animation to apply to the books in a list?
When creating variants, it is important to delineate shared styles from styles affecting only the variant. This way, it is obvious when we change one of the core styles that it will change styles everywhere.
After grouping large patterns, continue the pattern evaluation process for more granular patterns, such as:
Perceptual patterns (color, contrast, typography, etc.) combine with functional patterns to give the product a distinctive look and feel. Many design systems have a standard color palette and typography set. However, without knowing the context in which certain colors and typography should be used, we will not create a cohesive design. For example, we might use blue to indicate a navigation link. If we then have a blue heading that does not navigate, this will confuse users. More than a shared color palette and typography set, we need a shared use of color and typography.
To take stock of the current perceptual patterns, ask each person on the team to write down the most memorable and distinct elements of the product. These are signature patterns. Signature patterns might include:
After completing the signature patterns exercise, catalogue individual patterns. Systemize each pattern using these four steps:
Patterns to inventory include:
Identify areas of overlap amongst patterns and place them into groups. For example, we may use specific colors and animation to build interactive states. Note disjoint areas where the same pattern is used to express a different intent and decide whether this is a potential source of confusion.
It can be difficult to get started categorizing perceptual patterns. Let us use colors as an example. Group colors into categories by purpose. Within each purpose, specify a subtype, give an example usage from the product, specify the color code, and the choose feeling we intend to evoke by using this color.
Having categorized a set of purposes and associated colors, it is time to scan for unnecessary colors. Are there multiple shades of a color that have the same purpose and feel? Choose a single color to reduce complexity. If we need multiple shades of a color, specify a base color and define additional shading in percentage terms, e.g., 20% darker, 20% lighter. Specifying a base along with increments also works for typography (base font size), spacing (base measurement unit), and animations (animation duration).
When choosing colors, we should consider contrast to ensure the product is accessible. Tools such as Color Safe and Tanaguru Contrast Finder aid in generating contrast-compliant color combinations.
Next, look for associations between the color and other perceptual patterns. Combinations of patterns are what give the product its distinct look and feel.
The final step is ensuring the patterns match our guiding principles. If our guiding principle is “timeless, not cutting edge” and we notice a gaudy color and glowing animation on a button, we should refine this pattern. If one of our principles is simplicity, we should not have navigation menus with many options and countless nested menus. Deciding what does not belong in the design system is as important as deciding what to add.
When adding new patterns to the design system, the first step is agreeing on what constitutes a design pattern. Two common approaches are:
Every new pattern on the site is first added to the pattern library. This approach optimizes for coherence and visibility of all patterns in the product. It also encourages designing components in a reusable way from the beginning, since a key goal of the pattern library is reusability.
Patterns are added only when they are reused. This keeps the pattern library lean. It does, however, risk reducing the coherence of the design as the number of undocumented patterns increases. We may benefit from faster initial development of patterns since they can be purpose-built for a particular use case. But it is likely we will need to refactor them if we want to add them to the design system.
Before adding a new pattern, we need an established process to check if a similar pattern already exists. Keep in mind this may mean introducing a variant of an existing pattern. This process reduces the chance of introducing duplicate patterns.
Establishing a design system enables teams to introduce new features faster while maintaining a cohesive user experience. The combinations of functional and perceptual patterns create a distinct look and feel. Over time, we must curate the design system to ensure its patterns match our purpose, ethos, and principles. Creating a pattern library provides an interactive model of the patterns that constitute the design system. Memorable pattern names and pattern library navigation are critical aspects of making the design system usable. While organizations have implemented design systems in a variety of ways, the strategies and processes outlined here are common to their success.
Kholmatova, A. (2017). Design Systems: A practical guide to creating design languages for digital products. Smashing Media AG. https://www.smashingmagazine.com/printed-books/design-systems/
Osborne, T. (2016, January 6). Using Visual Loudness for Better Wayfinding. Viget Labs, LLC. https://www.viget.com/articles/visual-loudness/
Salesforce. (n.d.). Accordion. Retrieved June 9, 2021. https://www.lightningdesignsystem.com/components/accordion/