Cet outil vous fournit une traduction automatisée en français.
Great Technical Writing: Improve Your Readers' Access With A Visual Index
OVERVIEW
People are visual creatures. They look at your product, and see, for example, a button or display. They want to find out about that control or indicator. A Visual Index is a simple but powerful document access tool that enables your Readers to find the information that they want.
This article describes the Visual Index concept and tells how to create one for your document.
A VISUAL INDEX
A Visual Index is a picture of your product or process with links to the relevant information in the related document. Using a Visual Index, your Readers can look at the picture, and quickly jump to the place in your document that describes the item of interest.
Your document may include several Visual Indexes (the plural of "index' is "indexes" not "indices").
STARTS WITH A PICTURE
The Visual Index starts with a picture of your product or process. There are various kinds of pictures to use, based on the product type:
* Physical Product (for example, a barbecue or video disk recorder)
Pictures of the product (all relevant views).
* A Procedure or Process: A flowchart of the steps and decisions in the procedure or process.
* Software Product 1: Screenshots of the software.
* Software Product 2: Before and after images of the work that the product does.
* Organization: An organization chart.
LABEL THE PICTURE
Label all the User-Product Interaction Points (U-PIP) on the picture. A U-PIP is anywhere that your User and the product may interact. U-PIP's include controls, displays, and relevant physical features of the product (such as handles, latches, etc.). Provide a meaningful (to your Reader) label (name) for the U-PIP. (Use that same exact label everywhere you refer to that U-PIP.)
Aside: If your product uses sounds to inform the User, then include a table of those sounds, what they mean, and a link into the relevant area of your document (describing the sound).
LINK THE U-PIP's TO YOUR DOCUMENT
Up to this point, the Visual Index is just like any well-labeled picture of your product or process. However, when you add links into your document, the well-labeled picture becomes a Visual Index.
The link should be to a section of your document that you believe your reader would most want to reach to get the information about that U-PIP. (This is a fundamental question whenever you create an index: "does my reader want to come to this place in my document for this item?")
Your method of adding links to the picture depends upon the publishing mechanism for the document. If the document is published as:
* A Printed document, then use page numbers for the links;
* An Electronic Document, then use hyperlinks that a Reader can click on to follow. If the document is published as HTML, then the visual index can be an image map.
EXAMPLE 1: A PAIN IN MY FOOT
I have a pain in my foot when I walk. If I go to a website about feet, it would be very efficient for finding out about my pain, if I could see a picture of a foot with various areas where the pain could be. Links from the foot areas to specific web pages would enable me to find the information about my specific foot pain quickly.
EXAMPLE 2: PHOTO CORRECTING SOFTWARE
Show a picture with the errors that your software can handle, before and after correction. Here the U-PIP's are each of the photo errors.
EXAMPLE 3: A COURSE ON WRITING USER DOCUMENTATION
The Visual Index is a flowchart for creating the User Document. Since the Course is presented in HTML, the Visual Index is made from an image map, with hyperlinks into the sections of the Course relevant to each item in the flowchart.
BOTTOM LINE
A Visual Index is a simple concept. But like many simple concepts it is very powerful. Try to include one in your next document. You'll be doing your Reader a great service.
BONUS : Great Technical Writing: Make Your Product Fit
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.