One of the problems with doing user manuals as part of my day job (the WANScaler group at Citrix Systems) is that the scheduling is always so wacky. You can’t document the product precisely until it stops changing, and it doesn’t do that until the last minute. Then the documentation has to be done in a rush. Good thing I like a challenge! So I’m in a tremendous rush to get everything done for a big software release.
There are some specific techniques for making this work. The most important one is to be a bona fide expert on the product, so you already know what it does, why it does it, and why the customer should care. You can’t succeed at a last-minute rush if you’re faced with big knowledge gaps. You just need to catch up on what the last-minute changes do.
The other technique that works for me is to never write a partial draft of anything. I try to write production-worthy copy in a single pass. By not leaving any gaps or guesses in my work, I don’t have to keep track of them. Learn first, then write.
The beauty of this method is that it dovetails with the last-minute-ness that the schedule demands. I spend the early part of the project learning everything about it, testing it, lobbying for improvements, etc. When it’s time to write up the new features, my research is all done and I can simply emit the text and diagrams. Pretty spiffy.
Also, writing is hard. Getting into the zone is painful. Once you’re there, it’s fun, but you need to stay in the zone. So doing your writing in big chunks is less painful than the alternatives.
I Publish Books! Norton Creek Press
 |
 |
 |
 |
