June 11, 2014
How Do We Know Which User Tasks to Write in Manuals?
Many technical communicators have learned that an end user manual should consist mainly of tasks. That is, instructions detailing each step that users are recommended to follow. And indeed, a user must complete many tasks do get a product to work.
But how do we know which tasks to write about in end user manuals? Are you like me, a technical communicator who finds it confusing at times to identify what task to write? Then this article, part 6 in the Designing for the Searching User series, is for you.
Since we technical communicators often work in parallel to product development, we must predict "How do I [task] [result]?" questions as part of developing user assistance. In order to know which "How do I [task] [result]?" questions users ask, we must first model the possibilities that the product offers. Sound complicated? Let me explain.
In The Beginning, It Seemed Easy to Identify Tasks to Write
As a fresh technical communicator some 20 years ago, it seemed easy to figure out which tasks to write when documenting a technical product. I learned that I had to scrutinize the product user interface in order to identify various use cases that the user must master, such as opening a print dialog or defining user groups; each characterized with a persona, where I had to observe representative users in action and make a list of the steps taken in performing a task.
But as I started to think about how users actually behave when using a product, that is, searching for answers, I realized that the product user interface (or a list of features and functions), or developing user groups, was the wrong starting point for identifying which tasks to write. Developing user groups may lead you astray as you may end up writing organizational centric tasks, (see discussion here).
It also became apparent that I disagreed with the way a user is portrayed in main stream technical communication. To me, the main stream view portrays the user as a passive creature who lacks appropriate knowledge.
According to this view, you, as the technical communicator, must develop a list of the things the user needs to know in order to fulfill a specific purpose. The manual implicitly states, "This is the knowledge you must have in order to use the product safely and effectively". If we could, we would force the user to read the manual to increase their knowledge. Sad to say, but this view hasn’t seemed to have loosened its grip.
To Design for the Searching User, We Must Think Differently
Minimalism got us to think differently. The minimalist perspective, which I favor, views the user as an active and sense-making individual. They believe in something. They act based on what they believe in.
According to minimalism, users learn a product by discovering it; by performing real tasks. Minimalist instruction is all about supporting effective discovery learning.
But I believe we must think even more differently. Users go to user assistance to find an answer to a set of questions, not primarily for the purpose of gaining support in their product discovery. (Find a more detailed discussion here).
Thus, we know the tasks to write about by understanding when and why users ask a "How to I [task] [result]?" question. But the tricky part is that we must predict all these questions, since technical communicators often work in product development projects.
To understand when and why a user asks a task oriented question, we must start by understanding why someone would want to use a product.
Why Does Someone Want to Use a Product?
Or, why does an individual perform various tasks with a given product? They do it because they know that the product has the potential to deliver a result which is meaningful for them, one which they hope will satisfy a specific need.
Individuals within an organization, for instance, are pressed by the need to constantly optimize, automate, secure, and create something. They may be impelled by global competition, or are required to do so by law. They set up goals, and act to satisfy these needs.
They may decide to use a product as a means for reaching these goals. A user knows that a product offers possibilities to optimize, automate, secure or minimize something in a business or on leisure time. Thus, a user engages the product in order to achieve what is possible, with the intention to get a meaningful result, and in turn reach their goals.
A user must perform various tasks with the product in order to produce the meaningful result. For example, a project leader using a spreadsheet software to calculate budget overrun.
How Does a "How do I [task] [result]?" Question Arise?
How do you open a wine bottle using an elaborate corkscrew?
Consider the following example. An individual works as a sommelier in a restaurant. Part of their work responsibility is to open wine bottles. It’s cumbersome to manually open each bottle, thus he needs a tool, a product. He knows there’s a product that automatically opens wine bottles. He finds something that looks like an automatic wine opener and recognizes that it has the potential to open wine bottles. He creates a mental model, based on prior experience, of how to go about using it. But he can’t figure it out. When he tries, he fails.
What’s happened here? The user has been impelled to ask their first question: How do I open a wine bottle? The sommelier in this example knew the purpose of the product and that the product has the potential to open wine bottles. Thus, he did not ask such types of questions.
How Do We Predict the "How do I [task] [result]?" Questions?
To summarize: If a user lacks knowledge on how to do to reach a result they know is possible, they may get stuck and ask "How do I [task] [result]?". Thus, as technical writers, in order to predict these "How do I [task] [result]?" questions, we must first identify the possibilities a user "knows" a given product offers. After all, a sommelier would not ask "How do I open a wine bottle?" if he were unaware of the possibility.
Here, we run into a problem. It’s impossible to know what a user thinks is possible. A user may very well believe that a product has a possibility which it doesn’t in fact have. Or the user may believe that the product can be used for something that is indeed possible, which wasn’t what the manufacturer actually intended.
So in order to predict "How do I [task] [result]?" questions, we must limit ourselves to the context of a user who we assume understands the possibilities a given product has. When we know these possibilities, we can derive the tasks.
The following example illustrates how a user learns about the possibilities. A user who knows that a product is generally suitable for meeting their need may wish to know about each and every possibility the product represents to evaluate its suitability (as I have outlined in part 5 of this series). The user approaches a sales person and asks "What is possible? Tell me about every possibility.” The sales person presents each possibility, and the user learns them all. Now this user is knowledgeable about the "valid" possibilities that exist. But still, he lacks knowledge of how to make the product achieve these possibilities.
Now, each possibility equals a variable value according to the approach to predict user questions, as outlined in part 4 of this series. If we assume that users know "it is possible to open a wine bottle,” we predict that some users will ask "How do I open a wine bottle?" which gives us the task to write about.
Now, there are mandatory tasks a user must perform before the product is functional and prepared to achieve a possibility. A radio clock, for example, has the possibility to issue an alarm for the purpose of waking someone up. Before this possibility can become reality, the user must install the radio clock, set the current time and the wake up time. But awareness of the possibilities is the starting point to identifying these mandatory tasks.
So, How Do We Know Which User Tasks to Write in Manuals?
To know the task to write, we need to start by identifying the possibilities a product is designed to offer as answers to a user asking "What is possible?" or "Is it possible to [task] [result]?". In the Excosoft CMS for example, it is possible to set conditions and insert variables, as Joakim Ström describes in Managing Variation in Reused Content with Conditions.
Imagine the automatic wine opener described above. It may be possible to start it by pressing a button on the front panel, or by waving a hand in front of a sensor. It may also be possible to select how much power to use to indicate the speed at which the bottle is to be opened. Identifing all these possibilities is vital before beginning to write a task topic.
In this case, you would need to write the answers to three questions: "How do I open a wine bottle from the front panel?", "How do I open a wine bottle by waving my hand?”, and "How do I indicate how much power to use?" Or, would you write one (1) task topic covering all possibilities?
But to identify possibilities, can be a challenge. In some software, like Adobe Illustrator, there is an infinite number of possibilities; you can draw almost anything. Exploring how to identify possibilities, or meaningful result statements, as they are called in SeSAM, is a topic for another day.
You might wonder, is it really possible to predict user questions? It is possible, and this is what SeSAM and exFinder are all about – allowing you to design for Findability.
Contact me at firstname.lastname@example.org if you are interested in a webinar about SeSAM and exFinder. And stay tuned for the next article in Designing for the Searching User article series, written by Excosoft information architect Jonatan Lundin.
- Info Tech Trends
- User Experience