TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
This is a nice thread. I have done much of this before (recently). And I took a slightly different approach but with much the same results.
I have a couple questions though….
1. Is there any product requirement docs OR at least a product manager in the picture? If so, she or he well be a great asset.
2. What is the range of documentation? Administration, reference, installation, integration, operation, etc.
Depending on the answers, this is what I might do.
1. Determine the technical level required to use the product.
2. Determine the technical level required to understand the data or effects of the product.
3. Determine what the technical level of user will be to use the product
The first two are not simple audience analysis because you really don't need to talk to your audience to find out the info. But they give you a great starting point for weeding out information that is unnecessary or could be rewritten. The third may be important only in the sense of multinational issues. I had a job once in which third world farmers had to use a hand-held computer (in 1990- so no tablets) to input data about their crops. The assumption was they had little to no computer experience. The program and docs were in 20+ languages.
4. Divide all the text into the components/buckets for products: install, tutorial, operation, reference, administration, customization/integration
5. Deal with only one set at a time.
6. For operations, try to determine the tasks required of your readers. This is a nice Product Management task. If not apparent and no PM, then the survey methodology is quite effective: ask what they need to do with the product.
7. For reference, try to divide everything into must have and nice to know. Put all the nice to know on hold or in the bit bucket or in a set of apdx or whatever. Don't lose sight of the objective: cleaner docs with purpose.
Don't forget about Administration of the product, if you have that type of product. You best allies here are tech support.
Tech Support is just a good group to lean on. They probably know a lot about questions that are not in the manuals and about tasks that are problematic AND about administration of the product.
With the 14 languages of translation involved, understanding the constraints of translation is very important. Katarina has nice insight on programs that can help. Whatever process your company uses, you need to be very involved.
Everyone else has really put in nice comments, so these tidbits are additive :)
Have a nice weekend,
walden
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
