Great Technical Writing: Has Anyone Ever Used Your Product?

Product documentation gives the feeling that nobody has ever used the product. Most documentation:

. Ignores the product's failings (warts), and how to overcome them.

. Leaves out tips that would improve the User's experience with the product

. Leaves out knowledge that experienced Users could share with the new User

Before you release a product, have some people use it. From these "test users" get solutions to problems, tips and knowledge that would help your real-life Users. Put that information in your User Documentation, and on your product support Website.

Three More Ways That Your User Documentation Fails Your Reader/User:

1. Ignores the product's failings (warts), and how to overcome them

Every product has "warts". Warts are the failings of your product. A wart might be something that the current version of the product cannot easily do, but needs to be done.

Here are some examples of product warts. Some of the warts can only be cured in the next version of the product:

. A telephone answering machine that has no wall mounting. It only takes a small change in the mold of the plastic for the back of the unit to enable screws to hold the device on the wall. The answering machine has its cable permanently connected to the device, making it difficult to use a shorter cable when needed.

. A word processor that has the most unusual and troublesome defaults. These cause the users a myriad of problems, including reformatting an entire document when a small change is made to the appearance of a piece of text.

. An electrical sub-panel for eight circuits that only has room for four ground wires. This makes it difficult to connect all the circuits.

. A five-stage water filter that does not mark which of its filters fit into which holder.

. A graphical (windowing) computer operating system where the mouse cursor jumps around the screen.

. A toaster oven with an electronic timer built in, that does not stay on long enough to toast an English muffin in one toasting session. (It only takes a larger resistor in the timing circuit to make it work properly.)

. A digital timer coffee maker (I love this product for its flaws and the flaws in the User Manual). Quiz: For home use, when do you think most people want to have coffee automatically brewed? I think it's in the morning. However when a user sets the clock, the time display starts at 12:00 A.M. But when the user sets the brew timer (when the coffee will begin brewing) the timer starts at 12:00 P.M. This is not just a flaw; this is silly.

The Users of your product need to know how to get around its warts. Think about these warts, how to overcome them, and the best way to tell the User the techniques you find.

If you do not think that your product has warts, then you may be living in a fantasy world. The entire concept of the "next version" of the product suggests failings in the product. If these shortcomings are not in the product itself, then they are failings in our understanding of how our User needs to/wants to use the product.

2. Leaves out tips that would help the User in his/her experience with the Product

After using any product, one comes up with tips for better use. Share these tips with your Users so they will have the best possible experience with your product.

Probably the most outrageous missing tip is a product feature that is not described anywhere in the User Documentation. I have a low-flush toilet. These toilets have been the butt (sorry about the pun) of jokes because they have trouble with large quantities of "solid waste." My toilet has an undocumented feature. If I hold the handle down the entire time the flush is taking place, there will be extra water to handle the large quantity of "solid waste." But it's not documented! That is really a missed tip!

Think about how your User might want to and need to use the product. Add tips to help him/her.

Almost all computer software documentation leaves out a very important tip. It's a fact of life that users change computers every few years. Yet software documenters never describe how to move the User's data from the old machine to the new one. This is a failure of most software documenters to face reality.

3. Leaves out knowledge that experienced Users could share with the Reader

A front-loading washing machine has two spin speeds: "Normal" and "Fast". The User Document merely says to 'set the spin speed.' However I am confused. The User Document writers should have told me the benefits and the costs of using each spin speed. This information would help me decide what speed to use for my particular situation.

Computer language reference manuals are another good example of missed knowledge sharing. In many languages (for example the C or C++ languages in the UNIX environment) there are many ways to perform an operation. In computer jargon there are many different functions (or methods) that a programmer can use to do something with the computer. Yet these language manuals do not provide the knowledge that will help a programmer decide which function or method to use. The developers of the language know. It is only a matter of sharing the knowledge.

A good rule of thumb is that if your User has to make a decision, provide the information that will enable him/her to make the best decision.

The knowledge need not only be gained from your own use of the product, but from the product's industry. Let me give you two examples:

. A blood pressure monitor: Its User Manual provides a chart of blood pressure ranges and their meaning. That is good.

. A dehumidifier (or, also true for humidifiers): Its documentation does NOT tell the best range for indoor humidity. That is not so good.

Often it only takes a small table or a few lines in the User Document to provide this beneficial information, yet for some reason it is left out.

Test in Real USER Life

I bought a device (an "FM transmitter") that enables my MP3 player to play through any FM radio. The problem is that the transmitter distorts the sound. However, if I turn down the volume on the MP3 player when connected to the FM transmitter, the distortion is reduced. There is no tip or instruction in the User Manual telling me to turn down the volume. When I hear the unclear sound, I'm disappointed in the product, and believe that the product does not work.

I am sure that the company tested their FM transmitter. I am also sure that they were careful to set the volume on the audio source (MP3 player) low enough as not to distort. That is NOT a Real User life test.

In real life, the User would set the volume for comfortable headphone listening. Then when connecting the device to the FM transmitter, the volume would be too loud and the sound from the FM radio would be distorted.

My guess is that either

. The people testing the product never set it to the Users' real-life volume settings (they did not test in Real USER life)

. Or, if they knew that the User's headphone volume would be too loud, they felt that "everyone could figure it out" and did not include this knowledge (as a tip) in their instruction sheet.

By including the volume-setting information, the User would be more satisfied with the product, and thus less likely to return it.

Solicit Real Users' Comments

Ask your Users to comment on their real-life experiences with your product. Have them provide you with the tips, techniques, and shortcomings that they have discovered while using the product. Publish this information in later versions of the product's User Document, and on your product's web pages.

The Bottom Line

Share the experiences that your organization has with the product. Add relevant tips to the User Documentation. Add the knowledge that you uncovered in your experience with the product. Give remedies for the product's warts.

Doing so will improve your Users' experiences with your Product. Improving your Users' experiences with your product will:

. Reduce support costs

. Improve sales

. Reduce product returns

And those are the things we want to do to help our company thrive.