HCI 510 : HCI Methods I
• Context of Use
HCI 510: HCI Methods I
• Context of Use
– Users
– Tasks
– Environment
• Task Analysis
– Hierarchical
– Cognitive
– Activity
Context of Use
User centred design requires that the product development team
interacts with the end users from the beginning to the end of the
project.
One of the major obstacles to implementing such an approach is the
problem of defining in advance:
• Who the target users are ?
• What kinds of tasks users will wish to use the product for ?
• What kind of environment will the product be used in ?
Usually, compromises are reached which typically result in a
product that only meets the users’ needs by chance, if at all.
Certainly, if you wish to carry out realistic user testing you should
be able to give comprehensive answers to the above questions.
Context of Use
Context of Use (CoU) analysis is a generic technique that assists
development by posing certain probe questions about the project.
The probe questions elicit from the development team and other
stakeholders in the project information that may be held ‘below the
surface’ by one or more of the constituent groups (usually
unwittingly).
The effect of carrying out CoU analysis is to bring this information
out into the open at an early stage in development, when the
implications can be examined, to produce a user requirements
specification and to drive the formulation of a realistic test plan.
Kirakowski, J. and Cierlik, B., Context of Use: Introductory Notes, Version 2.0, HFRG, Cork, 1999.
Context of Use
There are two major uses for Context of Use analysis:
•
•
As an aid to requirements capture
As an aid to usability evaluation
The first, as an aid to requirements capture, may be carried out very
early in the project – as early as concept definition, for instance.
Later, when some kind of workable prototype is available for
evaluation, CoU is used as a planning aid for selecting which
aspects of the product need evaluation, and what are the most
meaningful circumstances under which evaluation can take place.
This will ensure that usability evaluation, when carried out,
realistically captures important elements of how the product will
actually be used after release.
Context of Use
“Innovation happens when the designers get direct exposure to the users'
entire context and its subtle variations and accidental similarities. Some
of the most innovative designs in the last 5 years are the result of paying
attention to the little details in the user's context.”
Jared M. Spool
Context of Use
When using CoU for requirements capture some CoU information is
much more important than other information, and at this stage, it is
recommended that the number information be used to monitor the
criticality of the design constraints emerging from the analysis of end
user needs.
It is up to the development team to decide on what numbering scheme
to use, but the following is suggested:
1. Critical requirement or feature, should not or cannot be changed, non-negotiable,
2. Important, but may be traded against technical or organisational requirements if necessary,
3. ‘dream machine’ requirement or feature which indicates future scenario expectations,
4. requirement or feature which does not have to be strongly defended and may be
circumvented in practice.
Context of Use - Elements
It will be seen that the three important elements of CoU are sets of
probe questions which deal with the following three issues:
•
WHO will use the software (Users)?
•
WHAT will they do with the software (Tasks)?
•
WHERE will they use the software (Environment)?
Context of Use - Elements
User analysis:
In any complex application, there is likely to be a multiplicity of users: for
instance, in a multi-media application designed for supporting teachers to
help them prepare their lesson materials, there are of course the direct end
users, the teachers themselves. However, there are importantly a group of
users who are directly affected by the use the teachers make of the
application, and these are the pupils.
There are also content providers at the other end of the chain. The pupils
and the content providers are indirect users of the application.
There are also likely to be technical personnel involved in making the
content available in multi-media form and support personnel involved in
maintaining the database from day to day and responding to user queries.
These are support users.
Context of Use - Elements
Task analysis:
There are numerous books written on the subject of the analytic techniques
known together as ‘task analysis’.
For the moment, a task is considered to be any activity which starts from a
known initial state of the human, the computer, or the environment (or all
three), and continues until it reaches a known end state. The activity is
defined in terms of the transformation from the start state to the end state.
At the CoU analysis level one should concentrate on defining a few big
tasks which are the main stream of the activity of using the application.
If one has defined multiple users, one may find that each class of user has
several distinct tasks in which they participate, maybe in conjunction with
other classes of users.
Context of Use - Elements
Environment analysis:
There are several aspects to the environment question: the social, the
organisational, and the technical environment in which the users work.
Sometimes aspects of the environments the users work in display peculiar
characteristics, and these should most certainly be noted, as they may
affect the way the product is developed and will certainly affect the way the
product should be evaluated for a realistic evaluation.
It sometimes happens that a certain category of user may carry out exactly
the same task in two quite different environments (for instance, an
electrician may be called to make adjustments to a circuit board in an office
environment as well as in a moderately dangerous and uncomfortable
underground tunnel.)
Context of Use - Elements
It will be seen that the three important elements of CoU are sets of
probe questions which deal with the following three issues:
•
WHO will use the software (Users)?
•
WHAT will they do with the software (Tasks)?
•
WHERE will they use the software (Environment)?
Context of Use - Users
Defining the User
1. Assign a unique name to this kind of user
2. User category name
Some users may take on more than one role with regard to the system being evaluated. Only
assign them to different user categories if they have to interact between themselves in the
carrying out of two or more of their roles.
3. User Role
Direct user, Indirect user, Supporting user, Monitoring user, Other.
Context of Use - Users
Defining the User
4. User Skills and Knowledge
• Education level
• Qualifications for job
• Training or experience in the business processes
• Linguistic ability
• General computer experience
• Product experience
• Training or experience in product use
• Input Skills
Context of Use - Users
Defining the User
5. User Physical Attributes
• Age
• Gender
• Physical Characteristics
6. User Attitude and Motivation
• Attitude to the job/ task
• Attitude to the product
• Attitude to information technology
• Attitude to employing organisation
• Level of motivation to use system
Context of Use - Users
Defining the User
7. User Job Characteristics
• Job Function (title)
• Job History
• Hours of Work / Operation
• Job Flexibility
• Work Autonomy
Context of Use - Elements
It will be seen that the three important elements of CoU are sets of
probe questions which deal with the following three issues:
•
WHO will use the software (Users)?
•
WHAT will they do with the software (Tasks)?
•
WHERE will they use the software (Environment)?
Context of Use - Tasks
Defining the Task
1. Assign a unique name to this task
2. Task Objective
Explain briefly the usual objective for which the task is carried out (‘why do you do it?’) and
how you recognise that it is achieved (‘how do you know when you’ve finished?’).
3. Task Execution
• Degree of choice in use of system to carry out task
• Criticality of the task output
• Degree of precision required in output
• Autonomy of user in completing task
• Other execution constraints
Context of Use - Tasks
Defining the Task
4. Task Flow
• Task input / starting condition
• Task output / finishing condition
• Task side effects
• Task dependencies
• Linked tasks
• Task Postponement
Context of Use - Tasks
Defining the Task
5. Task Demand on Users
• Task frequency
• Task duration
• Task flexibility / pacing
• Physical & mental demands
• Complexity as perceived by user
6. Task Safety
• Safe to operator
• Safe to secondary users
Context of Use - Environment
It will be seen that the three important elements of CoU are sets of
probe questions which deal with the following three issues:
•
WHO will use the software (Users)?
•
WHAT will they do with the software (Tasks)?
•
WHERE will they use the software (Environment)?
Context of Use - Environment
Defining the Environment
1. Assign a unique name to this environment
2. Social Environment
• Multi / single user environment
• Assistance available (eg help desk)
• Interruptions
Context of Use - Environment
Defining the Environment
3. Organisational Environment
• Policy
• Aims
• Culture
• Procedures
• Mode of communication
• User monitoring in progress
• Feedback on job given
Context of Use - Environment
Defining the Environment
4. Technical Environment
• Standalone / networked
• (Supporting) software required
• Hardware required
• Additional hardware / software resources required
• Type of network connection required
Context of Use - Environment
Defining the Environment
5. Physical Environment
• Standard Office,
• Laboratory or training class,
• Home / Informal,
• Other.
Context of Use - Environment
Defining the Environment
6. Additional Information
• Location
• Auditory Environment
• Thermal Environment
• Visual Environment
• Stability of Environment
• Posture required of user
• Necessary furniture/ resources
• Amount of available space
• Health hazards
• Protective clothing needed
HCI 510: HCI Methods I
• Context of Use
– Users
– Tasks
– Environment
Lets have a go ….
HCI 510: HCI Methods I
You are a design consultant who has been employed by a
shipping company (such as Fedex or UTS) to design a new
handheld device for their couriers.
HCI 510: HCI Methods I
• You are a design consultant who has been employed
by a shipping company (such as Fedex or UTS) to
design a new handheld device for their couriers.
• This mobile, touch screen device will contain all the
information that the couriers need.
• It will tell the couriers where to deliver the parcels,
the order/dates of delivery, GPS tracking and maps
for guidance, a method of recording signatures when
parcels are delivered.
• The first stage is to perform a Context of Use
assessment to capture the requirements.
HCI 510: HCI Methods I
• Context of Use
– Users
– Tasks
– Environment
• Task Analysis
– Hierarchical
– Cognitive
– Activity
Task Analysis - Introduction
Practitioners and researchers routinely advocate building user-centered
systems which enable people to reach their goals, take account of natural
human limitations, and generally are intuitive, efficient and pleasurable to
use (Preece, Rogers and Sharp, 2002).
Central to the design of such systems is a clear understanding of what
users actually want to do:
• What are their tasks?
• What is the nature of those tasks?
Task analysis techniques are particularly important because they enable
rigorous, structured characterizations of user activity. They provide a
framework for the investigation of existing practices to facilitate the design
of complex systems.
Preece, J, Rogers, Y, and Sharp, H. (2002). Interaction Design: beyond human-computer interaction. New York: John Wiley & Sons.
Task Analysis - Introduction
Task analysis is especially valuable in the context of human-computer
interaction (HCI).
User interfaces must be specified at an extremely low level (e.g. in terms of
particular interaction styles and widgets), while still mapping effectively to
users’ high-level tasks.
Computer interfaces are often highly inflexible (when compared to
interacting with a physical environment or another person).
This inflexibility magnifies the impact of interface design problems, making
the close integration of task structure and interface support especially
crucial.
Task Analysis - Introduction
As applied psychologists and system designers dealt with ever-more
complex tasks and supporting systems to increase efficiency and
productivity, they began to search for more rigorous, systematic, and costeffective analytical techniques.
These techniques influenced the emerging interdisciplinary practice of HCI.
Task analysis now includes a range of techniques aimed at obtaining
descriptions of what people do, representing those descriptions, predicting
difficulties, and evaluating systems against functional requirements (Jordan,
1998).
These techniques focus on quite different levels of analysis and contribute
different insights.
Jordan, P. (1998) An Introduction to Usability. London: Taylor & Francis.
Task Analysis - Introduction
Task Analysis - Introduction
Task Analysis - Hierarchical
Hierarchical Task Analysis (HTA) was introduced by Annett and Duncan
(1967) to evaluate an organization’s training needs.
The underlying technique, hierarchical decomposition (Annett, Duncan,
Stammers and Gray, 1971), analyzes and represents the behavioral
aspects of complex tasks such as planning, diagnosis and decision making
(Annett and Stanton, 2001).
HTA breaks tasks into subtasks and operations or actions. These task
components are then graphically represented using a structure chart. HTA
entails identifying tasks, categorizing them, identifying the subtasks, and
checking the overall accuracy of the model.
Annett, J. and Duncan, K. (1967). Task Analysis and Training Design. Occupational Psychology 41, 211-221.
Annett, J., and Stanton, N., eds. (2000). Task analysis. London: Taylor & Francis.
Annett, J., Duncan, K., Stammers, R. and Gray, M. (1971). Task analysis. London: HMSO.
Task Analysis - Hierarchical
HTA is useful for interface designers because it provides a model for task
execution, enabling designers to envision the goals, tasks, subtasks,
operations, and plans essential to users’ activities.
HTA is useful for decomposing complex tasks, but has a narrow view of the
task, and normally is used in conjunction with other methods of task
analysis to increase its effectiveness.
HTA serves as both an analytical framework and a practical tool for
designers.
Task Analysis - Hierarchical
A hierarchy is an organization of elements that, according to
prerequisite relationships, describes the path of experiences
a user must take to achieve any single behavior that appears
higher in the hierarchy.
Thus, in a hierarchical analysis, the designer breaks down a
task from top to bottom, thereby, showing a hierarchical
relationship amongst the tasks, and then the task is
sequenced bottom up.
For example, in the diagram, task 4 has been decomposed
into its enabling tasks implying that the user cannot perform
the third task until he/she has performed the first and second
tasks respectively.
Task Analysis - Hierarchical
How do I conduct a hierarchical analysis?
The starting point for constructing a hierarchy is a
comprehensive list of the tasks that make up a job or
function. There are three major steps to constructing a
hierarchy:
1. Cluster or group the tasks.
2. Organize tasks within each group to show the hierarchical
relationships for learning. Ask yourself "What would the
learner have to learn in order to do this task?”
3. Confer with a subject matter expert to determine the hierarchy’s
accuracy. This step occurs concurrently with Steps 1 and 2.
Task Analysis - Hierarchical
Task Analysis - Hierarchical
Task Analysis - Hierarchical
Task Analysis - Hierarchical
Task Analysis - Hierarchical
Task Analysis - Hierarchical
The strengths and weaknesses of HTA flow from its strong system-centric
stance. While user-centered design advocates often see task analysis as
requiring deep understanding of individual behavior, HTA theory views
tasks in a more abstract sense, as a set of interlinked goals, resources and
constraints. The focus is on the system and its properties (Shepherd,
2001).
The system-centricity of HTA is logical given its close ties to systems
engineering and ergonomics. These fields typically analyze systems with
the same hierarchical approach that HTA applies to tasks—systems consist
of subsystems, which then interact through various inputs and outputs.
It is recognized that the system (or the task) exists in a wider context, which
may influence its behavior, but little attempt is made to model this context
explicitly.
Shepherd, A. (2001). Hierarchical task analysis. New York: Taylor & Francis.
Task Analysis - Hierarchical
HTA recognizes the responsibility of the operator (user) to plan the use of
available resources to attain a given goal, but it treats the operator’s
cognitive processes as a black box.
But—as has long been apparent in HCI—it is crucial to understand the
structure of human cognition in order to appropriately support cognitively
intensive tasks.
Cognition is intimately connected to sociocultural processes (Hollan, et al.,
2000), but HTA provides no systematic way for dealing with the rich social
and physical context in which activities are embedded. Similarly, HTA fails
to support the components needed to analyze system flows and dynamics.
These limitations necessitate the use of additional theoretical structures to
develop a more complete understanding of human activity.
Hollan, J., Hutchins, E. and Kirsh, D. (2000). Distributed cognition: Toward a new foundation for human--computer interaction research.
ACM Transactions on Computer-Human Interaction, 7(2), 174-196.
Task Analysis - Introduction
Task Analysis - Cognitive
What do we find if we peer inside the
“black box” of cognition?
By developing models of how the brain
and body respond in certain situations,
psychologists have created valuable
insights for HCI theorists and designers,
enabling them to create what Norman
(1988) calls “natural mappings” between
cognition and interface.
Norman, D. (1988). The Design of Everyday Things. New York: Doubleday.
Task Analysis - Cognitive
Card et al. developed an engineering
model of human performance—GOMS.
GOMS enables the characterization of
human performance to be applied to task
analysis.
According to Card et al., the purpose of a
task analysis is to map out the
constraints imposed on behavior by the
nature and features of the task
environment, and to determine what
users knows about the task, and when
they know it.
Card, S., Moran, T. and Newell, A. (1983). The Psychology of
Human-Computer Interaction. Hillsdale, NJ: Lawrence Erlbaum.
Goals, Operators, Methods (GOM)
Task Analysis - Cognitive
Task Analysis - Cognitive
A. Cognitive Task Analysis:
B. Knowledge Elicitation:
•
•
•
Interviewing/Observing Methods:
Process Tracing Methods:
Conceptual Methods:
C. Computational Cognitive Modeling
•
•
GOMS Family of Models:
Integrated Cognitive Architectures:
Task Analysis - Cognitive
GOMS models (Goals, Operators, Methods and Selection rules)
Goals are defined as a symbolic structure that defines a state of affairs to be
achieved and determines a set of possible methods for achieving it.
Operators are defined as elementary perceptual, motor or cognitive acts whose
execution is necessary to change any aspect of the user’s mental state or to
affect the task environment.
A method is defined as a description of a procedure for accomplishing a goal, and
is one of the ways that users store their task knowledge. Methods are learned
procedures that the user already has and are not created during a task
performance.
The selection rules in a GOMS task analysis determine how a user selects a
particular method, and can be used to predict which method the user will select
on the basis of knowledge of the task environment (Preece et al., 1994).
Preece, J., Rogers, Y., Sharp, H. Helen, Benyon, D., Holland, S., and Carey, T. (1994). Human-Computer Interaction. Harlow,
England: Addison-Wesley.
Task Analysis - Cognitive
Task Analysis - Cognitive
Cognitive Task Analysis
Close analysis of cognitive activity has led to another class of techniques, known
as Cognitive Task Analysis (CTA).
Development of CTA has been motivated by the observation that as “tasks have
become more intricate, knowledge-intensive, and subject to increasingly
integrated forms of technological support, traditional forms of task decomposition
appear to have an overly restricted scope” (Barnard and May, 2000:147).
In contrast to GOMS-style cognitive models, CTA targets more abstract, highlevel cognitive functions (Militello and Hutton, 2000).
Barnard, P. and May, J. (2000). Towards a theory-based form of cognitive task analysis of broad scope and applicability. In:
Schraagen, et al., 147-163.
Militello, L. and Hutton, R. (2000). Applied cognitive task analysis (ACTA): a practitioner’s toolkit for understanding cognitive task
demands. In Annett and Stanton (2000): 90-113.
Task Analysis - Cognitive
Cognitive Task Analysis
Compared to HTA or GOMS, CTA presents quite different challenges to the
analyst.
It requires deep engagement with a particular knowledge domain, working closely
with subject-matter experts to elicit their knowledge about various tasks
(Chipman, Schraagen and Shalin, 2000).
Here, many techniques—such as structured interviews, naturalistic observation,
ethnography and contextual inquiry—could be of value.
Ultimately the analyst must seek to define a coherent knowledge representation
for the domain being studied.
Chipman, S., Schraagen, J. and Shalin, V. (2000). Introduction to cognitive task analysis. In Schraagen, et al., 3-24.
Task Analysis - Cognitive
Cognitive Task Analysis
CTA represents an attempt to capture task expertise. Since expertise is often tacit
or idiosyncratic in nature, it can be much more difficult to analyze than the explicit
actions typically considered by HTA.
In fact, CTA requires “making explicit the implicit knowledge and cognitiveprocessing requirements of jobs” (Dubois and Shalin, 2000). This challenge has
spawned a diversity of CTA methods.
A significant problem with many CTA techniques is that studying high-level
cognitive functions in a real task situation is very difficult. Studies may take
months or years and rely on the dedicated efforts of senior researchers.
Dubois, D. and Shalin, V. (2000). Describing job expertise using cognitively oriented task analyses (COTA). In Schraagen, et al.
(2000).
Task Analysis - Introduction
Task Analysis – Active/Process
Activity theory derives from the Russian ergonomic tradition, which takes a
more holistic view of work (Bedny and Meister, 1997). In contrast to informationprocessing psychology it models people as agents, rather than as collections of
cognitive attributes. In contrast to traditional task analysis it takes an “activity,”
rather than a task, as the highest level of analysis.
Activities, as opposed to tasks, are inherently context-sensitive.
The key principle of activity theory is to establish a “minimal meaningful context”
for individual actions (Kuutti, 1996).
This context is the activity, defined as “a form of doing directed to an object.”
Bedny, G. and Meister, D. (1997). The Russian theory of activity : current applications to design and learning. Mahwah, NJ: Lawrence
Erlbaum.
Kuutti, K. (1996). Activity Theory as a potential framework for Human-Computer Interaction research. In Nardi (1996).
Task Analysis – Active/Process
What is a procedural analysis?
Unlike learning a concept or a principle, procedures are strictly defined so that
each step is clear and unambiguous to the learner.
Procedures can be simple, whereby the learner follows one set of steps in a
sequential fashion. However, procedures can also be complex, with many
decision points that the learner must make.
Regardless of the complexity of the procedure, a procedural analysis breaks
down the mental and/or physical steps that the learner must go through so that
the task can be successfully achieved.
The steps that make up a task are arranged linearly and sequentially, illustrating
where the learner begins and ends.
Oftentimes, the steps throughout the task, from start to finish, as well as any
decisions that the learner must make are arranged in a flowchart, but they can
also be done in an outline form.
Task Analysis – Active/Process
What is a procedural analysis?
Learning goals that are procedures are the easiest goals upon which to conduct
an instructional analysis.
Generally, application of procedures involves these steps:
1. Determine whether a particular procedure is applicable.
2. Recall the steps of the procedure.
3. Apply the steps in order, with decision steps if required.
4. Confirm that the end result is reasonable.
Task Analysis – Active/Process
What is a procedural analysis?
Flowcharting has a language of its own.
The following are the generally accepted conventions for flowcharting.
Task Analysis – Active/Process
Task Analysis – Active/Process
Task Analysis - Introduction
Task Analysis - Software
Task Analysis - Comparison