Sharp Words

As discussed in previous posts, technical documents typically go through several draft phases. A first draft is often incomplete, and it can take a few more drafts and review cycles before a document is ready to go out to its intended reader (and can be classed as a ‘deliverable’).

But how can you stop well-meaning support agents and sales people getting hold of a draft and passing it on to the customer? How can you stop unfinished documents being published to your website with glaring errors and ‘TO DO’ markers?

Well, you can’t always prevent your drafts getting out into the wider world. But you can minimise the damage.

1. Use a watermark or header/footer to mark your documents as DRAFT. Having that stamped on every page makes it very clear that the document is not complete.
2. Enforce source control and don’t let people have access to unfinished documents if there is no reason for them to have! Of course, this isn’t always possible; and if there’s no central control (you!) to make sure that everything that goes out is fully complete and wholly accurate, then that just makes preventing disasters twice as hard.
3. So… Encourage disclaimers – if you don’t have control over what goes out publicly, then at least make sure that any colleagues who may send documents out know to do so with a disclaimer that the document isn’t finished.
   Have a disclaimer added to the front page of any draft documents too, as belt and braces!

If draft documents are regularly given out to customers (with or without your say-so), then it might be worth having an ‘early adopter’ scheme. Create a ‘special’ draft (perhaps when your document is 90% complete or just one or two reviews away from being signed off) which can be given to customers by support and sales staff. Call it a beta release of the document, if you like, in line with software naming!
One advantage of this method is that you instantly get an extra set of reviewers – and importantly, they are the type of people who the document is aimed at, which means that you get exactly the right sort of readability review that many tech writers can only dream of…

PS: Thanks to Andrew for the topic suggestion. Other suggestions for topics in this series are very welcome! I’m up for covering general issues like this, or for writing more specific how-to articles. Or anything related to technical writing, really!

————–
If you have any questions or comments about this article, or any suggestions for future posts, please comment on this post or email me via my contact form.
Technical Writing Tuesdays: index of posts