About Style Guides

Published: 22 March 2016

The first style guide I ever used was a simple in-house guide, about 20 pages stapled together in the upper left-hand corner. I worked for a financial services training company with maybe 10 other employees, so the style guide was really a collection of the owner’s preferences. This style guide instructed us to write “LITE” instead of “light” and to always use at least three exclamation points (!!!), never only one or two. Doesn’t that sound glorious? No? Well, after you got used to it, it was great!(!!)

Some of us thought the style guide was weird but endearing, and some of us thought it was a crime against the English language. I was in the “endearing” group. It didn’t bother me too much to break all these rules. The owner obviously had strong opinions, but he was also trying to do something with his wacky style…he was trying to liven up the dry material.

His way may not have been the way most technical writers would choose, but his way did have a benefit: when people liked his training materials, they REALLY LIKED his training materials. His company had a loyal group of customers who had to maintain their certifications, and they bought his training materials to help them do it year after year. People called customer service just to say that they loved the “personality” in our materials. The owner understood his audience.

Maybe my exposure to that first style guide is context for my approach to style guides today. A few months ago, I introduced myself to some folks and said that I’m a technical writer. My introduction started a great discussion about the serial comma. They were really passionate about it. One guy even said that when his work teammates disagreed over whether to use a serial comma, they called an English professor to settle it. Then they asked me what I thought. I said, “It depends on what the style guide says.” And that’s how I feel about it!

Structure and consistency in your writing are good. The fact that there are rules shows, even if the rules aren’t perfect. The point is to be understood, not to be right.

I love style guides. They solve so many problems and settle so many questions. You don’t even have to develop your own in-house style guide for your technical documentation. There are plenty of style guides out there. Find one that applies to what you’re doing and start using it.