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.
A Broken Idea
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.
Wikis to the Rescue
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.
+