Great Technical Writing Series


Home | Contact | Site Map

Navigation:  Home -> Reading Room -> Great Tech Writing Series -> This Article

Has Anyone Ever Used Your Product?


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

  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:

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.  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 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:

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

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:

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


Barry Millman, Ph.D., has a Bachelor of Science in Electrical Engineering (1966, Carnegie Institute of Technology) and an M.Sc. and Ph.D. in Psychology (Human Information Processing, University of Calgary).  He has been a consultant for over 25 years, an instructor, course developer, and award-winning speaker.  For the past seven years he has been researching and creating resources to help organizations create great User Documents. 

Visit: for resources to help you create the User Documents that your Product needs and your Users deserve.

Visit for more articles like this one.

You may copy and distribute this article freely.  However you must keep the entire article and Resources sections intact, with no changes, additions, or deletions.

Copyright 2007, Igetitnow! Training, Inc.