There are a variety of processes involved in the creation of user documentation. The planning process must begin long before the software is ready for testing. Using the technical specifications, I outline a rough draft, setting up chapter and section headings. I leave placeholders for screen shots where appropriate, and prepare a glossary and an outline for the quick reference guide.
Once the initially "build" – that is a first run-through of the viability of the software – is complete, I actually sit down at a computer on which the software has been installed, and compare the actual procedures to those that I have derived from the technical specifications. I pull preliminary screen shots to replace my placeholders, and write the actual steps that comprise the process.
This first draft is then sent to the validation department for review. A validation technician will take my document and compare my written instructions to the actual process. This person will mark up my document, indicating where changes need to be made, and returning it to me for rewrite. I rewrite the document, and then resubmit it to the validation department for review.
Each time a new build is completed, I review the specifics to determine whether or not anything in the manual needs to be updated. This process can take place daily, weekly or even monthly depending on the priority level placed on the project. I also attend development team meetings to learn about upcoming changes or new features that are being added to the program.
This process of writing, validating and rewriting continues until the software is ready for alpha testing. My company arranges for a customer who is using our product to have an updated, unreleased version of the software to use on their system. This process allows us to determine the viability of the product, and to receive feedback from the field. During this phase, I normally will visit the site and watch as the technicians use our systems. I interview the technicians and ask their opinions on the "usability" of the manual itself. Taking this feedback, I generally will do another rewrite of the manual, tailoring things accordingly.
When a change is made in hardware, that also must be documented. This may sound fairly simple but it the most challenging part of the job. The problem is that there is little communication, and I am usually the last to know about changes. I have worked to institute better channels between the designers, marketing, engineering and myself, but this frequently breaks down.