General description
When we write user documents, we rely on the experience of our reader / user to simplify our work. This can cause problems for the Reader. This article will discuss the effects of the reader’s experience and how to minimize the negative effects of the incompatible experience, and how to handle the writer’s assumptions about the reader.
Writer Benefits: Trust the Reader’s Experience
When we write, we rely on the experience of our reader to give us a “starting point” for our user document. We often make hidden assumptions about our reader’s experience.
Here are some examples where relying on our reader’s experience makes things easier for us (and causes us problems) as writers:
Example: using a computer mouse
When writing user documentation for graphical user interface-based computer products (such as the Windows or Mac user interface), we assume that the reader knows how to use a mouse to click items, drag, and so on. This saves a lot of background writing.
Example: cooking: how to measure ingredients; Terms
Cookbooks save space (usually correctly) by 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 like AM and PM to simplify our lives as writers. However, many readers use a 24 hour clock and therefore AM and PM do not make sense to them.
Be wary of acronyms you assume your reader knows. It is best to define acronyms inline (perhaps in parentheses) when they are first presented in that part of the user document.
you guys can not define them only the first time they appear in the user document. This incorrectly assumes that users read your user document from start to finish.
Issues Writers Cause Assuming User Experience
Our assumptions as writers can get us into trouble.
Example: unknown words
Here’s an example from gardening: Acme (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 armpit of a leaf” to define another term. “Axil of a leaf” does not appear in the book’s index and there is no glossary in the book. Clearly, this book assumes that the reader understands the term “the armpit of a leaf.” I do not and therefore I am not satisfied 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 (undeclared) assumption from a training company rendered one of their courses unusable.
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 machines in the course was a UNIX editor known as vi.
Unfortunately, the students were not told to use the vi editor. The course presenters fictional that the students knew I saw. The students did not, and spent half of the course time trying to learn and deal with vi.
The hidden assumption of the training company resulted in a failed learning experience (students never needed to use vi again). He missed two days of the four-day course.
Do not present assumptions in a sneaky way
If the training company had said “we train on UNIX systems”, then they leave an outlet when they disappoint students who don’t know the vi editor. In the face of confrontation, the company might respond: “We told you it was a UNIX system. You should know that I saw is the editor available on that system.”
This crafty statement of the assumption is nonsense. It will lead to a lose-lose situation.
The bottom line
As writers, we must make assumptions about our reader’s experience. However, if you make assumptions, be sure to tell the reader what you make about him / her.
Think about the assumptions you make about your Reader. Are these assumptions valid (that is, can you really expect your readers to follow through with your assumptions)? If in doubt, include information that explains the terms and procedures you assume.
Make sure that when you state assumptions, you present them in a way that the reader (student) can understand what the assumption is means for them. Don’t be sneaky about making assumptions.
User experience can cause problems for writers
Your reader’s experience can cause confusion. Here are some examples:
Example: shampoo / conditioner product
One of my favorite examples is a hair conditioner and shampoo combination product. If a user has experience with the separate products, then their experience is for:
* Shampoo: Wet hair. Massage the hair with shampoo and then rinse it off.
* Conditioner: Wash hair. Massage the conditioner into damp hair, leave it on for two to three minutes, then rinse.
The problem arises with the combined product. Should the User leave the product on the hair for two or three minutes (as with the conditioner), or rinse it off immediately (as with the shampoo)?
The user document (product label) of a combination shampoo-conditioner must instruct the user how to use the two-in-one product. Most of such labels do not.
Example: words used in unexpected ways
Your writing can set the reader’s expectations, leading to confusion when words are used in unexpected ways.
An article in the Technology Section (from a newspaper dated June 10, 2004, page B14) described, “How the little one can back up computer data.” The article was about computers. When I got to the phrase: “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 in which the computer starts up (“lifts itself up by its bootstraps” … by a program originally called the “bootstrap loader”). Does the author’s quote about “trouble to boot” mean that if I do backups, my computer will be slower (“boring”) and will require more work on my part to start up (“trouble to boot”)?
The use of the phrase “start” is inappropriate in this article, since “start” has multiple meanings. The author used it as slang for “in addition to”. Since the article was about computers, I thought about the meaning of “boot” computer. The sentence would be less confusing if the author omitted “to boot”, such as: “Let’s face it: backups are boring and annoying.” We will return to this example shortly.
Example: Functional fixation
The function of an object is fixed in the mind of a person. For example, the function of a hammer is to hit things. Experiments have shown that people have a hard time using a hammer for an unusual function, such as a paperweight, prop, or crowbar. This is called functional fixation.
Functional fixation can limit the usefulness of your product. Your user document should try to overcome the functional fixation. Perhaps this example shows how critical I am of user docs.
I have a global positioning satellite (GPS) wrist device that keeps track of my long walks. Thick sweaters and coats, necessary for walking in winter, make it difficult to wear the GPS device on the wrist. But it is a DOLL device. Functional fixation emerges, making me struggle to use the GPS on my wrist. But it turns out that GPS works fine when used in a pocket.
The GPS user document should mention this (obvious?) Capability, thus reducing the functional fixation associated with the GPS WRIST. In my defense: I’m not sure putting the wrist GPS in a pocket is more obvious than using a hammer as a paperweight.
Example: Humor
Humor is related to:
. a subtle knowledge of the language (for example, a play on words)
. or knowledge of an event (perhaps a current event or an entertainment event)
on which humor is based. Here’s an example of an old joke:
“You are so funny, you should be on a stage. There is one that leaves in 15 minutes.”
This joke is based on the reader knowing the two meanings of “stage”: (1) a place to perform and (2) transportation used in the western United States in the 19th century. The second meaning may not be known to most readers, making 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 a form of popular talk or humor. It confused the reader.
Remove humor from your user document
. Humor will only confuse users who don’t understand it.
. Humor is difficult, if not impossible, to translate into other languages.
I suggest that you use an informal and conversational writing style, but without attempts at humor. Eliminate attempts at humor when reviewing and editing your writing.
If you want to write humor, do it elsewhere (you should be on stage). User docs are not a place to practice your humor.
The bottom line
Assumptions
Be careful what you assume about your reader. When in doubt as to whether a reader knows something or not:
. State your assumptions about your reader
State the assumptions in a way that the reader can relate to
. In case of doubt, add the information what do you assume, or
. Tell your reader where to find the information assumed
By providing or flagging this supposed information, you increase your audience
Readers experience
Consider how your reader’s experience influences the way they interpret your user document or use your product. If necessary, add material to your user document to counteract the incompatible experience of your reader.