Adapt or die: style guide edition
Being cognizant of your environment and adapting accordingly is a good survival technique for any being (as Darwin recognized), and it’s particularly true in the professional world. And that’s why I’m puzzled by how much time tech writers spend agonizing over style and word choices in tech comm forums, on Twitter, and elsewhere.
Don’t hit the wall of unproductivity by arguing style points (flickr: OpenSkyMedia)
I am an English major with a background in a journalism. I am a fan of precise, well-written content of any kind, and I can nitpick over wording with the best of them. (Just ask Sarah O’Keefe or anyone else who has asked me to review content.) But as Tom Johnson and Scott Abel have pointed out, a singular focus on style issues in tech comm does not cut it these days. (If you’re writing fiction on your own time, have at it!)
A style guide is basically a compendium of choices that foster consistent content. If there isn’t a style guide in place, implement one with a minimum of fuss and quickly move on to actually implementing those guidelines in your content. The goal is to create consistency, not agreement among writers on every single point.
If you start a new job and don’t like a decision in a style guide, join the club and suck it up (unless you have a truly compelling argument). Every time a style decision is renegotiated, that’s precious time wasted when our jobs require increasing speed in both the creation and distribution of content.
Harness your concern about precise language in a productive way that will save your employer time and money. For example, if your content is localized, using terminology consistently will reduce your localization costs (and offer all readers of your content a unified experience). Come up with a list of approved terminology, apply it to your source content, and work with your localization vendor to ensure it’s implemented in translated content. If you’re cranking out a lot of content, look into software that can enforce consistent terminology, style rules, and so on.
Style guidelines should save time and money. Arguing over every rule in a style guide does not.
P.S. Yes, I borrowed the headline from Sarah O’Keefe’s upcoming presentation, Adapt or Die: Managing Increasing Content Velocity, at the Intelligent Content Conference next week. Sarah and I will be at Scriptorum’s booth, so drop by for a chat and some chocolate!
About the author
Larry Kunz
Yes, as long as there’s a good style guide in place. If there isn’t, I guess the solution is to get one (rather than “implementing” one as you say). There are plenty of good ones out there. Then appoint someone to be the “buck stops here” arbiter when the inevitable questions arise.
I’m left to wonder just one thing. If we writers can’t argue about fine points of style, what can we argue about? ACC basketball? (I really like the type font that N.C. State uses on its uniforms this year. You can’t seriously think that Wake Forest’s is better!)
Alan Pringle
Larry, I can’t imagine why you would think tech writers want to argue about font use. They *never* do that.
All kidding aside, choosing an existing style guide is a great idea to save time and get on with business–namely, DEVELOPING CONTENT.
Sally Fresquez
You mention that if there isn’t a good style guide in place, get one (rather than “implementing” one . . . ) and that there are plenty of good ones out there. Where do you find a few basic style guides to reference? I’ve been jotting down notes here and there while on projects, but this method is not proving to be productive.
I’d appreciate any leads or suggestions you might have that could help as opposed to starting from scratch. Terminology is established and not an issue.
Alan Pringle
We have an online style guide we used years ago for writing projects. We still pretty much follow the rules when we’re writing books.
https://scriptorium.com/resources/online-style-guide/
A word of warning: it hasn’t been updated recently, but the guide should at least provide a solid starting point.
Mark Baker
Alan,
I think it is worth making the point also that for a style guide to be effective, it needs to be short.
Every language, and English in particular, is an organic thing that grows over time and it has many different ways of saying the same thing. You absolutely do not need to be consistent in every one of them, and it is virtually impossible to be so.
Readers read all sorts of stuff every day and easily process the differences in the way that different people express things. Most would never notice that there were inconsistencies, and would roll their eyes at you if you pointed them out.
There are, of course, a few things that you really do need to be consistent on in your technical content — things that will create real confusion and ambiguity if they are not consistent. This is usually product names and technical terminology. It is never about variant spellings of “email”.
But writers can only hold so many of these things in their heads. Insist on them remembering hundreds of style rules that exist only for the sake of formal consistency and you create a cognitive load that both inhibits their ability to think about the subject matter they are talking about, and hinders their ability to remember to be consistent on the few terms where it really does count.
The fewer rules you have, the better adherence you will have to the rules you do have. Anyone who tries to impose more style rules is really just setting up a false quality measure that is easier for them to conform to, but which is not actually adding value to the end user.
Alan Pringle
Mark, shorter is indeed better–and much more realistic.
Karen Lowe
I whole-heartedly agree with your post and the comments from others. It seems to me that tech writers want to produce perfection (I mean, who doesn’t?) but often we forget about the cost of perfection – especially in time delays and re-writes. It’s like analysis-paralysis in the business analysis world. It’s counter-productive. I feel that it’s better to deliver something that’s “good enough” than to deliver nothing while awaiting the perfect document.
I am leaning towards the Nike approach – just do it. 🙂
Alan Pringle
Perfection in anything is subjective–and can be a huge time sink. “Good enough,” as you say, delivered efficiently may be the better goal.
Yaakov Simon
I couldn’t agree more with your post. It is more difficult to be brief and to the point, than to be long-winded.
How much time is wasted in meetings arguing about how to document a one-step procedure. Choose one style and move on!