Great technical writing – has anyone ever used your product?

The product documentation gives the feeling that no one has ever used the product. Most documentation:

. ignore the product failures (warts), and how to overcome them.

. let tips that would improve the user experience with the product

. let knowledge that the experienced Users could share with the new User

Before you launch a product, get a few people to use it. Get troubleshooting, tips, and insights from these “test users” that would help your real-life users. Include that information in your User Documentation and on your product’s support website.

Three more ways your user documentation fails your reader/user:

1. Ignore product flaws (warts) and how to overcome them

Each product has “warts”. The warts are the faults of your product. A wart may be something that the current version of the product cannot easily do, but it must be done.

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

. An answering machine that does not have a wall mount. Only a minor change to the plastic molding on the back of the unit is needed to allow the screws to hold the device to the wall. The answering machine has its cable permanently attached to the device, making it difficult to use a shorter cable when needed.

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

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

. A five-stage water filter that doesn’t mark which of its filters fits in which bracket.

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

. A toaster oven with a built-in electronic timer, which doesn’t stay on long enough to toast an English muffin in one toasting session. (It just takes a bigger resistor in the timing circuit to make it work properly.)

. A coffee maker with a digital timer (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 coffee to brew automatically? I think it’s in the morning. However, when a user sets the clock, the time display starts at 12:00 am But when the user sets the brew timer (when will the coffee start to brew), the timer starts at 12:00 pm This it’s not just a fault; this is silly

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

If you don’t think your product has warts, you may be living in a fantasy world. The whole concept of the “next version” of the product suggests flaws in the product. If these deficiencies are not in the product itself, then they are failures in our understanding of how our User needs/wants to use the product.

2. Omits advice that would help the User in their experience with the Product

After using any product, one comes up with tips for better use. Share these tips with your Users so they 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 (pardon the pun) of jokes because they have problems with large amounts of “solid waste.” My toilet has an undocumented feature. If I hold the handle down the whole time it’s flushing, there will be extra water to handle the large amount of “solid waste”. But it is not documented! That is really lost advice!

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

Almost all software documentation leaves out one very important piece of advice. It’s a fact of life that users switch computers every few years. However, software documentalists never describe how to move user data from the old machine to the new one. This is a failure of most software documentarians to face reality.

3. Leave out knowledge that Experienced Users might share with the Reader

A front-loading washing machine has two spin speeds: “Normal” and “Fast.” The user document simply says to “set the spin speed”. However, I am confused. The writers of the user document should have told me the Benefits and the costs to use each spin speed. This information would help me decide which speed to use for my particular situation.

Computer language reference manuals are another good example of missing 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. However, these language manuals do not provide the knowledge that will help a programmer He decided which function or method to use. The language developers know this. It’s just a matter of sharing knowledge.

A good rule of thumb is that if your User has a decision to make, provide the information that will allow them to make the best decision.

Knowledge should not only be gained from your own use of the product, but also from the industry of the product. Let me give you two examples:

. A blood pressure monitor: Its User Manual provides a table of blood pressure ranges and their meaning. It’s okay.

. A dehumidifier (also valid for humidifiers): Its documentation does NOT indicate the best indoor humidity range. That’s not so good.

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

Test in the real life of the USER

I bought a device (an “FM transmitter”) that allows my MP3 player to play any FM radio. The problem is that the transmitter distorts the sound. However, if I turn down the volume of the MP3 player when it is connected to the FM transmitter, the distortion is reduced. There is no advice or instruction in the User Manual that tells me to turn down the volume. When I hear the unclear sound, I am disappointed in the product and think that the product does not work.

I’m sure the company tested their FM transmitter. I’m also sure they were careful to set the volume of the audio source (MP3 player) low enough not to distort. That is NOT a real user lifetime test.

In real life, the user would set the volume to listen comfortably with the headphones. So when connecting the device to FM transmitter, the volume would be too high and the FM radio sound would be distorted.

My guess is neither

. People who test the product never set it to Users real life volume settings (didn’t test on USER real life)

. Or, if they knew the User’s headphone volume would be too loud, they felt “everyone could figure it out” and didn’t include this knowledge (as advice) in their instruction sheet.

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

Solicit feedback from real users

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

The bottom line

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

Doing so will improve your Users’ experiences with your Product. Improve the experiences of your Users with your product:

. Reduce support costs

. improve sales

. Reduce product returns

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