Great Technical Writing The Two Edged Sword Of Reader Experience

Great Technical Writing: The Two-edged Sword Of Reader Experience

Overview

When we write User Documents we rely on our Reader's/User's experience to simplify our work. This can cause problems for the Reader. This article will discuss the effects of Reader experience and how to minimize the negative effects of incompatible experience, and how to handle the writer's assumptions about the Reader.

Writer's Benefits: Relying on Reader Experience

When we write, we rely on our Reader's experience to give us a "starting point" for our User Document. Often we make hidden assumptions about our Reader's experience.

Here are some examples where relying on our Reader's experience makes things easy (and causes problems) for us as writers:

Example: Using a Computer's Mouse

In writing User Documentation for Graphical User Interface-based computer products (such as the Windows or Mac User interface), we assume that the the Reader knows how to use a mouse to click on items, drag, etc. This saves much background writing.

Example: Cooking: How to Measure Ingredients; Terms

Cook books save space by (usually correctly) assuming that a Reader can perform basic cooking operations (such as measuring ingredients), and terms (such as puree or slice).

Example: Common Acronyms

We rely on "common" acronyms such as AM and PM to simplify our writing lives. However, many Readers use a 24 hour clock, and thus AM and PM are meaningless to them.

Beware of any acronyms that you assume that your Reader knows. It is best to define acronyms in line (perhaps in parentheses) when they are first presented in that part of the User Document.

You cannot define them only the first time they appear in the User Document. This assumes -- incorrectly -- that Users read your User Document from start to finish.

Problems Writers Cause When Assuming User Experience

Our assumptions as writers can get us into trouble.

Example: Unfamiliar Words

Here's a gardening example: Acme's (a fictitious company) Illustrated Guide to Gardening in Canada (1979) makes an incorrect assumption about its Readers:

In one of their definitions they use a term, "the axil of a leaf" to define another term. "Axil of a leaf" is not listed in the book’s index, and there is no glossary in the book. Clearly this book assumes that the Reader understands the term "the axil of a leaf." I don’t, and am therefore unhappy with the presentation.

Solution: Provide a glossary of gardening terms or a reference to a page in the book where the term is defined.

Example: Assuming Students' Experience

Here is an example where an (unstated) assumption by a training company rendered one of their courses useless.

In order to do the exercises in a computer programming course, students had to be able to use an editor (a simple word processor) to program the system. The only editor available on the course machines was a UNIX editor known as vi.

Unfortunately, the students were not told that they needed to use the vi editor. The course presenters assumed that the students knew vi. The students did not, and they spent half the course time trying to learn and deal with vi.

The hidden assumption by the training company resulted in a failed learning experience (the students never needed to use vi again). It wasted two days of the four-day course time.

Don't Present Assumptions in a Sneaky Way

If the training company had said that, "We train on UNIX systems," then they leave a way out for themselves when they disappoint students who do not know the vi editor. When confronted, the company could respond with, "We told you it was a UNIX system. You should know that vi is the editor available on that system."

This sneaky statement of the assumption is foolish. It will result in a lose-lose situation.

The Bottom Line

As writers, we to make assumptions about our Reader's experience. However, if you make assumptions, then make sure that you tell the Reader what you assume about him/her.

Think about the assumptions that you make about your Reader. Are these assumptions valid (that is, can you really expect your Readers to meet your assumptions)? If there is any doubt in your mind, include information explaining the terms and procedures that you assume.

Make sure that when you state assumptions, that you present them in a way that the Reader (student) can understand what the assumption means to them. Don't be sneaky about presenting the assumptions.

User Experience Can Cause Trouble for Writers

Your Reader's experience can cause confusion. Here are some examples:

Example: Shampoo/Conditioner Product

One of my favorite examples is a combined hair shampoo and conditioner product. If a User has experience with the separate products, then their experience is to:

* Shampoo: Wet thenhair. Massage shampoo into the hair, then rinse it out.
* Conditioner: Wash the hair. Massage conditioner into the wet hair, leave in the hair for two or three minutes, then rinse it out.

The problem arises with the combined product. Should the User leave the product in the hair for two or three minutes (as done with the conditioner), or rinse it immediately (as done with the shampoo)?

The User Document (product label) for a combined shampoo-conditioner should tell the User how to use the two-in-one product. Most such labels do not.

Example: Words Used in Unexpected Ways

Your writing can set the expectations of the Reader, resulting in confusion when words are used unexpectedly.

An article in the Technology Section (of a newspaper on June 10, 2004, page B14) described, "How the little guy can back up computer data". The article was about computers. When I came to the sentence: "Let's face it: backups are boring and a hassle to boot." I wondered about the phrase "to boot."

In computer jargon, "boot" is the process where the computer starts up ("lifts itself by its bootstraps"...by a program originally called a "bootstrap loader"). Does the author's quote about "hassle to boot" mean that if I do backups, then my computer will be slower ("boring") and require more work from me to start up ("hassle to boot")?

The use of the phrase "to boot" is inappropriate in this article, given that "to boot" has multiple meanings. The author used it as slang for "in addition to." Since the article was about computers, I thought of the computer meaning of "to boot." The sentence would be less confusing if the author left out "to boot," as: "Let's face it: backups are boring and a hassle." We'll return to this example shortly.

Example: Functional Fixedness

An object's function is fixed in a person's mind. For example, a hammer's function is to pound things. Experiments have demonstrated that people have a hard time using a hammer for an unusual function, such as a paperweight, a prop, or a lever. This is called functional fixedness.

Functional fixedness can limit the usefulness of your product. Your User Document should attempt to overcome functional fixedness. Perhaps this example will show how critical I am of User Documents.

I have a wrist global positioning satellite (GPS) device that keeps track of my long walks. Sweaters and heavy coats, needed for walking in the winter, make it difficult to wear the GPS device on the wrist. But it is a WRIST device. Functional fixedness arises, causing me struggle to use the GPS on my wrist. But it turns out that the GPS works well when used in a pocket.

The GPS User Document should mention this (obvious?) capability, thus reducing the functional fixedness associated with the WRIST GPS. In my defense: I am not sure that putting the wrist GPS in a pocket is more obvious than using a hammer as a paperweight.

Example: Humor

Humor relies on:

. a subtle knowledge of the language (for example a pun)
. or a knowledge of an event (perhaps a current event or entertainment event)

on which the humor is based. Here's an example, from an old joke:

"You're so funny, you should be on a stage. There's one leaving in 15 minutes."

This joke relies on the Reader's knowing the two meanings of "stage": (1) a place for performing, and (2) transportation used in the western United States in the 1800's. Most Readers might not know the second meaning, rendering the humor a confusing waste of words.

Earlier we examined the sentence: "Let's face it: backups are boring and a hassle to boot." The author used the phrase "to boot" as some form of folksy talk or humor. It confused the Reader.

Eliminate Humor from Your User Document

. Humor will only confuse Users who do not understand it.
. Humor is difficult, if not impossible, to translate into other languages.

I suggest that you use a writing style that is informal and conversational, but with no attempts at humor. Remove attempts at humor when you review and revise your writing.

If you want to write humor, do it elsewhere (you should be on a stage). User Documents are no place to practice your humor.

The Bottom Line

Assumptions

Be careful about what you assume about your Reader. When in doubt whether or not a Reader knows something:

. State your assumptions about your Reader
State the assumptions in a way that the Reader can relate to
. When in doubt, add the information that you assume, or
. Tell your Reader where to find the assumed information
By providing or pointing to this assumed information, you increase your audience

Readers' Experience

Be aware of how your Reader's experience influences how he/she interprets your User Document or uses your product. If necessary add material to your User Document to counter your Reader's incompatible experience.

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

THE USER-PRODUCT LIFE CYCLE (U-PLC)

Usually, when we think of a Product Life Cycle, we think in terms of the development and production of the Product itself. When writing User Documentation, consider the U-PLC to help you generate all the topics necessary for a complete document. User Documentation should support your Users in all of their interactions with the product.

The User-Product Life Cycle refers to the full range of interactions between the User and the Product itself. This is more than simply "how to use the product." As you will see below, "Use the Product" is only one stage in the U-PLC.

STAGES IN THE U-PLC

Here are the stages IN the U-PLC (assuming that the User as acquired the Product):

-- U-P LC Stage: Transport the Product to its working location

-- U-P LC Stage: Unpack the Product

Transport and Unpacking of the product are listed here just for completeness. These are currently displayed on the packaging itself, usually in pictorial form, and do a good job.

-- U-P LC Stage: Overall knowledge about the Product.

This is information that is presented to the User early in the User Documents.

Topics here include safety, legal, and disclaimers related to the product.

The description of the product should indicate how the product may change the way that the User currently does things. For example, an analog voice recorder will require the User to listen to all the stored items to find a particular one; a digital voice recorder will enable the User to quickly jump from one message to another.

-- U-P LC Stage: Set up or Install the Product

* Environments

It is important for the writer to think of the various environments where the product will exist. For example, how should a computer program be installed in a Windows, Mac, or Linux environment?

"Environments" includes other things that the product must work with. For example, how should a DVD player be installed in a system currently composed of a TV and a VCR? How about installation to a TV & VCR system where the TV has only one video input?

* User Capabilities.

The capabilities required for the User to set up the product are also important. Since the assumptions related to the User for set up may be different from the assumptions about the User in using the product, the wise writer will present the skills (and perhaps regulations) needed to set up the product. A section entitled "Can You Set Up This Product?" will enable the User to make the decision about whether to set the product up themselves, or find outside help.

For example, suppose the product is an electrical light dimmer that is intended to replace the light switch in the User's home. Using the product merely requires adjusting the dimmer's single control to set the desired light level. Installing the product requires experience with home electrical wiring--does the User have these capabilities?

Sometimes, the limitation may be legal. In some jurisdictions -- Quebec, Canada, for example -- only qualified electricians are permitted to install or modify electrical circuits in the home. Thus in Quebec, the general User of the dimmer will not be able to (legally) install the light dimmer.

-- U-P LC Stage: Use the Product

This component is the focus of most User Documentation. It should contain at least these three sub-topics:

- Starting the product

- Actual Use of the product

For most products "Actual Use" is the central focus of the User Document.

Ideally, this should be divided into basic or common product functions, and advanced functions. A good example is photo-editing software. Most Users want to crop, rotate, and adjust the brightness and contrast of the image. These are basic functions. More advanced functions might be combining the parts of one picture with another.

- Shutting down the product

Is there any maintenance to be done at shut down? List it here and in the "Maintain" section.

-- U-P LC Stage: Maintain the Product

Consider breaking this down into time periods, such as: after each use, weekly, monthly, yearly, as applicable.

-- U-P LC Stage: Move the Product

For a computer software program, how the User should move the program and its data to another computer; computer users often upgrade their computer hardware. While it is often assumed that the User should re-install the product on the new computer, there always is the question about moving the data related to the product: where is it located, and how should it be moved so the newly-installed program can recognize it on the new computer?

For a physical product, are there any special considerations in moving the Product to another location?

-- U-P LC Stage: Discard the Product or its By-Products

Here I would like to mention only selling the used product. It might be wise to mention that by keeping the User Manual, the seller may find it easier to sell, and possibly get a higher price, for the used product.

USING THE U-PLC IN YOUR WRITING

As you generate the topics for your User Document make sure that you keep the U-PLC in mind. Ensure that you include topics in your User Document Outline to assist your User in all phases of the U-PLC.

Great User Documents can assist in the UP-LC section that I did not present here: acquisition of the product. Your marketing department may be able to use your GREAT User Document as part of its marketing campaign.