Process, process Back when Aaron and I worked at The Company That Shall Not Be Named, I was notorious for butting heads with the technical editors at head office. The cause of those situations wasn’t ego or a misguided urge to be a troublemaker, though.

My problems with the editors revolved around their attitude towards The Company’s rather large set of style guidelines. The battles weren’t always pretty.

While style guidelines can be useful for maintaining consistency across a set (or several sets) of documentation, the editors that I worked with viewed the style guidelines as sacrosanct. Any deviation, no matter how small, was punishable by a nasty email and a sharply worded note to the offending writer’s manager.

Nothing should be carved into granite

I see style guidelines as being just that. They’re guidelines, and aren’t and shouldn’t be set in stone. Processes do fail

In theory, a set of style guidelines should cover every eventuality that a writer encounters. In practice … well, reality has a way of tossing a wrench into the works. To deal with reality, you need to step outside those guidelines once in a while.

That might mean using a more user-friendly word or term (say, choose and not select). Or it could involve adding another level of bullet list or indented text.

Remember the audience

Content is king Sometimes, technical communicators fail to remember that we’re not writing documentation for ourselves. And we’re definitely not writing it for our technical editors (if we have them). The documentation is for the people trying to use the software.

My argument then, as it is now, is that any deviation from the style guidelines that’s transparent to the reader is OK. As long as the integrity of the information contained in the documentation isn’t compromised by these deviations, there’s nothing wrong with ignoring the guidelines.

Will a reader care, or even notice, the use of that instead of which? Does it matter if a list is set using the style ListBullet2 instead of ListBullet2Compact? More often than not, the answer to questions like that is no.

Guidelines aren’t a recipe for success

Even the most rock solid set of style guidelines can’t guarantee that documentation will be well written, meaningful, and fit for its purpose. And that purpose is to show users how to get things done in the fastest, most efficient way possible.

In the overall scheme of things, content trumps process. You can’t cling to a process like it’s a life preserver in the middle of the ocean. You must focus on the needs of the user.

Thoughts? As always, comments are welcome.

  • Share/Bookmark
Print

Related posts:

  1. Style guides
  2. The importance of process documentation
  3. Is content reuse harmful?

Related Posts