I was doing some research on pattern libraries for a client today. We're creating a model for a new section of their website. I had asked if they had a style guide or pattern library that they were working from. I got a 2-page PDF style guide that covered the colors and buttons. That is a good start, but not helpful to me as I start to design the content.

Because we start with a content model and design the content using the attributes needed to meet a user need, we do not have a preconceived idea of what the content will look like. We have only the priority of the content and some sample pieces to begin the interface design work.

It's fine if there is no existing user interface (UI) design framework. The designer can take the content and apply their magic to make the content come to life and become useable for the people who need it.

From that content design springs patterns for content presentation. Conference speakers get displayed a certain way every time they show up. Maybe like this:

Behind the visual piece is code: CSS that tells the browser how to render the visual style.

So CMS developers can use that code for their templates that send content dynamically to screen after screen with speaker information.

Now whenever we add a speaker, everyone knows what it will look like and which content attributes are included in the display and interaction.

Creating pattern libraries with content in mind

That is an oversimplification of how pattern libraries work. The point is, it should be the start of your UI design work, not an after-the-fact add-on. And when you start with actual content, the designers' and developers' jobs are more meaningful. They have to make fewer guesses.

The atomic design of pattern libraries directly corresponds to the atomic design of the content.

In atomic design (coined by Brad Frost), you build up from the smallest part of the system, the atoms. Then you put those together to form molecules, then organisms, then templates, and finally, pages.

The 5 levels of the atomic design methodology for creating design systems

By starting with content atoms – the attributes of the content type – the designer knows exactly what the atom is made of.

For a conference speaker, we know we had these attributes, or atoms:

Name
Photo
Biography
Twitter ID
Role
Email address

Some of these attributes may show up in a molecule like this:

Put together with other speakers, they form an organism like this:

Speaker organism with multiple molecules and a header

And also the speaker bio template:

Repeat this for all the other content types and templates and pages on your website or in your product.

Because the content and UI pattern go together, there is no wondering what a piece of content will look like. There is only a small amount of ambiguity early on that gets cleared up as you go.

This should all be documented in a coded, live website so it can be updated, shared, and used by everyone.

When it's time to add a new type of content that contains a person's photo, the pattern can be reused.

And now you do not have to re-engage the designer or front-end developer.

You don't have to take the time to rethink this element.

Your addition is relatively easy, fast, and cheap. When was the last time that happened?

Examples of pattern libraries

Here are some examples that make use of content along with the UI patterns. Depending on your size, some of these examples will seem like too much. Take what you need and leave the rest. Just be sure to have a conversation with your design team and make decisions deliberately.

U.S. Web Design System Ben Brignell's styleguide and component library
Eurostar GLU pattern library(See UI Components)
Tourism Whistler styleguide

(We'll save the debate over whether style guide is one word or two for another day.)

Have a pattern library you really like? Experiences creating one? Please share your lessons and libraries in the comments.