Brad Frost was showing me some slides from one of his talks recently. He had some graphics that demonstrated different approaches to where a style guide can fit into a team’s process. As you might imagine, it’s a matter of just having one or not that will determine its effectiveness.
I thought I would attempt to explain my own thoughts on these approaches based on my own experiences.
Or maybe we could call it the “after the fact” model. The idea is that you have a Style Guide, but it’s this separate thing that exists outside of the actual process. You have to maintain and update it separately. Changes to the site aren’t reflected in the Style Guide unless you take the time to do that. Changes to the Style Guide aren’t reflected in the site unless you do that.
Useful as a reference, mayyyybe. I’ve worked on a Style Guide like this. It was slow to gain any use at all and was quick to be abandoned.
In this approach, the Style Guide is the law. Nothing goes into production that isn’t a part of the Style Guide. If something is needed on the site, it is integrated into the Style Guide then is available for use on the site.
Adoption of the Style Guide, of course, is high because it has to be. Everything is documented. Those are potentially good things. This is also potentially frustrating – the process can be slower, which is sad since speed is a big reason to use a Style Guide in the first place.
There is also a danger that you’re “designing a Style Guide”, not “designing a website”.
The Hippie Colony
Everything is connected, man. The Style Guide builds the website, but the website builds the Style Guide as well. It’s just one set of assets, packaged up in different ways. One way looks like a Style Guide, one way looks like a website.
This can be nice, as you could work on either one and have the changes reflected in both. The only potential danger here is that it might be too good to be true. Discussions might become disjointed. The Style Guide might not stay as updated as you might assume it would.
In this model, you generally work on the site itself. The Style Guide is built from production assets. It essentially becomes part of testing. “Does the Style Guide still look correct and cohesive after these changes?” The potential danger of this method is that people stop caring about the guide because of its placement at the end of the process.
The CodePen Style Guide is a bit like this, but I’m hoping to make it more hippie-like.
Never is one, I’m afraid.