Recently, Nishant Kothary tweeted that styleguides “are the most useless design deliverables in existence.” Geri Coady responded with a nicely written blog post defending styleguides and their use, but pointing out the drawbacks to their usage, plus some good examples.

The thing is, there’s a BETTER way.

First, let’s take a quick gander at what a styleguide is, traditionally. This is a document, usually a PDF, ranging in length from one to hundreds of pages. It lists everything from what fonts are allowed on your website or marketing materials, to where the logo can be placed, what colors are kosher, and more. It’s the brand bible, and it’s often the product of months of work by a team of very smart people.

The styleguide’s most valuable purpose, and most undeniable impact, is to create consistency. My UX teams know that consistency, consistency, consistency is my mantra. If a website or application is consistent, then even if it’s hard to learn or understand at first it’ll build a sense of safety, confidence and speed in the user. The user will learn that they look for X to do task 1, and that task 2 is always in place Y. It’s proven that consistency builds trust in users, and that companies with consistent branding, user experience elements and interactions are perceived as more professional.

However, the styleguide usually gets emailed out to everyone, then put up on an intranet, where it instantly begins to get stale and moldy. Those people who got the email either delete it without reading it, or stick it in a folder to be forgotten about. It benefits no one other than the designer who needs to use it to cover his butt or the product manager who wants to use it to convince a reluctant designer to do something a certain way. In other words, it’s an instantly dusty, bully pulpit.

Designers complain that styleguides stifle creativity, and developers complain that styleguides are unusable documents that change too often to be tracked properly. I suspect these are the bases for Nishant’s frustrated declaration – and who can blame him?

But what if it wasn’t this way? What if the styleguide was effortlessly up-to-date, relevant and useful to everyone involved in the design and development process, and accessible directly within everyone’s workflow? What if the styleguide wasn’t a drab, outmoded tome, but rather a LIVING thing made of code and recursively following its own rules?

Living styleguides aren’t a new idea. However, when my architect came to me and said “hey Krys, you know that styleguide you’ve been working on? How about we build it in code, and instead of just being a document, the very styleguide itself is the CSS that people will use? Separate presentation from everything else and let people just write code without having to think about how it looks.” my head nearly exploded.

It took me a while to get the concept, truly. It’s possible that I didn’t completely grasp it until we built it. But build it, we did. It took us a couple of months, and goodness knows there’s a lot more we want to do – but our styleguide lives and breathes.

From a practical, design-oriented viewpoint, here’s what it is:

• An architecture that completely separates presentation from code, segmented into typography, colors, containers, backgrounds, foregrounds, interactions and widgets.
• A set of supporting Sass and Compass files (I’m sure you could do this with other technologies too, but we’re a Sass/Compass shop)
• A few haml pages that use the styleguide to demonstrate the styleguide, in case anyone needs to reference it
• A matching and corresponding UI Design Library psd file, which is the only part that is manually maintained (and when I figure out how to have a PSD auto-generate from a CSS file, I’m totally going to be rich)

When a designer is creating a new feature, it’s quick and easy to use styleguide elements because each element is named according to its purpose and intent, not its appearance. The process looks a lot like this:

1. I need to give the user this information without distracting them from the primary task here.
2. I guess that would go in a low-priority container, then.
3. But since it’s in a green page, it needs the green page foreground colors
4. and standard typography
5. and that looks a little awkward so I’ll vertically separate it.
6. Ah, that was easy. Now on to something that challenges my giant brain.

Then the designer hands it off to the developer, saying, “It’s a low priority container in the right column, 4 grid columns wide. Standard typography, green foreground, vertically separated”

And the developer just creates a div with these classes: low-priority-container, g-4, reading-text, green-foreground, vertically-separated

And you know what? it’s instantly pixel-perfect.

Look how easy that was for everyone involved.

If the designer is working on a feature, and the styleguide isn’t quite sufficient, all she needs to do is design something new (here, there’s some discipline needed. I go into detail in my Adopting Sass talk), add the appropriate code to the Sass files, test it in the haml, and deliver it to the developer with corresponding class names. Simple, clean – and because she designed it actually in the code of the styleguide, she saved the developer a lot of time and trouble.

I’m not saying living styleguides are easy to implement. I did a lot of hand-waving over the really brilliant, hard work that my architect did actually building all the backend stuff. There are some wonderful frameworks already out there. There was also a steep learning curve for some of the engineers, while they adjusted to a new way of working. However, I’ve since heard engineers say things like “The styleguide makes building new pages so much easier” and “It’s so much easier to communicate when you just tell me what class that is”.

Plus, a super awesome bonus: you get your UI cross-browser testing for free with a living styleguide. You cross-browser test it when you build it the first time, and every time it gets reused you’re using already-tested code. Don’t get lazy with your QA – just focus it where it’s needed most. :>

When it comes to moldy PDFs, I’m with Nishant. They’re nearly useless. But as a workflow and communication tool, and to ensure consistency and brand fidelity, a LIVING styleguide provides an amazing scaffold on which your team can grow and thrive.

 

---

Today’s Interesting Link:

foundation.zurb.com – Foundation, by the good folks at Zurb, is a decent place to start if you’d like to build a living styleguide.  It provides you with a basis from which you can build all kinds of amazing things.  And it’s responsive, which in this day and age, is a MUST.

Today’s Usability Quote:

“To innovate, you must first be inspired.” – David Blakely, Director of Technology Strategy at IDEO

Today’s Music To Design To:

The Tron:Legacy Soundtrack is energetic and relaxing at the same time.  It’s so well crafted that you almost feel the transitions from song to song.  It instantly inspires me to make new things, and it seems to be completely independent of style.  I love to listen to this while I’m sewing or making props too – it’s just CREATIVE music.