OverviewProduct 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 themEvery 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:
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 ProductAfter 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. Here are three examples:
Example 1: 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.
Example 2: One of the worst omissions is to leave out a tip that is essential to the use of your product. I have a manual can opener that clamps and locks to the can when you squeeze the handles together. However, it requires a hard squeeze to clamp the can opener to the can. In fact, the handles flex and make this task almost impossible.
My son discovered a tip that the manufacturer forgot to mention. If a User squeezes the handles with moderate pressure, and at the same time turns the knob that moves the can around, then the clamping will be a simple process. This tip changes the use of the can opener from a frustrating task to a simple one. Yet the manufacturer "forgot" to mention it. Had they never used their own product?
Example 3: 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 ReaderA 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:
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 LifeI 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
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' CommentsAsk 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 LineShare 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:
And those are the things we want to do to help our company thrive.
Great Technical Writing: The User-Product Life Cycle - A Documentation Tool
The User-Product Life Cycle (U-PLC) is a powerful tool for the User Document writer. Use the U-PLC to generate the high-level topics for your User Document.
Great Technical Writing: Tell Your Users What to Expect
In your User Documentation, you direct your Reader to perform tasks with your product. If you don't tell your Reader what to expect when performing those tasks, you will have a baffled Reader, resulting in dissatisfaction and expensive calls to technical support.
New Technical Writer: Conquering the Fear of Writing
Stepping into the role of a technical writer can be daunting, especially for those without a writing background. The task of creating User Documentation for a new product might stir up fear and anxiety, reminiscent of school days filled with writer's block and critical evaluations. However, writing for a user manual is a unique process that differs significantly from academic writing. This article aims to guide new technical writers through the process, providing strategies to overcome anxieties and produce effective documentation. With the right approach and resources, anyone can craft clear and helpful user guides.
