Writing a style guide that will actually get used
Usability commandment #2: Thou art not the consumer of the style guide
I have written or co-authored more company style guides than I have fingers upon which to count them. In the shadows of every effort has been that one guy wearing a surly look and muttering “but no one will ever use it” as he shifts back and forth impatiently. I don’t like that guy. My secret quest is to consistently prove him wrong.
Some of my early efforts did languish untouched on the company server. My team does not need more reading homework. They need something easily consumable and that will take work off of their plates.
I now strive to write and provide access points into a usability style guide in a manner suitable to the thought models of the development team, I hope, will utilize it.
1. What is a usability style guide?
A usability style guide walks through all possible interaction devices (e.g. form inputs, accordion controls, buttons) in a macro-to-micro fashion and gives its’ reader both a broad sense of how each device should be experienced as well as precise directions regarding functionality, accessibility, and layout. The guide is a complete design tool set so that someone working on a feature at 1:30 pm in Bangalore who has a question is not waking me up at 3 am in Chicago to get an answer. It empowers them to make decisions.
The instructions I set out to provide for each interaction device are pretty recognizable: outline the exact appearance styles, the do’s and don’ts of functionality, all variations and error conditions, and precise accessibility guidelines. This is when Usability Commandment #1 (Thou art not the user) and #3 (Thou shalt not design in a vacuum) come into play. I’m not the user of this style guide.
2. Get into the audience’s brain (or side of the brain)
I mostly work with developers who, prior to my arrival, have had zero design direction. They were forced to make UI decisions they didn’t want to make. The prospect of me taking over design decisions is a relief. Now they can focus solely on what they do best! But then comes a snag: we’re from different planets.
Developers revert to making ad hoc UI design decisions not because they don’t care about the style guide but because it’s not speaking their language. When I set out to write I come from a place of understanding the overall hierarchy of all necessary design elements. I’m so deeply entrenched in this structure that I can’t see my own bias. I provide overall guidance and rules-of-thumb which frame detailed instructions. I’ve organized the style guide by thinking from my right brain. This presentation method is so foreign to my developers at that moment when their minds are in work mode that I may as well be sending love letters from Jupiter.
Developers grasp details in a way that seems, to me, almost absent of any hierarchical structure. Upon hearing them constantly asking for the same minute directions over and over it seems like they’re being obstinate and not a little bit daffy. But they are not. They are deep in their left brains. To me, they sound like Martians.
3. Don’t make the style guide user change modes of thinking
I realized I had been presenting a complete tool kit to developers who just needed someone to put that one right wrench in their open hand. I asked what they wanted. Their list of minutia shocked me into seeing that my mental model for consuming design direction was not universal. They didn’t want the color specs and pixel dimensions outlined in what to me looked like a clear diagram, they wanted the CSS. They didn’t want what I thought was a clear hierarchy of pages allowing them to drill in and find directions on each UI element. They want exactly the place in the style guide that they need to go in exactly the moment when they are working on a precise part of the layout. The prototype I give them to work from needs to contain some of the directions from the style guide and give them a one-click reference to the one spot in the guide to which they must refer so they can stay in the mental flow of their work.
If what they need is precise doses of design direction at regular intervals then that’s what I should give. Project managers fight providing such granular directions. “This is spoon-feeding!” they protest after years of outlining every jot and tittle of projects has left them frazzled. Yes, it is. It is spoon-feeding. It makes perfect sense to do this because we are dealing with babes in the woods.
4. Be ready to iterate
The usability style guide is a living document. It evolves as new needs arise and as developers evolve their architecture. The important thing is to make sure that the design direction remains easily accessible and is broken down in a way they understand. I have to be ready to hand them the right wrench.