Last week, I discussed how style guides are a help and hindrance. In this follow-up, it’s time to take a look at how style guides might adapt to new, web-based publishing models.
During the summer of 2007, I worked at Google as technical writer intern. Toward the end of my internship, I attended an all-day meeting of nearly all the technical writers at Google. One of the writers brought her dog to the meeting. At the merest mention of the possibility of a Google-wide style guide, the dog groaned. Loudly. Even the animals at Google had come to embrace the culture there of openly resenting style guides. There was some discussion—despite the dog’s protests—but little enthusiasm for the idea. Google seems to get by without an absolutely consistent voice across their various bits and pieces of documentation.
On the other hand, during the course of my internship project, my mentor at Google and I developed an informal style guide to help us coordinate our work on Google Desktop. It wasn’t an exhaustive document like the AP Style Guide or the Chicago Manual of Style; it just covered a handful of possible inconsistencies we had run into. It wasn’t hard to maintain and helped avoid some unnecessary editorial effort. So why did it work for us specifically, when Google’s technical writers rejected the idea in general?
Google is in a currently unusual situation when it comes to style guides. Google, in contrast to many other large software companies, doesn’t make use of centralized technical writing departments. Many large software companies either outsource or have teams of technical writers working together to serve as an internal clearinghouse for docs. At Google, technical writers usually work as a part of a particular product, frequently as that product’s only writer.
Moreover, what Google publishes more often than not are single web pages that address some limited issue, not monolithic manuals. I’m all but certain Google has never distributed a printed manual (though it’s tough to prove a negative). Such a work and publishing model is suited to an individual author owning a collection of docs, rather than spreading the work of that collection to several writers.
In that context, the path to a successful style guide becomes more clear. In such a content creation and distribution model, specificity becomes a key word in creating a style guide. When few authors are focused on a limited area (like a particular product, system, or process), a style guide need not become a monolithic document to advise on every possible writing decision. Instead, those authors that take ownership of some documentation can craft a product-, system-, or process-specific style guide. Writers can use a style guide of a size and character which is congruent with the size and character of the documentation they’re producing.