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.

I recently reviewed Brad Frost’s thoughts on responsive navigation patterns. In terms of mobile widths, I personally have been using the select menu option, utilizing a jQuery script to change out a nav’s unordered list UL for select option tags. I had found it to be a perfect way to utilize a phone’s native function — the act of pulling up the navigation menu a seemingly seamless experience. After reading his cons in that use, I’ve changed my mind.

In a mobile setting, select menu “rolodexes” like in iOS are not a sensible way to display navigation menus because users generally do not know what navigation options there are to begin with. Hence, I agree with him that they are potentially confusing. One must consider the normal, intended use of multiple select menus as a form element that combines many related items. For example in a shopping cart, I want to show color options for a t-shirt. When a user clicks on “select a color”, they expect to find only names of colors like red or blue. In the case of “navigation”, the user might be fairly daunted when presented with many unrelated links in a website. Similarly in my example, someone looking to chose a product color is going to be confused when options like blue hoodies and red jackets appear.

My alternative has usually been the do-nothing approach, essentially restructuring the top nav into a mobile-friendly element. My personal default has usually been a full or half width button with soft gradient, to mimic iOS general styling. The one concern that I have encountered by many clients is that they do prefer the nav to fall at the bottom of each subpage. A jQuery detach/append can certainly do this, but that function is processor intensive and rather clunky with click-happy users. One client was so perturbed that I created an entire mobile version of the site with this layout.

My solution for Urban Bean presents the homepage with just nav and on each page, the nav appears at the bottom.

At the end of the article, Brad linked to an interesting pull down nav solution by Inspect Element which essentially takes a cue from the pull-down-to-update effect by Twitter. I’d call it more of a pull-down-to-reveal since the nav height doesn’t stay anchored atop, rather the page itself pulls down to reveal nav from top to bottom. While the solution is very compelling and presents room for creativity, unfortunately I don’t find the pull down nav to be terribly intuitive. Subducted information from the top of a page tends to imply related content to that page, not to the entire website. Also from a UI perspective, we’re taxing the brain to orient two up-and-down motions. The other motion is iOS Safari’s native inclination to snap the entire browser window when you exceed a page’s maximum scroll.

Facebook introduced the left reveal and it works because natively, iOS apps like to slide progressively right to left. Sliding the current page left to right implies we’ve moved back a step. The home menu is further implied to be a master screen by several important details. First, the menu is generally a dark color and color grades downward, second the current page’s subtle box-shadow floats it atop, and thirdly, the page hasn’t quite moved all the over, implying we’re taking a peek into the master Facebook brain behind everything. A left reveal also lets the thumb do its job of scrolling, only this time for navigation. You could do this with the pull down nav but then you’d be asking the user to track three vertically changing elements all at once. Vertigo would ensue (unless that’s what you want!).

My last observation is that I’ve noticed some designers pushing ridiculously small text scaling for their navigation bars as you move toward smaller screen widths. To keep the horizontal element, they’ll squeeze nav buttons, proportionally might I add, into that 20 to 50 pixel height.