Creating useful pattern libraries

Pattern libraries are great, but designing them (well) is difficult.

What are they?

Designers and front-end developers have embraced pattern libraries. They allow us to design a unified system rather than a series of isolated pages and also break up development up into smaller, clearer chunks. They let us see how different components work with each other.

Why are they hard to create?

Quite simply, they’re hard to create because we’re designing a system rather than a series of individual pages. Each part of our system needs to be flexible enough so that it work harmoniously alongside each other part. Therefore, changing any single component will inevitably have a knock-on effect on a number of other components too. But, we do need to be careful not to make things too generic and, of course, we need to make sure that our design reflects the brand appropriately.

To complicate this further, our system needs to be flexible enough to cope with, not just new content, but usually a hefty import of legacy content. We can’t impose arbitrary limitations like “headings must be 100 characters or less”. Our system needs to take into account the average length of a title, but also handle not just the unusually long ones, but probably the occasional single word title too. After incorporating as much flexibility as possible, at some point it always comes down to making hard choices and accepting trade-offs.

All these considerations mean that the design as a whole will evolve as the number of components in the library grows. As designers we need to constantly step back and ask ourselves the usual questions: Is it readable? Will it flow as part of a page? Is the design detracting from the content? Do we have enough options to make something stand out where necessary, or to alter the page contrast to improve readability?

Can we use them better?

Pattern libraries, or style guides as some call them, serve as a repository of all the components, elements and modules that can be used in a site. This makes them a great resource for publishers to quickly find components and use them as they are constructing their pages.

However, I’m not convinced a pattern library is the same thing as style guide. In my mind a pattern library is an exhaustive repository, probably with code examples and usage instructions. It’s a toolbox, from which a publisher can select the right component for the job.

A style guide on the other hand should serve as a reference, a collection of usage examples suggesting how and where you could use your chosen component. Outlining how it will work in different positions, different width columns and alongside other content. It should ask questions and make suggestions.

Understanding this distinction between the two will hopefully enable us to make more useful tools for both ourselves and our clients.

  • What do you suggest for a non-technical solution. Most of the pattern libraries out there are built on grunt and node.js. I want a simple repository for styles and patterns, that will always live on the host.

    • edmerritt

      I’d suggest just starting simply with a static HTML file hooked into your CSS. It doesn’t need to be any more complicated than that to begin with.

      People will always try to find ways to simplify, streamline and speed up processes they find useful, but before worrying about any of that, just build yourself a repository and next to each component paste its HTML inside a pair of <code> & <pre> tags. I suspect you’ll be surprised how often you refer back to this page throughout the project – be it to grab a snippet of code, or just compare the styling of a couple of elements.

  • Guest

    I’d suggest just starting simply with a static HTML file hooked into your CSS. It doesn’t need to be any more complicated than that to begin with.

    People will always try to find ways to simplify, streamline and speed up processes they find useful, but before worrying about any of that, just build yourself a repository and next to each component paste its HTML inside a pair of <code> & <pre> tags. I suspect you’ll be surprised how often you refer back to this page throughout the project – be it to grab a snippet of code, or just compare the styling of a couple of elements.

Headscape