Creating Pattern Libraries

What is a Pattern?

Design systems empower product teams to create consistent experiences, especially when many teams are building features or capabilities within a product. The foundational layer of these systems includes tokens and components that provide the DNA and building blocks of the experiences. A pattern, in its simplest form, is an arrangement of components. When a product grows into a large surface area, patterns become the primary driver of consistency, helping teams implement experiences beyond the component level.

Examples of Patterns

Simple pattern: Empty state

Within an interface, empty states can be informative to new users onboarding to a product. They can provide context, and perhaps a call-to-action to propel users in creating objects. This pattern is typically a combination of text, a button, and maybe an icon.

Complex pattern: Onboarding

Onboarding patterns are generally complex because of the considerations involved. Generally, onboarding tends to span multiple screens and experiences and may require more guidance. For example, a product may utilize a wizard experience to create focus. Or, perhaps portions of the experience are inaccessible until certain steps are completed. Because of the complexity, this pattern requires a lot of documentation, components, and considerations.

Why is a Pattern Library Helpful?

Pattern libraries remove the guesswork for product designers who largely are aiming to solve their team challenges. When product designers don’t have a robust pattern library, a lot of risk is introduced into the experience as each team can make siloed decisions and fragment areas that could be consistent.

Our users are humans, and the human eye is constantly looking for patterns. By utilizing patterns, we can reduce the cognitive load of the user by providing them consistent means to achieve various goals. When done right, users gain confidence and know exactly what to expect as they navigate throughout a product.

Getting Started:

Understand Your Design Team

A pattern library is first consumed by product designers. In order to provide the best patterns, I recommend taking time to understand your product design team. Here’s a set of questions you could ask that would help gain insight:

• Is your team comfortable working with design systems?
• How does your team work in Figma? Do they copy and paste elements from other files?
• How knowledgeable is your team with the design system they use?

Unearthing these answers is helpful in creating an approach. In my years of experience creating patterns, there’s always an aspect of educating my team, whether that is coaching in systems thinking, or providing more resources for the design system to get designers comfortable.

Understand Your Product & Engineering Teams

In addition to understanding your design team, it’s also helpful to understand product teams. Here’s a set of questions you could ask that would help gain insight:

• Are their supplemental components team build to power their individual experiences?
• How comfortable are the teams using the design system? Are the resources provided enough to build confidence, or are there resources that could be added?

Audit Existing Experiences

The easiest place to start with patterns is to audit the entire product or family of products. This is especially helpful if you are a new designer in the organization and need to quickly understand the state of patterns. When judging experiences, I recommend Jakob Nielsen’s 10 Usability Heuristics for User Interface Design. These heuristics provide general rules for looking at interfaces and can be helpful in identifying improvements to pursue.

My personal process is to utilize FigJam and screenshot everything I see. By creating a visual log of these heuristic violations, you set yourself up for having assets to help tell the story of why patterns are important.

Activity: pattern identification & prioritization

Once an audit is complete, the next step is to begin identifying patterns. The most effective method is to collaborate within your product design team to identify exactly what patterns could be pursued. To facilitate this activity, I utilize a template I’ve created that is a blend of asynchronous and synchronous exercises.

Step 1: asynchronous capture

The goal of the capture phase is to have individual designers document through screenshots areas they reuse that have no formal component and/or pattern. I also ask designers to try and give the pattern a name, for example: wizard footer, page headers, cards.

Step 2: synchronous review & creating a single list

As a group, we review each designer’s capture. This lets the designer speak to their decisions and allows the group to ask questions. Generally, designers begin to see trends or multiple designers describing the same pattern. Once reviewed, we create a singular list of patterns identified.

Step 3: synchronous prioritizing

This exercise generally yields dozens of patterns to pursue. In order to create a path forward, prioritizing the patterns can be helpful in creating a backlog for the team to tackle. For this portion of the exercise, I recommend inviting engineering partners, especially ones that focus on the front-end.

My method for prioritizing is to have us as a group plot each pattern on 2 axes:

1. Occurrence: is the pattern common or rare?
2. Complexity: is the pattern on the simple side, or is it more complex?

Working as a group, we plot each pattern. I rely on product designers to help understand the occurrence, and engineers to help us understand complexity. I also encourage asking engineers for each pattern what could impact the complexity.

Final output: prioritized patterns

The final output is a list of patterns that are prioritized. For priority, occurrence is the primary sort criteria, with complexity being a sub-sort of that group.

Designing new patterns

With the patterns identified and prioritized, it’s now time to create patterns. This is usually too much for a single person to tackle, and I encourage you to see this as a group activity. If done right, you gain the advantage of coaching your team into understanding what goes into creating and contributing a pattern to your design system.

Divvy out patterns across the team

To begin creating a library of patterns, I recommend taking all of your patterns that are high occurrence and assigning 1-2 patterns per team mate. Be conscious not to overload your designers, and certainly triage the patterns to what is most pressing for the product.

Designers should consider the following questions as they design solutions for the pattern:

• Why is this pattern necessary?
• Where does this pattern exist within the product?
• What variants of this pattern are needed?
• What guidance do designers need? This could be considerations, things to ask yourself, and content guidance.

Review pattern candidates as a team

Once draft patterns have been created, it’s time to review and provide feedback. This could be asynchronous or synchronous within product design critiques. This is the opportunity where the entire team can help shape and harden these patterns.

Documenting patterns

Once patterns have been cemented, it’s time to start thinking about how others access these patterns and the insights, considerations, and guidance.

Create Figma components

For utility, consider making each pattern a Figma component. The pattern may or may not be a code component, but by making a Figma component it becomes less likely that a designer will attempt to override aspects of the pattern and introduce fragmentation. The Figma components should live within a library, either the main library for the system, or a supplemental library.

Explore creating a code component

Much like a Figma component, a React component provides similar benefits in that it’s difficult for engineers to override key behaviors. It doesn’t always make sense to create a React component, but if your engineers see value in doing so, it’s an effective way to create guardrails.

Create documentation library

It’s rare that a designer or engineer can simply pick up a new pattern and know how to implement it. There are usually aspects of the pattern that need to be thought about. The documentation library serves this purpose, by creating a dedicated place that breaks down the pattern and examines the pieces. This documentation usually is best served living near your component documentation.

Questions to ask about the pattern to inspire what to document:

• Where should the pattern be used?
• What variants of the pattern exist and when should each be used?
• Are there content guidelines designers should consider?
• What are some implications of this pattern? What should a designer consider when using this pattern?
• What design system components compose this pattern?

Building new patterns

Patterns sometimes are good candidates for creating a React component. By doing so, engineers are able to efficiently and easily add the pattern to code, using a carefully scoped API that is difficult to override.

Things to think about when considering building a React component for a pattern:

• Is the pattern high occurrence? If so, by not having a component each team must carefully place components and style as designed.
• Is the API robust enough to not block a team? For example, if you design an empty state component that only supports 1 button, what happens if a team needs 2 buttons? Is that slow-down in velocity worth it? Or is composability important to provide flexibility?

If you go the route of building a React component, be sure to bundle the engineering considerations within your documentation library.

Maintaining the library

At the end of this exercise, you should have a library of patterns that can begin to be implemented. As the product grows, it’s likely that patterns need to evolve to meet new use cases. The most important consideration when evolving a pattern is to be cognizant of when a pattern gets too overloaded. When a pattern has too many variants, considerations, and documentation - it’s a sign that perhaps you should break up the patterns.

Evangelizing pattern changes

As your pattern library evolves, you’ll need a mechanism to ensure your design team knows what is new, changed, and removed. If you have a design system in place that has a release process, consider bundling patterns in with that process. If no process is set, consider making a slack channel to announce pattern changes, with links to the updated documentation.

Closing thoughts

Creating a pattern library has many benefits, but primarily it helps your product’s users understand interfaces and predict outcomes. If your product is a workhorse product, in that users spend a large chunk of their time within the product, patterns are critical in creating efficiencies. When done correctly, users glide through experiences knowing exactly what to expect.