How and why to create a pattern library

Ensuring a website is consistent and easy to maintain are two of the biggest headaches faced by larger organisations. Fortunately pattern libraries can help.

Play

Whether working for a large corporation like Nestle, a higher education institution like the University of Strathclyde or a big charity such as the Environmental Defence Fund, I increasingly find myself turning to pattern libraries as the solution to the particular problems faced by these bigger websites. But what is a pattern library, why do you need one and how do you go about creating them?

What is a pattern library?

A pattern library is a collection of user interface design patterns. The site UI-Patterns described these user interface design patterns as:

Recurring solutions that solve common design problems.

Still confused? Well, that is really not surprising. Web designers like to make things sound more complicated than they really are!

Essentially a pattern library is a collection of design elements that appear multiple times across a site. Typical examples might include:

  • Slideshows
  • Navigation
  • Social media features
  • News listings
  • Related links
  • Carousels

The list could and does go on.

A pattern library, documents all of these ‘patterns’ (also often known as modules) and defines how they behave, what they look like and how they are coded.

Examples of Pattern libraries that you might want to check out include:

Of course, pattern libraries do not spontaneously appear, they need creating and that takes effort. Why then is it worth your time to create a pattern library?

Why you need a pattern library?

Once a website reaches a certain size and complexity (especially if a number of sub-sites are involved) the argument for a pattern library are overwhelming. These benefits are three fold:

Consistency in user experience

Big sites are developed by different people over a prolonged period of time, and revised regularly. This almost always leads to a fragmented user experience unless there is something in place to ensure consistency.

University of Cambridge website
Like many large websites the University of Cambridge consists of radical differences in user interface and a lack of consistency.

You only need to visit any higher education site to see examples of this. Navigation shifts position, form elements are formatted differently and even typography changes. This happens because it is easier to guess how a button might look than find out how it was styled in the past. A pattern library changes this by offering an easy way to duplicate existing design and functionality on any page of the site.

Reusability

Large organisations often have multiple web teams working across the company reporting into different departments. Often these teams work largely in isolation and so end up reinventing the wheel at considerable cost.

Having a central pattern library developed in collaboration between all of these web professionals means that functionality and design elements can be reused, so keeping costs down.

If one web developer creates a new pattern for a specific requirement in their area of responsibility, this can now be shared with the whole group and is also permanently available for future projects.

Examples of Googles redesign
Google Apps used to have very different user experiences because they were produced by different teams across the organisation. However, this changed once they started working together.

Once the majority of patterns are in place creating a new site or sub section becomes a simple matter of combining these patterns, in much the same way you build something out of existing lego bricks.

Maintainability

Having a consistent pattern library that everybody works from makes maintenance easier too. When elements are always coded in the same way, it is much easier for a developer to work on somebody else’s code. Also when a new developer comes in they can get up to speed much quicker by looking at the pattern library.

Hopefully you can now see the value of building a pattern library. The final question therefore becomes – how do you build one?

Tips for creating a pattern library

As you will have seen from the examples posted above, there is nothing particularly special about a pattern library. It is essentially a collection of elements, their associated code and a few notes.

How you implement a pattern library is entirely up to you. However, I thought it maybe useful if I share a few of the things I have discovered about working with pattern libraries.

Start Early

The temptation is to only document a pattern library once you have built the site. However, this somewhat undermines the point of having a pattern library.

At Headscape we try to put the skeleton of a pattern library together before a line of code is written. We create a library featuring wireframes of individual patterns, notes on how that pattern works and other considerations, while still at the prototyping phase. This is helpful for the design and developer, acting as a functional specification of sorts.

Example early pattern library
A pattern library does not require final code and design. Instead start it early when you have nothing but a few wireframes to work with.

As code is written this pattern can then get fleshed out with the final design and associated code. This approach is considerably easier than putting everything together at the end and also allows you to quickly reuse patterns as you build the site.

Consider responsiveness

An important consideration these days is how a pattern adapts to different devices. When showing the visual appearance of a pattern, make sure you show how it responds at different sizes.

This is not just useful for mobile devices, but also for when the pattern is used in different contexts. For example a news listing may include a thumbnail when being displayed in the main body of a page, but drops the thumbnail when being showed in a narrower side column.

Define your components

Many patterns can be made up of multiple components. For example a news listing could include:

  • A title
  • A description
  • A thumbnail
  • The date
  • The author

When defining a pattern it is important to list these components and also whether they are required or not. For example do you need a description on a news listing? If not, what happens to the design if a description is not present?

Careful consideration needs to be given to these various permutations as they can become quite complex if not thought through.

How does it function

If a pattern library is also going to act as a functional specification for developers, consideration needs to be given to how patterns function. Where is the data coming from to populate fields? What happens when the user clicks a button or link? How does a carousel operate on a mobile device? These kinds of functional questions are important when it comes to implementing patterns. Answering these questions also forces the designer and developer to work closely together to come to an agreement, and prevents the designer just throwing a design over the wall.

Don’t forget accessibility

In this era of web applications accessibility is often forgotten. That is why I always include accessibility considerations in my pattern libraries. There will always be a section in a pattern definition where I make notes that a pattern should be keyboard accessible or can be interpreted by a screen reader.

Think about where you keep the code

A lot of pattern libraries display their code inline. However, I am not convinced this is a good idea. I believe there should be a single repository for code that is always kept up to date and that this repository should be in source control. By having code in multiple places it requires more maintenance and it would be easy for somebody to use the wrong code snippets for a pattern.

Personally, I prefer to include links across to source control, but whatever you decide make sure you have one definitive source.

Consider customisation

Finally, think about whether patterns can be customised and to what extent. This will depend on how your brand operates. If you have a single consistent brand, then you probably want to offer very little in the way of customisation. However, if like the BBC you run multiple brands then it will be important that the appearance of patterns can be customised to match those brands.

BBC websites
Although the BBC has a single pattern library those patterns look different between across their different brands.

One of my favourite tools

I have to confess I am a huge fan of pattern libraries and they are something I insist on for the majority of projects I am involved in. Yes, they do take some work to setup but ultimately it is worth the effort.

What I am interested to know is your experience of pattern libraries? Do you use them and if so how do you approach them? What does your pattern library contain, and if you don’t use them what are your reasons? Let’s talk patterns in the comments below.

  • Paul Hill

    Very good article, Paul. I’m about to create a pattern library for the brands I work on. I was wondering what you considered the best tool for this? A simple site much like Starbucks or are there any tools for quickly creating one? You mention these are time consuming, but do you have any advice on getting one set up rapidly and then adding to it as we go along? Thanks.

  • Jason Hunt

    Agreed Paul, these can be invaluable – would you be prepared/able to show one of yours that you have created recently?

  • isar21

    There are some CSS based tools / frameworks which allow to extract fragments of live code in order to display them as a part of a pattern lib. I believe it is critical to tie the live code with the lib, otherwise the doors of un-sync hell will swing open. To put it simple: The lib always has to display the live patterns. Otherwise its just another kind of a style-guide.

    Beside that: I recommend Mr.Frosts ideas on Atomic Web-Design: http://bradfrostweb.com/blog/post/atomic-web-design/

    As designers we have to change our why of thinking in the direction of how architects plan and think, and finally away from the way stylists think. The will be still plenty of room for decoration. Once the house is built.

  • DJ

    We’ve developed our own pattern library for building sites at UCL. What I’ve learned so far is:

    - I’m really glad we’ve done it! We’re already reaping the benefits in terms of consistency, maintainability, speed of delivery, etc.
    - It must be a living, breathing thing that’s constantly being improved & evolving. If it’s in immovable ‘cast in stone’ thing, it will probably fail. We want to encourage collaboration amongst our own developers, & with devs from other agencies who work with us, so we’ve put our code is a public github repo. However, support & development can be time-consuming, and it’s a far greater commitment than we’d foreseen. This is doubly true if, as in our case, you need to integrate your pattern library into a CMS.
    - Adoption is crucial, and clear communication of what it is, and how it can be applied, is crucial for adoption. We’ve given ours a brand name (‘Indigo’), which has really helped it gain traction within the institution – see http://www.ucl.ac.uk/indigo/
    - Positioning the pattern library has proved tricky. How low do we set the barrier to entry? Is this thing for front-end developers only, and should we require intimate knowledge of Sass, Grunt, AMD JavaScript, etc to use it? Or should it be simple to pick up & use? We’ve yet to resolve this one.
    - There’s an ongoing tension between creativity vs. control. How far can our design language be stretched by UCL websites without losing their sense of ‘family resemblance’? And are there use cases in which it’s ok to completely break the rules?

Headscape

Boagworld