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.
The Sidelines
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.
The Dictator
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.
The Exhaust
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.
The Answer
Never is one, I’m afraid.
For a bunch more information, check out StyleGuides.io and Brad Frost and Anna Debenham’s podcast.
It’s not hippy, it’s holistic! The only trouble you get is when you have a designer unfamiliar with the web terrain, attempting to wield executive control, creating misery for all involved, and ultimately producing garbled sh*t that is hard to adapt and code without fudging.
It is easy to spot these creatures, they tend to wear brogues with no socks. Avoid like the plague! :-)
Having said that, designing branding cross media (ie, print and web) is still a rare and impressive skill. It is rarely taught or discussed, even at BA level. I know this from experience attempting to work with design graduate interns, who literally haven’t a clue and break into cold sweats when asked to produce page template visuals.
Beyond this (and more on topic with your article), creating two-way dialogue between the designer and coder is paramount to the success of a given project.
As an Art Director, i do give precedence and bias to the style (which includes UX/UI), because this should be predetermined by the creative and marketing team prior to the coding and functionality production aspects.
Last thing: Function determines design! Jony Ive, i’m talking to you and your dog’s dinner called Yosemite!
Dictator checking in. I am a self admitted control freak and I live and die by the styles set in the style guide. I like absolutes. I like plenty of forethought and planning, even on a seemingly simple job. On a CMS website that will be handed off to a client who has very little design know how but they want to self manage, it sets them up for success because they’ll already have a good idea on how to best use everything from Headings 1 through 6, buttons and other elements they’ll be interacting with. Better yet, most of those things can be set through easily with the CMS’ WYSIWYG by just choosing some text and selecting from a dropdown “blockquote” for example, so it’s really locked down. We almost never see a client managed site any more that is a wall of all caps bold comic sans text. So for those scenarios it can even be a teaching tool.
Dictator.
If it doesn’t match the accepted style guide – it better have a damn good reason to be appended. Otherwise, change to match the style guide.
It’s the best way to maintain cohesion across media, on different pages of the same website, and in your branding message.
It’s slower to get the website out the door, but maintenance is a lot easier afterwards. What every programmer and coder seem to forget is that maintenance will eventually overtake production.
Maintenance will eat away more of your time in the long run – even if initial production was slower due to religiously following a style guide.
take out a pencil and draw a square.
Are the opposite sides parallel, the same length? All the corners right angles?
Is it really a good square, based on your capacity to manage the medium, the pencil?
You’ll know because the style guide of a square is part of you and you’d never need question it, it simply is part of the known substratum of that drawing you are doing.
A truly talented visual designer gives you that substratum and you can’t wait to realize it in html/css/js, and, if you are really good, you will know, to a certain extent, if your rendering is faithful.
Will you ever get a complete style guide? No. You’ll return to the visual designer with a new panel that doesn’t fit the other panels’ paradigm. And the designer, if they are really good, will give you a new, ever more feature inclusive version of that square. It will be so ‘right’ that you run back to your keyboard with an even greater enthusiasm thinking, “Float! No! Inline! No! Inline-block! Yes!!!”
So there is a place for the style guide but it surrounds, supports and inspires. And you don’t have to worry at all about maintenance, the visual designer will do that automatically as they respond to your ongoing needs.
It does actually work like this in the real world – but only only only if you have a great visual designer, and only only only if you are capable of responding…
I find a hybrid of Dictator and Sidelines works well: you update the styleguide in phases, based on the last round of design iterations. This is the sideline phase. But it becomes the dictator for the NEXT phase. Not too dictatory at first, moreso as it fleshes out. Otherwise it CAN’T get fleshed out. Earlier on, it’s there to guide, but be ignored half the time.
Call it… The Backseat Driver?
I think this is a subject that has a lot of controversy. In my honest opinion I think Style Guides are good for big projects, but for a fast development project they tend to not be used.
And ugly junk ensues… I think the speed at which a project progresses is in part down to the skills/experience of those involved. Most of the screwed up projects I’ve seen just needed an hour or two on the beginning of the process, and possibly an hour or two on the end to actually finish the job properly (and this is usually because that extra hour or two of prep at the beginning would have solved miscommunication and misunderstanding).
Fundamentally, this being a CSS site, we are talking about the link between a designer and front end dev (if it is different people). I only work with front end dev that actually understand design. I’m always amazed at people who can CSS, but cannot understand design. You tend to get terrible CSS from them.
pretty much on hold , I absolutely love this web site, nice topic.
I’m a teacher and I don’t maintain or implement production sites so can’t really comment on the team aspect. For me style guides are an essential communication tool in the design phase. SGs give designers and clients and easy way to collaborate. A good style guide is an artifact of that process. I mention this because I recently learned about the style tiles (styletil.es) and WOW. The concept is so good – I just had to share.
Hey Chris –
Thanks for bringing up a great topic as I have been involved in just about every variation mentioned. Beyond the models you’ve outlined, there is another tact that seems like it may work and one I’m currently looking into. I attended SXSW Interactive this year and participated in a panel called Style Frameworks by @martigold of Tonic3. In addition to being a great panel in which she had to ad-lib her slides (no projector), she brought a plethora of insight to the conversation I felt really touched on the struggle we all have with style guides. That is, noone wants prescriptive standards because they won’t get used.
Her talk centered around a Style Frameworks in which you don’t pre-define Lego blocks (e.g. create spec docs with actual measurements), you just create the components, or the blocks themselves.
Rather than a dictatorship, it’s more of a republic where everyone has a stake and is responsible for the pieces they’re passionate about. (e.g. You like Accordions? Great. You own accordions in the framework, etc.). Ownership is like a data-center where everyone is contributing/filling in as needed. Everyone owns a standard but not THE standards. Buy in from UX, Dev, Marketing, and PM is all important so that there are no silos.
She’s created a site that is freely downloadable/shareable here: http://www.styleframework.com
I also like the organization of the site as a model for how to build your own style framework. Among other things, she’s got headlines such as “What problems is this [component] trying to solve,” “Location of assets,” “Ownership and Governance,” “Comments & Questions,” etc.. I highly recommend folks take a look at it for inspiration. Her slide deck is available online at slideshare as well.
Thanks again for an insightful post.
Anthony Rezendes
@arezendes
Thank you, Chris, for the post. It has been the Dictator for me on one of my previous stints, and a blend of the Sidelines and Exhaust thereafter. Actually, that’s one of the reasons I took to this job of bringing the guide INTO the documentation process. Now, we make sure that it is more towards the Dictator.
I do believe the Hippy Colony model to be most useful. I generally code a page, then add to the CSS, then create a style manual from the total output of several webpages. At this stage, I am in the Sidelines model. As a website grows, I begin narrowing the CSS rules into a more Exhaust model until it can become a mature Hippy Colony. The Sidelines model tends to grow from the rules used on several websites. Since these are thematically different, it takes some time before the rules for one themed site is narrowed into the style guide for an individual site. I have lots of clean-up to do to develop my mature Hippy Colony, but such is my goal for future sites.
With the websites that I do as a small business, I find your models expressive of the lessons I have learned along the way. Style guides for me are useful starting points for all my sites. Also, I am the only coder for my sites, so I get to use and misuse my style guides in any way I like. Even so, I find the need for a set of basic style guides that I can easily alter to fit the theme of the new site.
Thanks for conceptualization of these models. It helps clarify my own past actions and could make the future actions more efficient–once I actually clean up my stylesheets!!
At WGU, we’re using the exhaust method, though with limitations. When you’re creating dozens of experimental design elements and style variations for conversion testing and multiple departmental purposes, a good percentage of your site styles are transient. We have a portion of the site’s stylesheet that’s just marked as experimental, and that stuff may or may not eventually make its way into the official Style Guide.
As a designing developer I’ve had the best results when a general style guide is already complete and is rapidly refined to work in the web. This should be done in the first quarter of the project’s lifespan. Then, as need arises during development, budgeted designers should be allocated to generate concepts to fit all the special cases that always arise.
Too often the design process eats up far too much time leaving the developers to clean up afterwards, when the designers have left to join another project. It’s much cheaper having a designer iterate through a few concepts with the client than a developer, so they must be available through the very end.
So my preferred method could be described as The Hippie Prison Colony: a dumbbell where the left side is the General Style Guide design phase and the right side encloses the Hippie Colony. The project gets the benefits of having a thorough design exploration, a long development period and designers locked in the project to support the developers.