Subject: Re: Bloated Docs: Identifying What's Useful

Subject: Subject: Re: Bloated Docs: Identifying What's Useful
From: Walden Miller <Walden -dot- Miller -at- canoeventures -dot- com>
To: "techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Sat, 25 Feb 2012 18:27:38 -0500

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,


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.


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @


Previous by Author: styleref workarounds
Next by Author: Re: WRONG!..... -ish?
Previous by Thread: Re: Question about a Home Wireless Network
Next by Thread: Re: Subject: Re: Bloated Docs: Identifying What's Useful

What this post helpful? Share it with friends and colleagues:

Sponsored Ads