Discussion on:

10 things you should know about working with technical writers

Make the Technical Writer part of the team and have them become the first "user" of your new project. The writer represents a fresh set of "uncontaminated" eyes on how your projects looks and feels to potential users. The writer can be an excellent source of finding bugs and awkward/convoluted interaction paths. If your company writes several applications for the public, the Technical Writer can help ensure a consistent "look and feel" amongst all of your applications.

I used to be one-removed from the Tech Writer. I developed training for the user on the software product. We too, need to be in the loop. I test each "lesson" and can find "bugs" in the software AND in the documentation. On a complex software product I discovered a problem when I tested my training materials with 12 simultaneous users. The system froze! It was discovered (much later) that each software developer had both a client and a server on their system while testing -- they didn't notice that the software couldn't run with a single server and multiple clients !

Pet peeve: Too many User Guides simply state, "The Widget button sets the Widget." without describing the result of "setting of Widget" or in what situations you would want to do that.

...it's an absolute necessity. It keeps the customers happy and reduces support costs.

The writer needs time to learn the product well because, without close knowledge, he can't do a good job. Hiring a writer at the last minute is not only cheap, but an insult. High-quality documentation takes time. It can't be thrown together at the last minute.

After 30 years, I retired from two of Eaton Corporation's plants in WI as a Sr. Technical Writer. To be successful, I worked closly with engineers & assembly areas in the factory. David Kennedy, Adams, WI