Pattern primers, style guides, pattern libraries. They’re all the rage. And they make good sense, but I think we’re in danger of working back to front.

At Mark Boulton Design we get quite a few project enquiries and over the past twelve months we’ve seen an increase in requests for these repositories as a project delivery. This is just fine for us, as we tend to propose them anyway in some form or other to document our work. But there is an inherent concern in delivering this type of thing to a client. When is it done? And how is it created? And making sure that is discussed with a client, in depth.

My first exposure to style guides was through print and branding. Corporate style guides are rules of execution; position this logo like this, use these colours, this type, crop photos this way. Adherence to the guide is critical and there’s always someone policing them. Having been involved in the creation of a few of these printed style guides, they are always designed after a body of work and then – almost without exception – never updated to reflect slight organic changes as a brand or design system grows. This is why digital style guides are good. They allow growth.

I’ve read recently that some designers are starting with patterns. Taking small modularised chunks of content and then compiling for display in different circumstances. This, of course, if great for taking an adaptive content approach. Thinking of our content in small chunks is useful. But, I can’t help but thinking that approaching design in this way is a folly and will result in generic, cookie cutter work.

When to abstract?

DHH from 37signals wrote a great post recently about the abstraction of code and when it should be done.

Future coding is a lot like playing the roulette. If you can guess where the requirements of tomorrow will land today, you’ve just scored the ultimate programmer’s prize: looking like a wizard. You saw the future and you were right! High five, brain!

That’s the almost irresistible draw of “flexibility”—often just a euphemism for building half or whole features before you know how they’re supposed to work or whether you need them. Just like in Vegas, the worst thing that can happen is to be right about this once in a while.

And that’s exactly how I feel about creating style guides. There’s a lot of talk about us designing systems for the web. Well, sometimes, we’re not designing systems at all. We’re designing a couple of pages for a marketing web site. Creating a whole pattern library for a project like that is not only overkill, but completely inappropriate.

But the same can be said for a large scale project too. If you don’t know what the patterns are, you could be abstracting too early – bowing to the lure of future flexibility.

I guess it’s a question of balance, and one I’m becoming acutely aware of recently. For me, style guides are still there to document a design system. But they’re not a tool kit of parts. Before you design a tool, you have to know what to fix first.