When does a pattern become a pattern?
If you’re embarking on the challenge of creating a new pattern library or design system, the task may seem daunting and even though these concepts are now fairly well-established in 2020, there are still grey areas aplenty. What is the difference between a pattern library and a design system? How do you decide what should become a pattern within your new library and what should be treated as a standalone design solution?
What do I mean by a ‘pattern library’?
When I talk about pattern libraries, I’m actually talking about a lightweight design system, but everyone has their own idea of exactly what is included in either of these things. I think a pattern library sounds like something tangible to stakeholders and end users who don’t fall into the design or development bracket. It’s easy to visualise from the word ‘pattern’ that we’re picking out the consistent elements of the design to form a common language as well as vastly reducing development effort with reusable components.
What do I mean by a ‘design system’?
A ‘design system’ to me has always been a more mystical and technical beast; a catch-all umbrella to cover everything that goes into the design process. It can include anything from:
tone of voice guidelines for copywriters,
to guidelines for developers making form fields more accessible,
to rules for designers around how to continue a web-based brand into the realms of print,
to process flows that anyone can use to ensure the system is being properly maintained.
In my mind, a design system is BIG. It’s something that will be used by hundreds of people. Of course it doesn’t have to be, but if it’s just being used by a handful of designers and the office dog then realistically a well-crafted pattern library should cover the bulk of what you’re looking for. It will also save you six months to a year of documenting in meticulous detail something that could be out of date next week. What’s more, you can update your library in a much more agile way. I’m not saying that design systems don’t have a purpose — I adore a beautifully crafted design system and such a system can transform design collaboration on a global scale. But it can also be like opening Pandora’s box.
You want neatly categorised sections of brand elements (colours, logos, illustrations), components and templates. Brief annotations are handy, but you probably don’t want an essay around when to use radio buttons vs. when to use drop-downs. You want the design of both of those things, shown in their different states, on different devices and within a larger form template. Using a tool such as Zeplin, you don’t necessarily even need to annotate the colours, dimensions, etc. Your developers will have everything they need to turn it into a living library of patterns and your designers can use a combination of this and your source Sketch / Adobe XD file to drag and drop the elements they need.
UXPin’s explanation of the difference between a design system, a style guide and a pattern library: https://www.uxpin.com/studio/blog/design-systems-vs-pattern-libraries-vs-style-guides-whats-difference/
This diagram from UXPin is quite a nice way to visualise the difference between a design system and a pattern library, but I think you can blur the lines more than this. Whilst a pattern library can be as basic as a snapshot of templates, modules, components and elements, I do think any pattern library worth its salt should also document the colour palettes, type scales and icons so that you can easily reference those throughout the designs. If those basic building blocks are included then you can very quickly start to grasp what the repeatable elements are within the pattern library at a very granular level. Including a basic overview of your core breakpoints and grid systems is also a must, since so many of your design decisions will hinge off this.
The ‘rules’ section within a design system could be a doorstop of a manual, but there are easy ways to bring the key considerations into the pattern library itself. It could be as simple as dropping a comment beneath a colour swatch to say:
“This is $blue-500. We use it for hyperlinks and primary buttons. It has been checked for WCAG contrast and meets AA rules so you can use white text over the top of a blue-500 button.”
If the reader wants the long backstory of how you created your range of blues, user-tested button colours and ‘what the hell is WCAG?’ they can contact you for further clarification, but they probably won’t want to. They just need to know what building blocks they can use with as little detail as possible to understand them.
In terms of editorial guidelines, you could spend months writing a masterpiece, but how many people are going to read it cover to cover? Again, placing helpful comments in-situ with the patterns themselves is a much better way to go:
“These form labels are kept as concise as possible whilst still being human-readable. We want to save space on smaller devices, not overwhelm the user with too much text, but nor do we want to sound too abrupt or use jargon.”
How to decide what ‘patterns’ make the cut
So, assuming we’ve laid the foundations of our basic building blocks into the library and provided helpful annotations, how do we now work out what patterns to include? A content audit is always the best way to start. I like to physically print out pages from the current site at desktop and mobile breakpoints, cut them up and create a chaos of paper on a boardroom table. Ideally I’d include designers, developers and all key stakeholders in this activity. Once you start to loosely group the components, you might find yourself cutting them up into smaller pieces to find the inconsistencies at a more granular level. This exercise won’t help you evaluate fine variations in colour or dimension, but it’s a solid place to start.
Looking at the core elements of your site, you should end up with a list along the lines of:
Buttons — is there a defined primary and secondary style? Can the colours be inverted for use over a dark background? What happens on hover and click?
Combinations of links + icons that can be used instead of a button to save space and not distract from the core CTAs.
Lists — ordered and unordered.
Form elements — text inputs, drop-downs, checkboxes, radio buttons, date and currency inputs etc. In addition, you’ll want validation rules for these.
Page-level messaging — alerts to show you whether an action has been successful or not, or if the Internet has imploded and caused a site outage.
Tooltips and modal layers — plus when is appropriate to use either one.
Tabs and tables — with a focus on responsive solutions
Each of these items will contain micro patterns — consistent colours to show what elements you can interact with, red to show validation errors, rounded corners on buttons or form fields, consistent sizing and positioning of arrows within drop-downs or buttons. These small, repeatable behaviours in design will go a long way to giving your site a consistent look and feel, but it’s important not to forget how small patterns or components work together to form larger patterns or modules. This could be taking into consideration
the spacing between one form field and the next,
the positioning of the ‘submit’ button at the bottom right of the form (and a ‘back’ button at the bottom left)
or as a more complex example — the grouping of a postcode field with a lookup button to create a module that lets you select from a dropdown of possible addresses (or manually enter it within a group of text input fields).
You can even go a level higher and define how an entire form template can work, although there’s a real danger of making your designs too prescriptive. A simple form that lets you log in shouldn’t use the same template as a 5 step process to get an insurance quote. You don’t want to end up stifling your designers’ creativity by insisting that everything is perfectly uniform. Shoehorning new content and functionality into an existing template will usually be to the detriment of the user experience and make a designer feel like a disempowered production line worker. It won’t even save time for the developers because they’ll be creating a workaround to adapt a module for a new use that isn’t robust and takes more time to get working than building from scratch.
So, in summary a pattern becomes a pattern as soon as it starts building upon the core blocks of colour, type, icons etc. but most patterns are really patterns of patterns. When we talk about what a primary button looks like, that can appear very simple. It’s a combination of colour, shape, size and the type within it. But as soon as you start to talk about what it looks like in different states, on a mobile, with an icon included to the left or to the right, where it sits on a page or a modal and what animations happen when you click it… suddenly you can end up with about 50 variations of that one button in use throughout your site without ever breaking the rules.
The aim shouldn’t be to have a single one-size-fits-all button or to document all 50 possible combinations of the same button. It should be to quickly see how a common set of rules can be applied to call out an action as effectively as possible. Now we have useful design tools such as Sketch symbols and even unicorn designers prototyping in-browser, the process should be more along the lines of documenting our primary button and then calling out the classes that can be applied to it to make it work in various situations.
There are an infinite number of ways that a pattern library can be designed. But for me the key measure of success is whether or not a designer can glance over it and rather than seeing an endless kitchen sink of elements, it highlights a clear network of interwoven patterns. It’s a difficult thing to get right and I’m still not sure I have myself, but it’s a goal worth striving for.
