Two years ago I read a great article by Smashing Magazine on “Style Guidelines for Brands and Websites” which suggests designers offer style guides to clients post-project. Often in the rush to the deadline, we forget that a website is never completely done and will continue to live on, organically changing and adapting itself. Having a style guide certainly gives the client evidence that actual strategic thought went into development of their brand. At the University of Minnesota, I became very familiar with their style guides during HTML 4.01’s reign. From a systematic organizational perspective, style guides were a doctrine that constrained specific uses but also allowed room for creativity in the spirit of the guide.
When I think about traditional style guides in the context of Lean UX, in reducing waste from iterative processes, I realize they are paradoxically outmoded and transgressed. Style guides can take many forms and for web often manifest in layout standards (wireframes) and graphic standards (color, shape, size, position). In essence a web style guide creates a prototype’s framework for you, and it’s up to you to fill in the pieces. In an ever evolving start-up environment, the visual standards are constantly changing, being thrown away or restructured into new forms. Why bother creating a guide when you know tomorrow even the very fundamental aspects of your product will change.
Now, at the same time, a style guide can act as a fundamental bedrock because it infuses the overall process with a sense of purpose and unity. Style guides come from the print environment where seemingly minor factors like line-height and line thickness can make or break. As we know from conceptual design or product design in general, that form is sometimes eminently more important than function (assuming the function is worthy). Twitter and Facebook are essentially communication mediums but their forms, in 140 characters or in dynamic multi-level posts, change the user experience. Mac OS X is a system that clearly has a style guide, that very specifically dictates every visual graphic to the point where outside developers and their designers must follow the edict. Ironically it is Windows that has shown a penchant for anything goes, and we know how that’s turned out.
Style guides are different from documentation. Jeff Gothelf writes in “Lean UX Is Not Anti-deliverable” (5/23/2012):
The focus should still be to design the best experience while minimizing the amount of time designing the wrong ones — not to design documentation that describes these design hypotheses.
Lean UX is about a specific design solution as a scientific question. Does my new app interface do what it intends without any instruction? The documentation outlining wireframes and hierarchy are what needs to go. On the other hand I see style guides as addressing a higher level question, whether the design communicates not just purpose but cohesion with the message, brand and experience. If anything, style guides answer questions of the strategic plan. The new Digg is perhaps the best example of a redesign that, one can argue, does exactly the same thing, but in form answers such a different mission statement.
