Latest posts by techwriter (see all)
- What is the Readability Index of Your Writing? - November 20, 2017
- Should Technical Writing be Boring? And if Yes, Why? - November 15, 2017
- How to Create a Custom-Designed Header in MS Word that Would be Available to All Other Word Documents - November 13, 2017
© Ugur Akinci
“Can you tell us more about quality in technical writing?” a reader asked yesterday, in a private email.
Here are my thoughts on the topic:
1) Quality starts with intra-team cohesion, if you are working as a part of a technical writing team. If you’re a lone writer, this means you should either have your own guidelines in place or should be aware of the one used by your client. Without a documentation guideline to lead the way, the quality of deliverables is bound to suffer since every “new idea” will inevitably pull the project in a new direction. And you know how the food tastes when too many chefs add too many ingredients to a dish. Same story here with documentation.
2) Related to that, the writing team should have a clear division of labor with well-defined roles for team members. If one technical writer is also good at drawing illustrations, having her provide such graphic support will only enhance the quality of the end product just like having only one person (e.g., the lead writer or the doc manager) interface with the upper management would avoid conflict messages and promises.
3) Quality also depends on a very clear workflow. The documentation team (even when you’re working alone) should be aware of the steps involved from start to finish in the production of a document. Related to that, there should be a clear production schedule and it should be reported and enforced through regular department meetings.
4) Review cycle is a very important ingredient of documentation quality since it’s rare that the first draft of any document is good enough for release. Usually documents go through at least two or three review cycles and I had those long stretched-out projects in which I’ve generated over 10 drafts, spanning over a year. For the review process to work, you need to commit the reviewers to a review calendar and follow it up religiously. Reviewers are usually SMEs, that is, very busy people. You need to keep tabs on them to make sure that the process moves smoothly, with an even pace. Last minute correction and revision nightmares can be avoided if a commonly-shared review system is in place.
5) Peer review is another crucial ingredient of quality in technical writing. I’m always amazed at the things my wonderful colleagues find in my documents, just like I find similar things in theirs. An extra pair of eyes is always important to ensure quality. Don’t skip the peer review for personal reasons if you want to keep up with your quality commitments.
6) Lastly, I can’t emphasize enough the importance of education and training in our fast moving technical communication field. This business of ours is changing at such a pace that I quit buying tech books a year ago since no matter which book I buy it’s bound to be at least partially out of date. (In case you’re wondering, I’m using wwwq.safaribooks.com monthly service to keep up with all the new publications in my field. Highly recommended.) A technical writer who does not renew herself and keep learning new techniques, platforms, and approaches, is a writer that might be without a job in the medium run. That’s why I firmly believe that budget reserved for training is a “profit center” item (and not a “cost center” item) for organizations that would like to remain in the forefront of global competition.
There are of course many other factors that contribute to overall quality in technical communications but these are the ones that jumped for my attention as I was preparing this list.
How about you, dear reader? What do you think about “quality”? Which other factors would you bring up within the context of this conversation? You’re welcomed to share through comments link below.