Authors: Michelle Carey et al
Publisher: IBM Press
Pages: 624
ISBN: 978-0133118971
Print: 0133118975
Kindle: B00L7ZKJ26
Audience: Those who produce technical documentation
Rating: 3.5
Reviewer: Kay Ewbank

This book gives clear and well written advice on how to write technical documentation, though you may think the advice given is obvious.  

This is the third edition of a book that first appeared back in the 1990s, and is still going strong. The latest edition has been updated again to reflect the increasing importance of online documentation as opposed to printed manuals and texts.  

The book opens with a brief section introducing the role of the technical writer and how it has evolved. In Part II, the authors get straight into ways to produce good technical documents, starting with the fact documentation should be easy to use. You might think this is obvious, but just think of all the manuals and documents you’ve read that are incomprehensible. The chapters in this part of the book discuss task orientation (write for the intended audience, focus on users’ goals); accuracy (research and verify your information, be consistent); and completeness (cover all subjects that support users’ goals, and only those subjects). Again, all fairly obvious but often ignored.

Part III is titled 'Easy to understand’, and has chapters on clarity (write coherently and avoid ambiguity); concreteness (relate examples to knowledge or experiences the users already have); and style (use active and passive voice appropriately and be consistent over grammar).   

The next part of the book considers how to make information easy to find, with chapters on organization (put information where users expect it); retrievability (optimize for searching and browsing); and visual effectiveness (use meaningful graphics).

The book ends with a section on putting it all together that has a useful chapter on reviewing and testing technical information.

I wasn’t at all sure what rating to give this book. It’s well written, easy to read, and makes some useful points, but I kept thinking that surely this is all just obvious stuff. Then again, a brief glance at the manuals or online documentation for just about any software or hardware product you care to mention shows that this obviously isn’t obvious stuff.

If you have to maintain documentation, it’s worth reading, but be prepared to think it’s all fairly obvious.