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:
- Social media features
- News listings
- Related links
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.
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.
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.
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.
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.
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.
I tend to put the skeleton of a pattern library together before a line of code is written. I 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.
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.
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.
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.
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.