OVERVIEW In your User Documentation, you direct your Reader to perform tasks with your product. Unless you tell your Reader things to expect when performing those tasks, you’ll have a baffled Reader, causing dissatisfaction and expensive calls to tech support team. EXAMPLE: reverse osmosis water filtration WATER FILTER I purchased and installed a reverse osmosis water filtration water filter. The instructions explained to fill, after which empty (the instructions foolishly used the word “dump, ” which will have caused the destruction of the system) the tank. The filter had a capacity around 100 gallons per day. Thus I expected the first fill (4. 5 gallon tank) to take less than 1 hour. After about one hour the tank was still filling. Worried, I called the tech support team. I was told that it takes about two hours for the tank to fill. One line in the User Documentation could have eliminated that call: “The tank initially takes 2 hours to fill. ” Not knowing things to expect I, and maybe other Users, wasted the time and money to call the tech support team line. EXAMPLE: UPGRADING A ROUTER’S SOFTWARE I had some problems with my Cable/DSL (Internet-Ethernet) router. The interior control panel caused it to be easy to look for and download updates to the internal software. The system explained that it would simply take a couple of minutes to test for updates (good), nonetheless it failed to tell me how long the update would take to perform once I downloaded the file. Maybe not telling the user things to expect in terms of time is a mistake. I started the update and after a couple of minutes of operation (was it working?) I canceled the procedure. I re-started it again, and made a decision to wait longer to see what happened. It took a couple of minutes longer, and successfully completed. It could only have a simple phrase such as “the software update usually takes up to five minutes to complete” to lessen the User’s anxiety. PROGRESS INDICATORS (as displayed in a windowing environment) are often useless. Some rise above 100%, others are logarithmic: they move quickly in the early processing and wait, seemingly at the conclusion, for a long time while processing is completing. Consider making progress indicators connect with the time of operation, maybe not quantity of files. Some progress/activity indicators have nothing to do with this program they’re connected with. I’ve 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 GET IT DONE Telling the user things to expect just isn’t a brand new concept. If you have ever downloaded files, the download site will frequently tell how long the file will need to download, based on your internet connection. EXAMPLE: YOUR PRODUCT’S INDICATORS While most examples of “telling the user things to expect” handles the time needed to complete an action, others could be related to the indicators and performance of the product. I’ve a little smart battery charger which has a red light for each one of the battery positions. Unfortunately, the operation of the lights is impossible to know, and there is no description of how they work. Here’s what happens. When you 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 conclusion of the charging cycle the light may continue again. This really is clearly confusing to the User. The User’s expectation is that after the light is out, the charging is completed. This would create a large amount of User frustration, as Users would try to use “charged” batteries that have been maybe not charged. The developers of the battery charger should explain the operation of the displays. THE UNDERSIDE LINE Tell the Users things to expect while they use your product. Often these details is the quantity of time it will require for an operation to perform. For other products, you might 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 tech support team costs.

Read Full Post »