Adam Johnston

Working with Pattern Libraries

Reading time ~6 mins

For a few years now I’ve had the benefit of building, maintaining and using pattern libraries in the workplace. I’ve seen them connect developers and designers, allow the sharing of insights through the wider team and lead to a more cohesive and collaborative product. With modular, component based architecture becoming ever more popular, pattern libraries are invaluable.

A pattern library is a collection of reusable components that can be used together to create an application. I tend to focus on web applications but a pattern library shouldn’t be limited to the web. I like to imagine a pattern library as a big box of Lego, full of blocks of different shapes, colours and usages that I can build lots of cool things with.

An example would be Mailchimp’s excellent pattern library and FutureLearn’s extensive pattern library. Both split their libraries modularly. Grid system, typography, forms, navigation and more. They show use cases, markup and notes left by designers and developers. A developer implementing a component into an app has all the information they need.

The way I approach creating a new pattern library is to look at the existing product (if there is one) or designs and discern common patterns, hence a pattern library. Patterns of an app are pieces that look or function very similar to other elements. I split these parts out as a component and begin to normalise them. Here’s a rather specific example:

Very rough and specific but hopefully a useful

Even at this early stage we can see a pattern (with more designs we’d certainly see more). The buttons are slightly different but both look and work in a similar way, as in I click one and it does some sort of action.

My approach would be to give this pattern a name, e.g. .btn, .action-button or simply .button and this naming should be agreed by the team. Then I’d discuss this with a designer. I’d try and reach an agreement on what could be normalised, such as border-radius, background-color or height.

Doing so makes the naming of components become much easier. When it comes to CSS styling, this process aids with BEM naming or through CSS module composition. We might end up something like this:

$button-colours: (
  default: #2a8fbd,
);

.action-button {
  @include button-reset;

  height: 2rem;
  padding: 0 0.5rem;
  background: map-get($button-colours, default);
  border: 1px solid darken(map-get($button-colours, default), 10%);
  border-radius: px2rem(3px);

  &--square {
    width: 2rem;
  }

  &--large {
    height: 3.5rem;
    padding: 0 1rem;
  }

  &--square#{&}--large {
    width: 3.5rem;
  }
}

Once you have your pattern library, at the very minimum it needs to be spread throughout the company. Both designers and developers need to be aware of it and work closely with it. This leads to a shared language between designers and developers but also other members of the team.

If a designer is creating a new section of an app, they should be wire-framing or prototyping with components from the pattern library, not creating completely new designs. Iterations and feedback can be made faster and functionality isn’t a concern as it will already have been defined.

For developers, the creation of reusable components means that concerns about the look and functionality would have been previously addressed so the implementation and testing can be the focus.

These are what I believe are some great benefits that come from the use of a pattern library.

  • A shared language throughout the company. I think this can be understated but when everyone shares the same language, communication is much easier.
  • Spend more time prototyping, implementing, testing and iterating. When you understand the patterns it takes less time to prototype and implement aspects of an app. Adding a new section? You shouldn’t need to worry about how buttons and inputs look and work.
  • It acts as documentation. Giving examples, markup, use cases and notes makes it much easier to document the architecture of an app and is especially useful for new developers joining the team.
  • It’s an ongoing process. A pattern library should never be finished. Components can safely be improved upon or redesigned within the confines of the pattern library before affecting the app itself.
  • Visual regression testing. Visual regression testing can be made on each component individually. You have a greater safety net when making changes to a component since you will have more granular diffing.
  • Style in isolation. Because your components is a single piece of an app you should style them on their own. A component should look good and function correctly without the context of other components.

Here a few other articles you may find useful in your learning of pattern libraries.