The Manual is the Product

There are always nuggets of great information out there. Here's one I stumbled across today:
A few random notes from my 23+ years of tech writing:
Words can take a person from point A to point B. If a person isn't at point A, or doesn't want to go to point B, then the text will be a mismatch. The better you define point A, explain it, define point B, explain it, and then accurately keep A and B in mind as you're writing, the more successful you'll be with the readers.
As an expansion of the previous point, I write books and columns to a single reader, whom I usually call "Joe". I define what Joe knows at the beginning of the book, and at the end of each chapter, and then I keep Joe in mind as a real, single reader while I'm writing. Seems to work nicely, and keeps me from handwaving or forgetting prerequisities.
In product documentation, the manual is the product. If a feature isn't defined, it doesn't exist as far as the user can tell. If a feature is described badly, the user will percieve the product to be a bad product. Thus, do not skimp on the documentation.
When you write a piece, read it aloud to a friend, or the wall if you have no friends nearby. If it doesn't make sense when read aloud, start over. That'll keep you from writing stuff that "looks good to your English teacher", but is truly useless in the real world.
-- Randal L. Schwartz, Perl hacker
It's rare to find such specificity in tips. "Do a lot of research" is great, but here, Mr. Schwartz says, "the manual is the product" and features don't exist if the technical writer doesn't take the time to define them. I've created a few basic manuals, but I wish I could have gone back to flesh them out more.

Always have someone read what you've done. Well, always have someone qualified, and someone who can use a critical eye to help you fix what might be broken. It helps when you marry a Literature major.
Enhanced by Zemanta