“But the deadline’s coming up fast, we’ve just got to start cranking out the content, pronto!”

A former technical writing manager told me this a while back when our documentation team was struggling to produce consistent content for the new software release. And it would have been an acceptable reponse and exhortation to us, if we had an established style guide we could use while writing this content.

After having worked as a technical writer for almost 8 years now, style guides are more of a reference rather than a strict guideline for me, as they all tend to be fairly similar. For example, using italic formatting for screen names, or writing “click Done” instead of “click on the Done button”. So writing the existing content for this employer was a relatively easy task, however at this stage the software developers were completely revamping the application. And our tech writing manager wanted a new “tone” for the UI and Help content.

Wonderful – except we didn’t have a style guide that laid out all of the guidelines that he wanted us to follow!

Half of the team was new to the company, and the new “tone” was radically different from not only the existing style, but from standard tech writing practices. So it was new to everyone. Yet my manager just wanted us to muddle our way along, producing content as best we could.

This situation was frustrating for a number of reasons:

• I have personally written and/or maintained style guides at 3 different large software development companies, so I felt qualified to write up the new one for this company.
• My manager had me start writing up they style guide, but he only wanted me to focus on the UI terminology section. Which would have been fine, if he allowed me to schedule the rest of the style guide as well. I had the time to complete the full style guide, yet he vetoed my every request to do so.
• We writers kept tripping over each other and delaying each other’s work with email threads of the “Do we click a button or click on a button?” and “Should we apply bold formatting to page names?” variety.

In the end our team was quite late in delivering the content to the development teams for prototyping, and my manager was concerned about the quality of the content itself.

From this situation I’ve learned the following, which I think can apply to all technical writers (and I’m going to use a numbered list here even though you don’t need to follow these in a sequential order–other tech writers, you’ll know what I mean here. *wink*):

1. Creating a style guide before you write a single sentence of content will save you a lot of time, both for existing technical writers and new ones you bring on board during the content development.
2. Saving time at the beginning of the writing process means you’ll have more time later to revise or solicit input from other teams and departments.
3. Style guides help technical writers feel more confident about the content they’re producing, which in turn makes their writing even better.

So if you’re looking to decrease your writing time, and save your company some money, take the time to write a style guide (or at least update your existing one) before you start writing your content. Your writers and your users will thank you.

Contact Julia today if you need a new style guide written up, or if your existing one needs some revision. She’ll help you save time and money.