Great technical writing – has anyone ever used your product?
Product documentation gives the impression that no one has ever used the product. Most of the 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. From these “test users” get solutions to problems, tips and insights 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. Ignoring product flaws (warts) and how to overcome them
Every product has “warts”. The warts are the flaws in 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 doesn’t have a wall mount. Only a small change is needed in the molding of the plastic on the back of the unit to allow screws to hold the device to the wall. The answering machine has its cord permanently attached to the device, making it difficult to use a shorter cord when needed.
. A word processor that has the most unusual and troublesome defaults. These cause users a whole 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 into which holder.
. 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. (Just need a bigger resistor in the timing circuit for it to 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 their 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 the coffee will start brewing), the timer starts at 12:00 pm This it’s not just a glitch; 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 his 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 egregious 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 entire time it is flushing, there will be extra water to handle the large amount of “solid waste”. But it is not documented! That’s really a miss tip!
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 change computers every few years. However, software documentarians 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 the knowledge that the Experienced Users could share with the Reader
A front-loading washer 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 what speed to use for my particular situation.
Computer language reference manuals are another good example of lost knowledge sharing. In many languages (for example 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. Language developers know this. It’s just a matter of sharing knowledge.
A good rule of thumb is that if your User has to make a decision, provide the information that will allow you to make the best decision.
Knowledge should not only be obtained 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: Your User Manual provides a chart of blood pressure ranges and their meaning. It’s okay.
. A dehumidifier (or also valid for humidifiers): Your documentation does NOT indicate the best range of indoor humidity. 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 to tell me to turn the volume down. When I hear the unclear sound, I am disappointed with the product and I think the product is not working.
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 life test.
In real life, the user would set the volume for comfortable listening with headphones. So when connecting the device to the FM transmitter, the volume would be too high and the sound of the FM radio would be distorted.
My guess is neither
. The people who test the product never set it to the Users real life volume settings (they did not 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.
Request feedback from real users
Ask your Users to comment on their real life experiences with your product. Ask them to provide you with tips, techniques, and shortcomings they have discovered while using the product. Publish this information in subsequent 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 he discovered in his experience with the product. Give remedies for product warts.
Doing so will enhance 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 business thrive.