Instructions should be written from the user’s point of
view, this is to create an understanding of how the information relates to the
installer. This is possible if the information is written in second person with
” Subsequent installation of the HIGS feature allows
InfoProduct to run unattended”
This instruction is unclear about who does the action, the
reader can’t tell how or if the information refers to them.
” If you want to run InfoProduct unattended, you must
install the HIGS feature. You can install the HIGS feature after you install
This instruction does not leave the reader out of the story,
it explains what is required from the installer to run InfoProduct unattended.
Figure 1 (Carey et al. 2014), Confusing information.
To present information from the user’s point of view it is
important to leave out confusing descriptions of previous steps that were
carried out by someone else with different skills.
As in figure 1, it is pointless to recommend the end user of an energy
optimizer meter to check if the installation was done correctly. It is the
company technicians who do the installations since end users are usually not
qualified to do so (Carey et
Figure 2 (Carey et al. 2014), revised instruction.
This revised instruction in figure 2 is much more relevant
to the user’s point of view.
It is recommended to use the product to get a better idea of
the user’s perspective. Thus, would clarify where it would help to present
explaining examples or actions that are required from the users in case of
Focus on user’s goals.
The best way to make sure that the user’s get what they want
when reading an instruction manual is to write it based on their goals. A goal
is not the same thing as a goal even though tasks are usually required achieve
a goal. Although user’s can probably do many tasks with a product it is
important to focus on the tasks that support the user’s goals. Information that
is focused on user’s goals is about what user’s want to do, while information
that is based on features is about what the product can do. Not all user’s need
documentation on every feature since many products have features or
instructions that a small number of users ever use.
One way to identify the tasks that are required to achieve a
user goal is to start at a high level. For instance, when if goal is to
refurbish an old car one of the high-level tasks could be; polish and paint the
body. The high-level task can later be divided into lower level tasks that
explain how to do the polishing and painting in detail. (Carey et al. 2014). This is similar to the
process of doing a Work breakdown structure when planning a project.
Another way to make sure that the instructions are focused
on the user-goals is to base the information on scenarios that lead to the
goals. Scenarios present a story of how to solve a problem in real life
circumstances. Instead of using a scenario to explain one topic/task, use a
scenario as the basis of every task that is required to reach the goal. This
reminds of a book called “The Goal: a
process of ongoing improvement” which was written by Eliyahu M. Goldratt.
What made the book so interesting to read is that it was written in the form of
a novel even though the main purpose was to teach techniques on how to improve
a process logistically.
Another thing that is of relevance when writing user-goals
instructions is to write user-oriented task topics instead of functions task
topics. User-oriented tasks are tasks that users want to perform regardless if
it’s with help of the delivered product. These tasks are usually the reason why
the customer makes a purchase in the first place.
For instance, “Making ice cream” is a more
comprehensive task topic than “Using the Clatronic ICM 3581”. The first
task topic is considered a user-oriented task topic while the latter is a
Indicate a practical reason for information
Writing user-oriented instructions should when needed be
complemented with information on why they are required to the tasks and
how it is relevant for their goal. Sometimes users need a practical reason for
why they should perform a task. For example, if a task states that the user
should drain the hose before disconnecting it from the tap the user might think
that it is not that crucial since it can be drained after its disconnected.
However, if the task states that it will be much easier to disconnect the hose
after it is drained because of reduced water-pressure inside the hose, then it
would be much easier to understand why the tasks should be carried out in the
Provide clear, step-by-step instructions.
Tasks should be written at the appropriate level of the
audience to be acted upon. The risk of user’s deviating from the instructions
rises if they are too difficult to understand or too obvious. Each step should
state a clear imperative action for the user to take, preferably in the first
sentence. The purpose of the task should be described when it is needed to make
it easier for the user to relate. If the instruction includes optional steps
for features within the product that are not required to reach the user’s goal
they should be clearly marked. Conditional steps should clearly state the
condition at the beginning of the step. That way, users who don’t fulfil the
condition can skip reading the whole task (Carey et al. 2014).
The checklist in figure 3 can be used to evaluate if the instructions