in reply to
Introduction to Technical Writing/Documentation
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