Information Technology Reference
In-Depth Information
Table 12.2 Stages of user activities
• Establish the goal
• Form the intention to take some action
• Specify the action sequence
• Execute the action
• Perceive the system state
• Interpret the system state
• Evaluate the system state with respect to the goals and intentions
the stages may not always be used, and they may not always be applied in the same
order. The stages are done in a cycle (thus, the last stage, Evaluate, also occurs
before the first stage, Establish the goal). The process does, however, capture the
essential aspects of how users perform tasks, and is therefore useful for analyzing
and guiding the design of systems. The process should be seen as cyclic rather than
a single shot linear sequence of activities. Activities may also overlap, and there
can be feedback loops between activities.
There may be not be a direct correspondence between the user's psychologi-
cally expressed goals and the physical controls and variables that have to be used
to carry out the task to achieve those goals. In many cases the goals and intentions
are highly context dependent, and often opportunistic rather than planned. The
goals and intentions may also be rather vague or ill-defined. Generally the user will
set up some goal that they want to accomplish, and then formulate an intention to
carry out some actions to ensure that the goal is achieved. Goals and intentions are
psychological concepts—they exist in the mind of the user and relate directly to
the user's needs and concerns. In most cases, however, the actions have to be
performed on a physical artifact or system, manipulating some physical mecha-
nisms to produce changes in the physical variables and the state of the system or
environment. The user must, therefore, turn psychological intentions into actions
that can be physically carried out upon the system or environment. The user then
has to look for the effects of those actions, and interpret those effects in terms of
the psychological goals to decide what to do next.
You do not want your users to have to resort to effortful problem solving just to
interpret the effects of any actions. If they do, this usually means that they have not
found the interface easy to use. This situation should normally only occur when
something goes wrong with the system, or where the purpose of the interface is to
deliberately force the user to resort to problem solving, such as in a game. Pro-
viding some level of built in redundancy will help users when they have to perform
problem solving. You could provide them with multiple email accounts, for
example, in case one is down, or provide multiple ways to get email, e.g., POP and
webmail; similarly, you could provide multiple ways to print with multiple
printers. These are usefully redundant rather than just duplicates.
When you design systems you should think about how to support users in ways
that help them to achieve their goals, and reduce the need for them to resort to
problem solving. You can provide users with some means to access commands, for
example, using keystrokes, menus, buttons, and so on, as a way of helping them
Search WWH ::
Custom Search