Perhaps the single most important aspect of technical writing is clarity - making your meaning readily apparent and unambiguous. If your document is unclear, then not only are you wasting people's time as they try to read and understand it, you could cause potential disaster if they misapprehend a crucial safety guideline, or misuse software with sensitive data. Your entire document must be as efficient and effective at communicating the information as possible. Seven rules for clarity:

Now we have our client, our table of contents that tells us what we'll be writing, and our meta-documents that tell us how we'll be writing it. So we're ready to actually write the thing, yes?

Well, yes and no. Now, your next step depends on what software you're using. If you're writing this whole thing monolithically in Microsoft Word or Open Office without the aid of VB-scripting, then yes - have at it. If, however, you're following the industry development into topic-based content and single-sourcing, then no.

Last session, we had our table of contents all planned out, and we created our Subject Matter Thesaurus. Now, we're ready for the second meta-document: the style guide.

So, you've planned your document, quoted your client, and they've come back with the go-ahead. You're now ready to start writing those pages, yes?

No.

There's another step first - one that's not-so-obvious, and very tempting to skip when you have a table-of-contents sitting tantalisingly in front of you. I've worked with several technical writers who haven't bothered with this step for various reasons, and the lack of it shows in their documents, and in the amount of time it takes to get new writers up to speed on the project.

Having just-about-finished the coding for version 1.0 of SubTracker, I'm embarking upon its documentation. I can remember some time ago, when I first considered technical writing as a day-job (and again, not that long ago when I began my contract) I shuddered at the terrible question of how do you actually write a technical document? Where do you start? What goes in it? How do you make sure you get everything? What mysterious tasks are you expected to do besides from give people a document about their software? It's not as daunting as it looks, even for megolithic software packages. 

There are different breeds of technical writers. Some are masters of Microsoft Word, having learned every hidden feature and function (don't laugh, it's actually a very powerful application, but most of it's hidden so as not to scare your grandma). Others shell out a lot of cash for fancy authoring tools like Flare, RoboHelp or Author-It that do everything but walk your dog, and others settle midway for a not-really-best-of-either-but-at-least-it-wasn't-pricey* option, such as pairing Adobe InDesign with a very organised set of text files. Where I currently work, I have the advantage of my employer's Author-It license, but as a contractor I've been considering what I'll do in future.

Technical writing is the process of designing documents to communicate their message with the maximum clarity and efficiency possible. It is, contrary to what many industries rationalise in hard times, a skill that cannot be replaced by your average engineer with a word processor and a diagraming tool. It demands high levels of English (or your language of choice, but most documents will need an English translation at some point) grammar and communications, analysis, design and organisation, attention to detail, and discipline.

Due to the aforementioned industry opinions, it also requires a thick skin, as a lot of the SME's (Subject Matter Experts) you'll be interviewing while you research the document will think you're a waste of their time, and that there's nothing wrong with the document they have already, even though it's only three pages long, contains no diagrams, and hasn't been updated since the initial software release. Welcome to techwriting.