Essay Online

OVERVIEW

Most product documentation sounds like their product is the only thing in the User’s life. Such thinking results in User confusion and dissatisfaction. This article presents three real-life examples of this attitude, and what should be done to remedy these unfortunate situations. The article concludes with some techniques for the writer.

BACKGROUND

There are two important facts that User Documentation ignores:

1. Your product is a only minor item in your User’s life

2. Your User Documentation must help fit your product into the User’s life

User Documentation that is written with awareness of these facts results in a better user experience. Here are three examples of where the writers (always incorrectly) thought that their product was the only thing in the User’s life.

EXAMPLE 1: Shoe Cleaner/Protector

Most people know about polishing and perhaps cleaning their leather shoes. This cleaner/protector product is meant to clean, protect and shine shoes. The instructions simply tell the User how to apply the product.

What the User is Used to: I polish my shoes with regular wax (or liquid) shoe polish.

The Problem: If a User wants to polish his/her shoes as well as use your cleaner/protector, then what order should the polish and the cleaner/protector be used? The instructions merely tell the User how to apply the cleaner/protector. It’s like the cleaner/protector is the only shoe product in existence.

Possible Solutions: The the cleaner/protector instructions could say (as appropriate):

* Use the cleaner/protector instead of your normal shoe polish.

* Use the cleaner/protector after you polish the shoes with your regular shoe polish.

* For a deluxe shoe treatment, use the cleaner/protector first on the shoes. Wait a few minutes, then wipe off any excess with a clean cloth. Then polish the shoes using your regular shoe polish, in the usual way. Finally, use the cleaner/protector again, but do not wipe it off.

These would make for much more effective instructions, and they could easily fit on the package.

EXAMPLE 2: DVD Player didn’t realize that I had a VCR

People buying a DVD player a few years ago were in the following situation. They had a VCR connected to the single video input of their TV. DVD players’ instructions described how to connect the player to a TV using a video input. The instructions ignored the situation of how to connect the player if there already was a VCR connected to the TV ’s only video input.

What the User is Used to: The VCR is connected to the only video input of my old television.

The Problem: My new DVD player needs to be connected to the TV’s only video input. Do I have to buy a switch or manually switch the DVD player and VCR?

Solution: The writer should provide some tips or instructions how to set up the DVD player in the customer’s real-life situation. These instructions may include how to connect the DVD video through the VCR. Or connecting the DVD to the TV’s video input, and connecting the antenna of the VCR to the antenna input of the TV. Both devices can be connected with no need to buy additional parts. The instructions should mention how. It would improve the User’s experience in setting up the new device. (The instructions should also mention that these methods of connecting the devices would yield a less than optimal picture.)

EXAMPLE 3: A 2 in 1 Shampoo and Conditioner Product

A User normally shampoos his/her hair and then may use a separate conditioner product. He/she just purchased your product, a 2 in 1 shampoo and conditioner. It has no instructions.

What the User is Used to: A shampoo is used on the hair and immediately rinsed. A conditioner gets left in the hair for a few minutes, then rinsed.

The Problem: Does this 2 in 1 product get left in the hair, or does it get rinsed out immediately?

The Solution: Provide correct instructions on the package. Or, if it does not matter how long the 2 in 1 product gets left in the hair, then say so. Don’t leave the User guessing. If the User wanted to guess about something, then they would be reading a novel, not your User Documentation.

BOTTOM LINE: What to Do for Your Documentation

Examine your product in the light of how it will change the way that the User currently does things. How will it fit into the User’s life? How does the product fit with other products your User employs?

Make sure that your User Documentation helps the User to effectively fit the product into his/her life. By ignoring the reality of your User’s situation, you are forcing him/her to solve problems that you could easily solve. If you provide the solutions, then you will create a better product experience for your User.

Fitting the product into the User’s life presents the writer with a duty and an opportunity:

* The duty to ease the User from what he/she previously did to the new product’s situation

* The opportunity to explain your product by using the User’s experience as a background.

OVERVIEW

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.

EXAMPLE: REVERSE OSMOSIS WATER FILTER

I bought and installed a Reverse Osmosis water filter. The instructions told me to fill, and then empty (the instructions foolishly used the term “dump,” which would have caused the destruction of the system) the tank.

The filter had a capacity of about 100 gallons per day. Thus I expected the initial fill (4.5 gallon tank) to take less than one hour. After about an hour the tank was still filling. Worried, I called the technical support. I was told that it takes about two hours for the tank to fill.

One line in the User Documentation would have eliminated that call: “The tank initially takes 2 hours to fill.” Not knowing what to expect I, and perhaps other Users, wasted the time and money to call the technical support line.

EXAMPLE: UPGRADING A ROUTER’S SOFTWARE

I had some problems with my Cable/DSL (Internet-Ethernet) router. The internal control panel made it easy to check for and download updates to the internal software. The system told me that it would take a few minutes to check for updates (good), but it did not tell me how long the update would take to perform once I downloaded the file.

Not telling the User what to expect in terms of time is a mistake. I started the update and after a few minutes of operation (was it working?) I canceled the process. I re-started it again, and decided to wait longer to see what happened. It took a few minutes longer, and successfully completed.

It would only take a simple phrase such as “the software update can take up to five minutes to complete” to reduce the User’s anxiety.

PROGRESS INDICATORS (as displayed in a windowing environment) are often useless. Some go beyond 100%, others are logarithmic: they move quickly in the early processing and wait, seemingly at the end, for a long time while processing is completing. Consider making progress indicators relate to the time of operation, not number of files.

Some progress/activity indicators have nothing to do with the program they are associated with. I have used virus checkers that have abnormally terminated, yet the activity indicator kept on moving. Make sure that progress/activity indicators do reflect activity of the associated program.

FILE DOWNLOADS DO IT

Telling the User what to expect is not a new concept. If you have ever downloaded files, the download site will often tell how long the file will take to download, based upon your Internet connection.

EXAMPLE: YOUR PRODUCT’S INDICATORS

While most examples of “telling the User what to expect” deals with the time needed to complete an activity, others can be related to the indicators and performance of the product.

I have a small smart battery charger that has a red light for each of the battery positions. Unfortunately, the operation of these lights is impossible to understand, and there is no description of how they work.

Here’s what happens. When you first insert the battery, the light illuminates. A short while later (the charging still has many hours to go), the light goes off. Sometime toward the end of the charging cycle the light may go on again.

This is clearly confusing to the User. The User’s expectation is that when the light goes out, the charging is completed. This would result in a lot of User frustration, as Users would try to use “charged” batteries that were not charged. The developers of the battery charger should explain the operation of these displays.

THE BOTTOM LINE

Tell the Users what to expect as they use your product. Often this information is the amount of time it will take for an operation to complete. For other products, you may have to tell the User what the indicators mean.

Don’t leave your document Readers confused or left to figure things out on their own. Doing so will reduce your Users’ comfort with your product, and increase your technical support costs.