Thu 09 Mar
2006
Wow, I’m a little stunned by the general lack of reaction to Monday’s post about the long decline in the quality of design style manuals. Maybe I was under some hallucination that this is an issue that many (if not most) designers will encounter many times in their careers, and that those designers would generally find the tortured motivations of style manuals to be a worrying state of affairs. Even so, it was one of my favorite pieces so far; I took out more time to write it than I do most pieces, and I think it represents a novel perspective on what it is exactly that designers deliver to clients.
At any rate, I’m undeterred in my pursuit of this subject. Never let it be said that I’m guided solely by comment count! As it happens, the second part of my rant on this subject is considerably less ambitious — it works off of the premise that the climate of client-designer expectations is one that’s unlikely to change anytime soon. For the time being, designers are stuck with these particular circumstances when it comes to style manuals: a high bar for comprehensiveness and a low threshold for time and for fees devoted to documentation — resulting in a lot of labor producing little value.
Given that situation, it’s reasonable to say that something about the entire style manual concept is broken. With so much effort going into so little result, it seems there must be a better way to do this. For a while, my own personal view was that the solution was simply to move away from the idea of these manuals as tomes, monolithic documents delivered in print form and intended to sit in someone’s file cabinet somewhere.
Producing these tomes usually entails a designer, often working without a proper copywriter, creating meticulous and pointless pages full of rote specifications with a program like QuarkXPress or Adobe InDesign. A lot of hours are spent creating an aesthetically pleasing presentation of numbers and facts. Once output in hard copy form, the effect is attractive and it can be very impressive, but it’s also often full of errors and always inflexible in the face of unforeseen contingencies.
That last point is crucial: a printed style manual is infinitely less adaptable than a digital version, and so for the past few major projects I’ve worked on myself, I’ve produced documentation in the form of a small Web site, using a mix of XHTML, CSS and PHP to provide a simple, centralized resource that can be shared with anyone. Instead of a printed document, what’s delivered is a micro-site that can reside on a client’s server or a password-protected external server.
This method is dramatically faster than using a page layout program, and allows for relatively painless updates, even major ones, because there’s no problem with maintaining multiple versions of a document, and no problem managing the distribution of those versions. In digital form, the manual can also provide direct access to source files. By making Photoshop files, Illustrator art and snippets of code available from directly within the HTML, it often precludes the need to painstakingly diagram the minutiae of a design solution.
Again, nothing in these style manuals, whether in print or digital form, could ever substitute for a full-fledged designer, nor can they anticipate every scenario that might arise. But at least in digital form the manuals are more pliable to the changing wills of project stakeholders.
These style manuals I did were hand-coded, and I considered attaching some simple Web publishing tool to the back-end to automate their production, but the effort seemed to outweigh the benefits. That is, until I really put two and two together and realized that wikis, by their nature, are ideal for the production of style manuals: they make the authoring process markedly easier (if no less awkward) by eschewing XHTML for an even simpler set of markup tags that almost anyone can learn. They also allow simple, on-the-fly creation of new pages, which in turn allows for a more organic evolution of a manual’s content structure: style rules can be written almost at the same time as they are developed, and then later re-organized into a more coherent table of contents with little penalty.
Best of all, a wiki-driven style manual can be continually updated by its intended users, which is really what is called for when there’s little or no budget allotted for design documentation, or when a client lacks truly dedicated design staff. With a wiki, anyone can amend and append the manual as necessary to suit the particulars of their own needs and design experience; it relieves the design team of the pressure of creating an all-knowing manual (though not of the responsibility of creating thorough documentation), and instead asks them only to provide the building blocks of such a system.
It’s true that turning to wiki software to address this come-down in our expectations for style manuals is a bit of a cop-out. There’s really nothing inherent in the wiki mode of thinking that will necessarily encourage a return to the narrative, instructional quality of the masters’ style manuals, and that’s a shame. In one sense, by giving up on truly comprehensive style manuals in favor of group-edited manuals, we are driving an additional nail into the idea of design authorship. But in another sense, wiki-driven style manuals are truer to the often touted idea that the best design solutions are in fact living systems that can grow and adapt with changing needs. It’s the 21st Century, after all, and we should be documenting our design in a 21st Century fashion.
Long Time Listener, First Time Caller.
(ok...not that long, but you get the picture)
Thanks for the insightful and thought provoking (and timely!) post.
Looking forward to the next installment.
Kudos.
My idea of a style manual for web designers is not really written documentation (PDF, Word, Powerpoint) but rather HTML prototypes. Some things will need to be explained on paper but I think most of it can be communicated through code, CSS, image directories, etc. HTML prototypes can also be reused. If you have some kind of global control on layout and specific CSS styles, changes can be easy in the future.
I understand your post is not entirely about web style manuals but this works for me as a web application designer.
Great post!
Thanks for a great read. I’m just about to get started on a manual myself now, so the timing couldn’t be better, either…
This is such a good point. Consumers demand a user manual on how to use something they buy - something that the cheaper products usually skimp on. The fact that clients are ignoring this piece of the design process is like never getting the user manual. Sure it looks great out of the box, but are you willing to risk breaking it by not paying a few extra bucks?
I agree totally with your analysis. With redesigns and brand refreshes being so popular lately, I doubt that many companies would focus on delivering a strong long-term message. I am too young to remember an era where coporations invested in style manuals, what has changed since then?