Journals by RSS
Journals by EmailOur organization has a style guide, and I’ve come to appreciate that fact. Style guides can seem like a relentless master who has bent you to his will, and now his every whim is your reason for breathing. I’ll admit that I don’t agree with everything in the guide. However, without a style guide, life is chaos.
I’ve been thinking about this lately because somebody other than me develops prototypes for our applications. The fact is that whatever the interaction designer puts in the prototypes goes into the actual application. This means that if there is inconsistent capitalization in headings, that inconsistency lands itself in the final product.
That’s where I step in. Being a technical communicator, I’m driven by the need for consistency and clarity, and where I’m driven is crazy sometimes. I can be a little fanatical, but you know that there are users like me out there, and their opinion of the organization may suffer if they see a lack of polish in the software.
Sometimes, problems may not lie in outright inconsistencies; they lie in deviations from the organization’s style guide. No offense or belittlement meant to interaction designers, but they’re concerned with just what their titles suggest: They set out how the users and software interact with each other. It’s a subtle idea that part of the interaction is the text.
Perhaps it’s not so subtle. Interfaces contain graphics, including icons, that affect interaction. But much of the interaction relates to text. In cases where text in and of itself is correct but doesn’t adhere to the style guide, you may run into inconsistency between applications that should be consistent among themselves.
There are times when I have to forgo my personal preference in favor of what the style guide dictates, but at least I can rest assured that I’m contributing to the product’s professionalism. Interaction designers and developers in the project teams in which I work have become accustomed to and accepting of my input in matters textual. I feel like a hound on occasion, but someone has to take on that role. If there’s no watchdog in the barnyard, the fox will make off with the chickens.
And I like chicken, so I can’t let that happen.
Related posts (auto-generated):
5 Comments to 'Style Guides: Love Them or Hate Them?'
July 17, 2008
I enjoyed reading this post. I’m in the process of setting up such a style guide for an intranet portal and associated documentation.
Not only does following a style guide make the site look more professional, but it makes updating the content easier.
July 17, 2008
Learning about company style guide is like learning a whole new language! My company has a very lengthy style guide because we have hundreds of products with documentation written by many technical writers.
While having a style guide brings a certain order and professionalism to documentation, I wonder whether style guides sometimes get in the way of writing user-friendly documentation. What do you think?
July 17, 2008
Gwen,
Lucky. If I could write the style guide, I’d feel like the king.
As we’ve talked about style in our team, it’s reminded me of how thorough they can be. Our organization’s style guide is fairly extensive, and we’re also supposed to use the Chicago Manual of Style for anything not specifically set out in the guide. But we discuss things sometimes that aren’t covered. Some style guides can be brief and cover only a few usage choices and branding, but others can really get down to the nitty-gritty and have a prescription for everything (perhaps like the one Susan mentioned…). I hope yours isn’t a major project all on its own.
Susan,
“User-friendly” is a very broad term. So in some cases, a style guide can enhance user-friendliness because it provides consistency. Consistency breeds familiarity, which in turn breeds friendship, and we’re talking about our products being friends with the users, right? (Just playing on words here…) Do you have any specific instances of style getting in the way of friendliness?
July 19, 2008
For the most part, I agree that style guides provide good guidelines for consistency, clarity, familiarity, and order.
I could think of a few examples in which styles can get in the way of friendliness.
1) legal implications — words/phrases we’re not allowed to use because of legal implications. Work around would be to break another rule or be very wordy
2) fancy words/terminologies for marketing sake — the other day, I had a discussion with a colleague regarding the way we refer to specific items both internally as well as in documentation. We create fancy words to distinguish our product from other products. It’s all about “branding.” So my question is whether end-users really understand our language or that they’d prefer simpler more familiar language For example: “input/output” are simple terms. We use “controls/indicators” instead. I end up writing something like “wire the aaa control of xxx to the bbb indicator of yyy. Then wire the ccc controls of yyy to the ddd indicator of zzz.”
3) Passive voice — generally technical documentation should steer as far away from passive voice as possible. But occasionally, I wonder whether we need to turn a simple sentence to a lengthy paragraph just to explain who did the action. Examples: “expected values” “… as shown in the following figure.”
Anyway . . . I agree with you that style guides are good. They’re just annoying sometimes.
Trackbacks