Int. J.

Human-Computer Studies (2001) 55, 453}483

doi:10.1006/ijhc.2001.0486
Available online at http://www.idealibrary.com on

Context of Use within usability activities

MARTIN MAGUIRE
HUSAT Research Institute, Loughborough University, The Elms, Elms Grove,
Loughborough, Leics LE11 1RG, UK. email: m.c.maguire@lboro.ac.uk

(Received 22 November 2000, and accepted in revised form 24 April 2001)

Designing for usability involves establishing user requirements for a new system or
product, developing design solutions, prototyping the system and the user interface, and
testing it with representative users. However, before any usability design or evaluation
activity can begin, it is necessary to understand the Context of ;se for the product, i.e. the
goals of the user community, and the main user, task and environmental characteristics
of the situation in which it will be operated. This paper describes the background to, and
importance of, understanding Context of Use, and presents a process for performing
a context analysis. The method described is particularly aimed at non-experts in the area
of user-centred design and evaluation.
 2001 Academic Press

KEYWORDS: context of use; user; task; environment; usability.

1. Introduction
Context is an important concept in everyday life. People often provide context when
writing postcards referring to the weather or holiday atmosphere. A knowledge of
context can also help to explain why an art object such as Donatello's bronze statue of
David was produced. As stated by Clark (1992), &&such monumental "gures were sym-
bolic of a new-found con"dence, and represented the freedom of Renaissance man from
the medieval past''. Context can also explain the background to an historical event, such
as the assassination of the Archduke Ferdinand in Sarajevo, which triggered war in
Europe in 19142and, of course, words taken out of context often distort the speaker's
intended meaning!
When a product (or system) is developed, it will be used within a particular context.
It will be used by a user population with certain characteristics. The user will have
certain goals and wish to perform various tasks. The product will also be used within
a certain range of technical, physical and social or organizational environments that may
a!ect its use.
When assessing a product from Human Factors (HF) point of view, there is a tendency
to forget about the Context of Use. Information Technology (IT) products are often
simply divided into those which are usable and have &&ergonomic features'' and those
which are not. In fact, it is incorrect to describe a product as ergonomic or usable,
without also describing the context in which the product will be used*in other words,
whom the product was designed for, what it will be used for and where it will be used.

1071-5819/01/100453#31 $35.00/0  2001 Academic Press

454 M. MAGUIRE

A manufacturer might, for instance, claim to have a very usable wristwatch. In fact, it
may only be usable in a certain range of contexts. The visual nature of the display might
exclude people who are visually impaired. If the watch face lacks numbers and minute
markings, this would make it unsuitable for tasks that require precise timings at a sports
meeting. Without luminous or illuminated dial markings, the watch would not be
suitable for use in the dark, whereas the use of re#ective glass could impede viewing in
bright light. Unless it is a watertight watch, it may be a!ected by rain and would certainly
not work under water. This example shows the pitfalls of classifying a watch or any other
product, as usable without referring to the context for which it is intended.

2. The development of context of use ideas

2.1. EARLY RECOGNITION OF CONTEXT

In the "eld of natural science, the procedure of specifying, controlling and reporting the
context in which measurement takes place has been routine for centuries. This procedure
ensures that measurements are both meaningful and reproducible. Much of the early
Human Factors work was performed in the military sector to test equipment compo-
nents in unstable, harsh and extreme environments to represent battle"eld conditions. In
the "eld of human computer interaction (HCI), it has been recognized for many years
that the users and the tasks they carry out are likely to have a strong e!ect on the results
of any system evaluation (Miller, 1971).

2.2. REALISTIC USERS AND REPRESENTATIVE TASKS

Many authors have emphasized the importance of selecting representative users and
realistic tasks when carrying out user testing or evaluation of IT products (Neal
& Simon, 1984; Bury, 1984; Rosenbaum, 1989). Yet, if the literature is explored, it is often
found that evaluation studies have either used unrepresentative subjects to carry out
unrealistic tasks, or more commonly have failed even to report the nature of the subjects
and the tasks they carried out. Often it is only after the study has been completed that the
e!ects of badly chosen subjects and tasks will be used to explain the &&odd'' nature of the
results.

2.3. TASK TOOL ANALYSIS

By the early 1980s the di!erences in characteristics of particular user groups were well
established. At the HUSAT Research Institute, several papers were produced character-
izing users of di!erent kinds such as managers, clerical sta! and specialists and discussing
their needs. Eason (1981) presented the concept of the user}task}tool analysis, highlight-
ing the fact that the user and task characteristics have to be supported by characteristics
of the tool, i.e. the computer system or product.

2.4. THE WORK OF WHITESIDE AND COLLEAGUES

In the mid-1980s there was an increase in awareness of context issues promoted by the
work of Whiteside and his colleagues (Whiteside, Bennett & Holtzblatt, 1988; Wolf,
CONTEXT OF USE 455

1989). They found that although many products performed well in their laboratory
experiments, they did not work when transferred to the real world. They put this down to
the fact that the research often overlooked something crucial to the context in which the
product would be used. The classical research methodology which they applied told
them a lot about how to control variables, but little about how to select the most
important variables in the "rst place. As a result of this they developed contextual
research, where they would work with people carrying out real work in real situations
rather than &&arti"cially contrived'' ones. In adopting this approach, Whiteside and his
colleagues not only stimulated the discussion on the relative merits of laboratory vs. "eld
studies, but also highlighted the importance of context issues.

2.5. LABORATORY VS. FIELD STUDIES

Laboratory tests and "eld observations are both valuable methods for product
evaluation which complement each other in the design process. The high degree of
control and enhanced observation and video-recording facilities associated with laborat-
ory studies are particularly suited to summative evaluation, where the aim is to test
whether a product meets certain prede"ned usability criteria. Field studies may then be
used to &&identify special problems associated with the integration of the product into the
actual working environment'' (Neal & Simon, 1984). Furthermore, "eld studies can tell
you about the acceptability of a product (i.e. whether the product will actually be used in
real life), whereas, in laboratory tests where the subjects generally have no option but to
use the product, this is often not possible. Karat (1989) demonstrated the complementary
nature of the two approaches by applying both laboratory and "eld studies in order to
help iteratively design a security application. Interestingly, participants completed the
tasks in 25% less time in the "eld than when subjects completed similar tasks in
laboratory conditions. Karat comments that &&there are possible problems in comparing
the results of the di!erent tests; however the bene"ts of having both types of test data
outweigh the negative factors''.

2.6. THE USABILITY CONCEPT

Usability became a well-established concept in the IT world to represent the user-
friendliness of a system. However, there was a need to establish the concept more clearly
and to determine how to measure it. Shackel has done much work in this area, starting
by his paper on The Concept of Usability in 1984, and through to his approach to
de"ning usability in an operational manner (Shackel, 1986, 1991).

2.7. THE HUFIT TOOLSET

In 1985, a large-scale European project was started within the EU ESPRIT I pro-
gramme, called HUFIT (HUman Factors and Information Technology). This brought
together a number of university institutions and major IT companies for the "rst time to
try to integrate Human Factors methods into the IT design cycle. Within this project, the
456 M. MAGUIRE

HUSAT Research Institute developed the planning, analysis and speci"cation

toolset (PAS), reported by Taylor (1990). This provided a process for identifying stake-
holders and analysing their characteristics in order to develop a system to match
them.

2.8. THE MUSiC APPROACH TO CONTEXT

The ESPRIT II MUSiC project built on the work of HUFIT. It aimed to develop
standard measurement tools and methods for usability evaluation. An important con-
cept that the project developed was &&Measurement of Usability in Context'' (hence the
name MUSiC). In an attempt to ensure that proper attention was paid to context issues,
the MUSiC project advocated the following principles.
E The usability of a product depends on its Context of Use.
E Products should be designed for speci"c contexts.
E Measurement of usability must always be carried out in an appropriate context.
E Usability measurements should always be accompanied by a detailed description of
the context of measurement.
Recording the context of measurement information allows other people to assess the
validity or fairness of the measurement, and gives them the opportunity to generalize the
results of the measurement to their own context if they see "t. It was recognized in
the MUSiC project that the guidelines and principles presented above can only be put
into practice if suitable tools and methods are available. This led to the development of
a Context of Use Questionnaire (Maissel, Dillon, Maguire, Rengger & Sweeney, 1991;
Thomas & Bevan, 1995) to describe a product's Context of Use and to specify an
appropriate context of measurement (Bevan & Macleod, 1994).

2.9. USER REQUIREMENTS SPECIFICATION

Establishing user requirements has tended to be an unstructured approach, unlike the
formal process of system requirements engineering. The EU Telematics Applications
Programme RESPECT (Requirements Engineering And Speci"cation In Telematics)
project (http://www.lboro.ac.uk/research/husat/respect) developed a structured process
for user requirements speci"cation, and the translation of those requirements into
speci"cations. An important component of this process was to specify the future Context
of Use for the system and thence to identify potential user requirements. Templates to
support this activity are contained within the RESPECT Handbook (Maguire, 1998).

2.10. MOBILE ENVIRONMENTS

The development of mobile and in-vehicle devices such as navigation systems has created
new areas for Human Factors research and design. Usability evaluation of such
products needs to be carried out in realistic environments such as in a driving simulator
or on the road. First, of course, the Context of Use for such systems must be reviewed and
de"ned. Ross and Burnett (2001) provide an example of this type of study, and discuss the
in#uence of di!erent contextual factors on driver performance.
CONTEXT OF USE 457

FIGURE 1. The human-centred design cycle (from ISO13407).

2.11. CONTEXT OF USE IN STANDARDS

The international standards community has also recognized the role of Context of Use
within usability. The ISO 9241 standard Part 112Guidance on ;sability (ISO, 1997)
refers to it in its de"nition of usability:

&&Usability is the extent to which a product can be used by speci"ed users to achieve speci"ed
goals with e!ectiveness, e$ciency and satisfaction in a speci"ed context of use.''

This de"nition emphasizes that the usability of a product is a!ected not only by the
features of the product itself, but also by the speci"c circumstances in which a product is
used. As de"ned by the standard:

&&The Context of Use consists of the users, tasks and equipment (hardware, software and
materials), and the physical and social environments in which a product is used.''-

Context of Use is also incorporated into the ISO 13407 standard on human-centred
design (ISO, 1999). This de"nes the process of understanding and specifying the Context
of Use as one of the main stages within the human-centred design process (see Figure 1):

-Note: The term &&usability'' is sometimes used to refer speci"cally to the usability attributes of a product, e.g.
the ISO/IEC 9126 standard (ISO, 1991) de"nes it as a software quality and describes it as &&A set of attributes of
software which bear on the e!ort needed for use and on the individual assessment of such use by a stated or
implied set of users''. In contrast, usability in ISO 9241*Part 11 (ISO, 1997) refers to the outcome of
interaction in a context: i.e. the extent to which the intended goals of use of the overall system are achieved
(e!ectiveness); the resources such as time, money or mental e!ort that have to be expended to achieve the
intended goals (e$ciency); and the extent to which the user "nds the overall system acceptable (satisfaction). To
distinguish the two concepts, the latter concept of usability has become known as: &&Quality in Use''.
458 M. MAGUIRE

TABLE 1
Producing a description of the Context of ;se at di+erent stages in the design process
Describing the Context of Use

Who When Why

Procurer and Speci"cation stage To aid speci"cation of user

usability analyst requirements.
To set usability goals and acceptance
criteria.

Designer Concept stage To ensure high-quality design by

tailoring the product to the context
and introducing early assessment of
usability.

Usability analyst Testing stage To match the Context of Measurement

to the Context of Use.

Project manager or Throughout the To help them be aware of usability

system developer process issues throughout the design process
and to track the achievement of
usability goals.

3. Context of Use in product design

3.1. BENEFITS
The analysis of the Context of Use helps to specify, in a systematic way, the character-
istics of the users, the tasks they will carry out and the circumstances of use. The bene"ts
of adopting this approach are as follows.
E Provides an understanding of the circumstances in which a product will be used.
E Helps to identify user requirements for a product.
E Helps address issues associated with product usability.
E Provides contextual validity of evaluation "ndings.
It also provides a system focused approach which leads to a shared view among the
design team.

3.2. WHEN AND WHO MAY WISH TO PERFORM CONTEXT OF USE ANALYSIS?
An understanding of the Context of Use of a product plays a role at di!erent stages in the
design process. Table 1 summarizes who should be involved in describing and re-
describing Context, at what stages in the lifecycle and the bene"ts that this will bring.

4. Summary of contextual factors

This section provides a description of the main aspects of context. It is followed by a table
listing the di!erent contextual factors (Table 2).
CONTEXT OF USE 459

TABLE 2
Components of Context of ;se analysis
System report and User Task
stakeholder analysis

System or product report User name Task list

E System or product name E User type E Task 1
and version E User role E Task 2, etc.
E System or product
description and purpose Experience, knowledge and E Task characteristics (per
E Main application areas skills task)
E Major functions E Product experience E Task name
E Target market E Related experience E Task goal/output
E Task knowledge E Task steps
Stakeholder report E Organizational knowledge E Task frequency
;ser and stakeholder list E Training E Task duration
E Input device skills E Task #exibility
User/stakeholder type 1, 2, etc. E Quali"cations E Task dependencies
Descriptions E Language skills E Physical and mental
E User/stakeholder type demands
E User/stakeholder role or Personal attributes E Task output
goals E Age, gender E Risks resulting from error
E Potential bene"ts from E Physical capabilities and E Safety critical demands
system or product limitations
E Costs of using E Cognitive capabilities and
system/product limitations
E Further analysis to be E Attitude and motivation
carried out? (i.e. Context of
;se analysis)

Environment

Technical environment Physical environment Organizational environment

E Hardware Workplace conditions Structure
E Software E Atmospheric conditions E Group working
E Network E Auditory environment E Work practices
E Reference materials E Thermal environment E Assistance
E Other equipment E Visual environment E Interruptions
E Environmental instability E Management structure
E Communications structure
Workplace design E Salary or payment
E Space and furniture
E User posture Attitudes and culture
E Location E Policy on computer use
E Organizational aims
Workplace safety E Industrial relations
E Health hazards
E Protective clothing and Job design
equipment E Job functions
E Hours of work
E Job #exibility
E Performance monitoring
E Performance feedback
E Pacing, autonomy,
discretion
460 M. MAGUIRE

4.1. USER GOALS AND CHARACTERISTICS

The central part of the Context of Use analysis of a system focuses upon the users of the
product. A stakeholder analysis should be performed to identify all the di!erent users of
the system, and also those who are a!ected by it, i.e. have a stake in its success. If the user
population is composed of more than one user type, then an analysis should be
completed for each type. Relevant characteristics of users also need to be described.
These can include knowledge, skill, experience, education, training, physical attributes
and motor and sensory capabilities.

4.2. TASKS
Tasks are the activities undertaken to achieve a goal. Characteristics of tasks which may
in#uence usability should be described, e.g. the frequency and duration of the task. Tasks
should not be described solely in terms of the functions or features provided by a product
or system. Descriptions of the activities and steps involved in performing the task should
be related to the goals that are to be achieved. For the purpose of specifying user
requirements or evaluating usability, a key subset of contextual tasks will typically be
selected to represent the signi"cant aspects of the total set of tasks.

4.3. TECHNICAL ENVIRONMENT

The technical environment is the software and hardware which is used in conjunction
with the product. The characteristics of the technical environment (such as the speed of
the processor or the layout of keys on the keyboard), may have an a!ect on the usability
of the product.

4.4. PHYSICAL ENVIRONMENT

The physical environment can have a profound e!ect on the usability of a product. Bad
lighting or loud noise in the workplace may actually prevent the users from receiving
vital feedback from the product. Likewise, even the location of the product in relation to
the user's workplace can magnify the e!ect of minor usability problems, such as having
to reinsert cassettes frequently when the tape backup machine is located down the
corridor (Brooke, 1986).

4.5. SOCIAL OR ORGANIZATIONAL ENVIRONMENT

The organizational environment will also a!ect the usability of a product. At a higher
level, the attitudes of the organization and its employees towards the introduction of an
IT system, and the way work is monitored, can a!ect whether a system is accepted and
used to carry out the work. At a lower level the structure of the organization, the way
people work (individually and in groups), the availability of assistance and the frequency
of interruptions, are also likely to a!ect the usability of a product.
A list of contextual factors is presented in Table 2. This draws from the work of
Maissel et al. (1991), Thomas and Bevan (1995) and from ISO 9241 part 11 (ISO, 1997).
CONTEXT OF USE 461

Context of Use information needs to be collected under each of the headings for the
context in which the equipment is actually used (or is intended to be used).

5. Stages in performing a usability context analysis

Before the context study is begun, a small &&usability team'' should be set up consisting of
at least one usability analyst, and one person with a good knowledge of the product, its
intended users and any constraints that may occur during the evaluation. It is also
important to include someone of su$cient seniority to ensure that results of the study
can be used to in#uence decision-making.

The results from a usability context analysis are typically captured in a set of Context
Tables. The tables shown in section 6 of this paper (Tables 4 to 11) may be used to guide the
process of collecting the context information. These tables give examples of typical output
from analysing the Context of Use of a bank &&cashpoint machine'' to illustrate the process.

One method of collecting information required in the Context Questionnaire is by

holding a meeting of the usability team (a &&Context Meeting'') with people who can
supply the required information*the stakeholders. This is a cost-e!ective way to elicit
the information, but care must be taken to ensure that everyone has an opportunity to
express their views and that they are accurately recorded. If it is possible that views
cannot be expressed freely, for example because of power relationships which may exist
between the participants, then separate meetings must be arranged with groups of people
at similar levels in the organization.
Collecting information about the Context of Use of a product will also encourage
other participants in the design process to consider context-related issues, and to make
explicit their views of the assumed Context of Use. Information is required for all the
contextual components*users, tasks and environments*and views may be requested
from di!erent departments. A list of personnel from whom information may be collected,
or who may be invited to the Context Meeting are shown in Table 3.
The following steps are involved in specifying the Context of Use for a product.
Step 1: Describe the product or system (or concept) within a Project Report.
Step 2: Identify users and other stakeholders for the product or system and select main
user groups for further analysis
Step 3: Describe the Context of Use
Step 4: Identify important usability factors
Step 5: Document potential requirements or test conditions
The "ve steps are described brie#y below.
Step 1: Describe the product or system. The development of a new or existing product
will normally take place as a &&project''. It is important for the user requirements analyst
to gain a high level of understanding of the product and the reason for its development. It
then becomes possible to understand how this will a!ect the user population. The
information may be drawn from the initial statement of requirements. It may require
reading and understanding the basic system proposal and asking for clari"cation where
needed. The information is placed in a Project Table or Report.
462 M. MAGUIRE

TABLE 3
People who can provide information for a Context Study
Job title Role in product (or system) development

Customer Commissions the product and sets requirements.

Project manager Responsible for the current product development

activities.

Systems analyst Identi"es requirements and makes speci"cations.

Designer/programmer Programmes the system.

Marketing specialist Plans the promotion strategy and advertising.

Technical author Produces user documentation.

Technical/user support Provides support to end-users when required.

Users Help develop requirements, provide input and feedback

on prototype, require training and support.

Quality manager Responsible for the implementation of quality systems.

Training manager De"nes user training requirements.

Human Factors specialist Responsible for usability aspects of the system.

The Project Report should be completed with the input from people with appropriate
knowledge of the product. During development this would include product development
managers, technical developers, sales and marketing sta! and documentation and
training material authors. When the product is being evaluated by a user organization,
the individuals involved could be product installation managers and technical support
sta! (cf. Table 4 for an example of a Project Report).
Step 2: Identify users and other stakeholders. This section identi"es the main users and
stakeholders for the product in order to get a broad perspective on who is involved and
a!ected by it. This will help to ensure that the needs of all involved are taken account of
and, if required, the product is tested by them. Stakeholder analysis will identify the
following.
E Primary user groups*those who use the system directly (&&hands on''). They may or
may not be the purchaser of the system. They include: end-users, installers, main-
tainers.
E Secondary user groups*those who in#uence or are a!ected by the system, but may
not be the actual users. They include: recipients of output from the system, marketing
sta!, purchasers (who are not also the main users) and support sta!.
E For each groups of users and stakeholders, it is important to identify their main roles or
task goals in order to "nd out how useful and appropriate the product can be to them.
(cf. Table 5 for an example of a Stakeholder Analysis Report).
CONTEXT OF USE 463

Step 3: Describe the Context of Use. The next step is to document the Context of Use
factors related to the product. A set of tables has been produced to help elicit contextual
information. A completion of the tables will help to create a comprehensive description
of the Context of Use of a product. It guides the usability analyst through a structured
breakdown of the relevant characteristics of the intended users, tasks and environments
for which the product is being developed.
Knowledge of the Context of Use in itself will improve the design of a product. It
encourages designers to tailor the design to the speci"ed real-world usage, and also to
specify usability criteria so the product's usability can be assessed by evaluation through-
out the design process (See the left-hand column within Tables 6}11, for example
components of a Context of Use Description Report.)
Step 4: Identify important usability factors. The usability analyst then uses the Context
Report Table to consider each of the components of the Context of Use, and decide
whether or not they could a!ect the usability of the product. There are three possible
responses to this question*&&yes'', &&maybe'' or &&no''. If the answer to this question is &&yes''
then it is considered a critical component of the context. If the analyst is unsure whether
a component will a!ect the usability of the product, he or she can reply &&maybe'' to the
question, and re-evaluate the response when it comes to step 3 of the procedure. If the
answer is &&no'' or if the component is not relevant to the product, then the analyst will
not have to consider this component any further. Each decision has to be made based on
the usability analyst's knowledge of HCI and ergonomics, and their experience of similar
product evaluations (See the middle column within Tables 6}11 to show the identi"cation
of usability factors within the Context of Use Description.)
Critical components must be identi"ed regardless of whether they can be represented
in the Context of Evaluation. Other parties, such as consumer organizations, can
then assess the validity and generalizability of the usability evaluation results. If it is not
feasible to simulate any of the critical components, e.g. the availability of a Help
Desk, then they will be omitted from the Context of Evaluation. The implementation of
any of the critical components of the Context of Use in the Context of Evaluation depends
upon the scope of the usability evaluation and any "nancial and technical constraints.

Step 5: Document potential requirements or test conditions. Having documented the

Context of Use, and identi"ed the important components, the next step is to document
(a) potential user requirements which follow on from the context information and (b)
features of the usability evaluation study that should be included when the product is
ready for testing.
For establishing user requirements, it is helpful to go through each usability compon-
ent as part of a brainstorm and propose ideas that could address potential problems
related to the context or that would match speci"c user needs or task characteristics. (See
the right-hand column within Tables 6}11 to show potential user requirements labelled
&Req' or test conditions, labelled &Test'.)
For establishing the characteristics of a usability test, each usability component
(marked as &&yes'' or &&maybe'') may be classi"ed as follows.
Ignore: No consideration given to setting the context item in the evaluation (e.g.
do not care whether subjects have glasses or not).
464 M. MAGUIRE

Monitor: Context item not speci"ed in the evaluation, but values will be monitored
to avoid extreme conditions (e.g. no restriction on the proportion of male
to female subjects but avoiding all men or all women).
Control: Set value for the context item either ,xing it e.g. lighting level, or varying it
e.g. to meet a certain characteristic e.g. having subjects in three di!erent
age categories.
Evaluate: Decide how to test, for example use two or more evaluation conditions for
comparison, e.g. equal numbers of subjects with and without previous
experience of using touch screens.

5.1. OPERATIONALIZING THE DECISIONS

When the analyst has decided whether a component should be controlled, monitored or
developed experimentally, etc., he or she must then specify exactly how this is to be
carried out. For example, if the analyst has decided to provide assistance, then a decision
must be made on how that can be provided in a standard format.
The next step is to develop an evaluation plan, which contains all relevant information
from the Context Report giving speci"c details of how the evaluation will be performed.
The plan should include the following.
E The number of users who will take part in the evaluation, what characteristics they
should have (those which are to be Controlled), and what are to be determined as part
of the evaluation (those which are to be Monitored).
E The tasks that the users will carry out as part of the evaluation and how the users will
be introduced to it.
E The organizational conditions under which the users will work. For example, the
number of and nature of any interruptions identi"ed in the Context of Use as a!ecting
usability.
E Details of the hardware, software and any network environment that will be provided
during the evaluation.
E Description of the physical location and characteristics of the workplace.
Finally, the evaluator should de"ne the usability measures to be recorded and success
criteria associated with them. This can take place early in design to form part of the
product requirements. During detailed design, the main objective may be to obtain
design feedback from informal evaluation of mock-ups and partial prototypes, in which
case measures may not be required.

6. An example Context of Use for an ATM (bank machine)

The following "ctitious example, designed to illustrate the procedure, has been used
during several training courses. It documents the Context of Use for an Automated
Telling Machine (ATM) which can provide simple banking services automatically to bank
customers. These devices are also often called &&cashpoint machines'' or &&bank machines''.

6.1. DESCRIPTION OF PRODUCT

The aim of this project is to produce a usable new generation of bank machine. The aim
is to broaden the facilities available to existing ATM users and to encourage the 24% of
CONTEXT OF USE 465

TABLE 4
Project summary
Project summary

Product or system name ATM 2000=a new generation of indoor bank machine.

Aim or characteristics of the E ¹o provide an increased range of services to bank

system customers via bank machines.
E ¹o o+er a reliable service with the machines out of operation
for less time.
E ¹o o+er a more secure and safe service.

Reason for system E ¹o promote the wider use of bank machines in a

competitive market.
E ¹o encourage new users such as people who are elderly
and disabled.

Target marketplace E Banks and building societies.

Scope of system/system E ¹raditional services of cash withdrawal, statement,

functions planned balance, ordering chequebook, etc.
E Short on-line introductions for new users and spoken
instruction.
E Possible new services include getting change, requesting
a loan, transferring money between accounts, etc.

bank customers who are non-users to consider using them. Reasons for non-use are:
distrust of computers, anxiety about becoming targets for muggers and forgetting
PINs or secret access numbers (Derbyshire, 1999). Another reason may be limited
English language skills. In this example, the product constitutes the software and
hardware that a customer sees when using an ATM. (See Table 4)

6.2. STAKEHOLDER ANALYSIS

An analysis of stakeholders has identi"ed bank customers as the primary users with bank
sta! and machine maintenance sta! as secondary users. Another group with a stake in
the system are bank marketing sta!. (See Table 5)

6.3. RECORDING CONTEXT OF USE

Tables 6 to 11 describe the Context of Use for the system or product for the bank
customer. There are separate tables for the users themselves, their tasks and the technical,
physical and organizational environments. In each table:
Column 1 is used to record the characteristics of the context in which the ATM will be
used.
Column 2 is used to record whether each of the context items a!ects usability of the
product (i.e. &&yes'', &&no'' or &&maybe'').
466 M. MAGUIRE

TABLE 5
Result of stakeholder analysis
Stakeholders and task goals

System name: ATM 2000=A new generation of bank machine

Primary users Main task goals

Bank customer ¹o obtain money

¹o request information (statement or balance)
¹o order a cheque book or statement
¹o perform account transactions and pay bills
¹o open and close an account.
¹o obtain an alternative bank service e.g. order foreign currency,
set up a loan, set up savings, insurance or pension scheme.

Secondary users Main task goals

Bank sta+ =ill be responsible for day-to-day maintenance, e.g. ,lling

machine with paper ( for receipts and statements), correcting
minor faults and reporting major faults.

Machine maintenance sta+ =ill perform routine maintenance every 6 months and will come
out to deal with major faults.

Security sta+ ¸oad A¹Ms with pre,lled cassettes of notes.

Other stakeholders Main task goals

Bank marketing sta+ =ill be concerned with deciding what services to o+er on the
machine and what advertising to display when the machine is
not in use.

Column 3 is used to record potential user requirements or evaluation conditions for

components marked &&yes'' and &&maybe''.
Task scenarios are listed in Table 7 as typical examples of ATM usage.
The task characteristics table (Table 8) should be completed for each task to be
analysed.
Please note: Although the example concerns bank machines located indoors, contex-
tual factors, user requirements and test conditions for machines located out of doors are
also listed for illustrative purposes.
From the above tables, possible user requirements can be identi"ed such as a recess for
wheelchair access, speech output for visually impaired users, customization features for
rapid access, "nger print for identi"cation, visor appearing during sunny weather,
buttons lighting during darkness, register button when faults occur, alarm button for
security alert. The basic structure of a usability evaluation and di!erent evaluation
conditions can also be speci"ed such as users operating the ATM without pre-training or
instructions, with and without gloves, using auditory and manual input, and in di!erent
lighting conditions.
 TABLE 6

CONTEXT OF USE
;ser context description

Context of Use A4ects usability? User requirements or test conditions

1. USERS
1.1. User type

1.1.1. Name of type

Bank customers. Maybe, control ¹est: ;se members of the general public.

1.1.2. User role (or aim)

¹o carry out bank transactions and obtain new services. >es Req: Provide basic transactions and new services in
consistent and similar way.
Control ¹est: Specify typical tasks to re-ect normal user aims and
also ,nancial aspirations.

1.2. Experience/knowledge

1.2.1. Experience/knowledge with system or product

<aries from none to regular daily use. *

1.2.2. Experience/knowledge with similar systems or

products
70% of users will have used bank machines >es Req: ¹ry to make the system conform with any accepted
elsewhere. ad hoc standards for bank machines.
Others will have limited or no experience. Develop ways to introduce new users to machine banking
e.g. video introductions in post, bank sta+ support,
speech instructions, etc.
Monitor ¹est: Check with user length of time card held and frequency
of use.

1.2.3. Task knowledge

Nearly all experienced in withdrawing cash over counter. >es Req: Study bank counter exchanges for new forms of
Goal is essentially the same but task process di+erent transaction proposed and re-ect in self-service kiosk.
(one is self-service, the other is not). ¹est: Include some users who have accounts but rarely

467
visit banks.
 468
1.2.4. Organizational knowledge
Many customers will have little knowledge of bank 2
organization.

1.2.5. Level of training

Mainly none. Some users may have received >es Req: Provide short interactive guide on screen for new users,
introduction from bank sta+. 00help11 facility to support user, spoken instructions
and video to play at home. Ensure job -exibility to allow
bank sta+ to provide support.
Ignore ¹est: Concentrate on testing without providing equivalent
human introduction.

1.2.6. Input device skills

Full range. Some motor impaired users will have very >es Req: Develop speech recognition interface for those with
limited skills. limited keyboard skills.

1.2.7. Quali5cations
Any level. >es Req: Design to be usable by people who may have
limited reading skills (e.g. spoken instructions).
Control ¹est: Include some non-readers.

1.2.8. Language skills

English will be main language. >es Req: ;se English language and up to eight other
Some areas of country will include up to 30% of language options, depending on local area. ;se simple
population where English is second language. terminology, diagrams and pictures.
;sed by tourists, especially from E;. ¹est: Include some users for whom English is second language.

1.3. Personal attributes

1.3.1. Age
16 upwards for main bank customers. Accounts for >es Req: Given particular consideration to older user groups
12}15-year-olds may allow some use of bank machine. who may be more reserved about new technology.

M. MAGUIRE
Control ¹est: Recruit 25% of users in each of the following age
categories: 16}25, 26}40, 41}70, 70#.
 CONTEXT OF USE
TABLE 6
Continued

1.3.2. Gender
Roughly 50% male, 50% female. Maybe, control ¹est: ¹ry to get an even balance between males and females.

1.3.3. Physical capabilities and limitations

Signi,cant minority with visual, hearing, speech, >es Req: Ensure that system keyboard and screen are placed
motor or mental impairments. at a standard height. ;se larger keys and short-cut option.
Provide recess for wheelchair.
Control ¹est: Consider inclusion of wheelchair users, users with
motor control problems and users with visual impairment.

1.3.4. Cognitive capabilities and limitations

Signi,cant minority with memory and other cognitive >es Req: Colour code or number certain key groups to reinforce
problems. sequence. Provide voice prompts on request. Allow user
to cancel easily if unsure.
Control ¹est: Consider inclusion of users with cognitive problems.

1.3.5. Attitude and motivation

Highly motivated to complete task. No

469
470 M. MAGUIRE

TABLE 7
Selection of task scenarios
Context of Use Analyse further

2. TASKS
2.1. Range of typical tasks

1. To withdraw a sum of money quickly. Task T1

2. To check balance, decide how much to withdraw and make withdrawal. Task T2

3. To order a statement and/or cheque book. Task T3

4. To deposit notes or cheque into account. Task T4

5. To transfer funds from one account to another. Task T5

6. To pay a bill e.g. electricity, gas, telephone, TV licence. Task T6

7. To obtain change for a high-value note. Task T7

8. Change PIN or password. Task T8

9. To set up a loan. Task T9

10. To deposit or order foreign currency. Task T10

6.4. EXAMPLE EVALUATION PLAN

An example evaluation plan, based on the product, primary users and test conditions
speci"ed in Tables 4}11, is presented below. References to speci"c parts of the Context of
Use tables are shown in parentheses.
;sers
E The evaluation will be based on members of the general public (n"120), the sample

being obtained via local newspaper advertising and contact with local disability and
community groups (1.1.1). They will be asked to assume the normal role of a bank user
(1.1.2).
E The advertisement will state that people of all ages and physical abilities would be

welcome to take part in the evaluation.

E During the recruitment process (over the telephone), check whether prospective recruit

uses a bank machine and how frequently they do so (1.2.2).

E Recruit the following sample. When recruiting, monitor the sample to achieve roughly

the following balance.

* 40 frequent users (at least once a month)*group 1
* 40 infrequent users (at least once per year)*group 2
* 40 novice users (once or twice only or never at all)*group 3.
* For each group, recruit 10 within each of the following four age
categories: 16}25, 26}40, 41}70, 70#.
CONTEXT OF USE 471

E Provide half of the users in each group with an introduction to use the new machine to
compare trained and untrained user performance (1.2.5).
E If possible recruit 4 of group 3 to be non-readers (1.2.7).
E If possible recruit 4 of group 3 to be persons for whom English is their second language
(1.2.8).
E Recruit even balance of male and female users across the groups (1.3.2).
E Recruit 3 users (one per group) who are wheelchair users (1.3.3).
E Recruit 3 users (one per group) who have limited upper limb movement
(1.3.3).
E Recruit 3 users (one per group) who have visual impairment*to be de"ned more
precisely later (1.3.3).
E Consult disability expert on suitability for users with cognitive impairments
(1.3.4).

¹asks
E Each user will perform the following tasks based on Table 7.
1. Withdraw a sum of money leaving C500 in the account (T2).
2. Deposit foreign currency*5000 Belgian Francs (T10).
3. Obtain foreign currency*100 United States Dollars (T10 } 2.2.6).
4. Transfer C200 to savings account (T5).
5. Change password to mother's maiden name (T8).
6. Set up loan of C1000 over 12 months (T9) using video link and speech interaction to
bank sta! member (3.1).
E Conditions 2.2.5 (long task duration) and 2.2.7 (insu$cient funds to meet request) to be

omitted from tests at this stage.

¹echnical environment
E New multimedia bank terminal (3.1) and software (3.2).
E Two users in each group to use system after reading instruction card (3.4).

Physical environment
E Two bank machines will be set up, one for standing use (1 m above ground*4.2.1) and
one for wheelchair use (4.2.2). During the evaluation any posture or reach di$culties,
particularly for the wheelchair users, will be noted. However, if time permits, informal
testing of the initial height and mounting could be carried out before the main
study.
E Two users in each experience group to use bank machine wearing gloves (4.3.2).
E Test within normal indoor conditions with comfortable temperature (4.1.3) and good

lighting (4.1.4)

Organizational environment
E The evaluation will be based on users working alone (5.1.1)
E No assistance will be given unless the user becomes completely stuck and cannot

proceed (5.1.3)
E Money and receipt will always be given (5.3.5)
E No queue will be simulated (5.3.6 and 5.3.7) although this may be simulated in later

testing.
 472
TABLE 8
¹ask characteristics description

Context of Use A4ects User requirements or

usability? test conditions

2. TASK T10
2.2. Task characteristics

2.2.1. Task name

Order foreign currency. 2

2.2.2. Task goal or output

Obtain currency at an acceptable rate of exchange. >es, Control ¹est: ;se as basis for test task.

2.2.3. Task breakdown Reqs:

Step 1: Enter card. >es 2 Notch/picture to show way to insert.
Step 2: Enter PIN. 2 Allow user to specify password as a
series of alphanumeric characters (to
be more memorable).
Step 3: Select 00Order currency11. 2 Allow speech interaction option.
Step 4: Select currency type. 2 Do not time out too quickly.
Step 5: Show currency exchange rate 2 Having selected currency, show
and change over period. current rate and rate change over
period of time (e.g. last few days).
Step 6: Enter amount. 2 Provide range of standard currency
amounts to withdraw.
2 Allow user to specify amount in ;K or
foreign currency.
Step 7: ¹ake money and collect card. 2 Allow time lapse to allow user to put
money in pocket, purse or wallet.

M. MAGUIRE
2.2.4. Task frequency
<ariable. Average perhaps once every few months. No
 CONTEXT OF USE
2.2.5. Task duration
2}3 min (varies with system response times). >es, control ¹est: System could be tested with long and standard
system response times.

2.2.6. Task 6exibility

;ser may wish to simply obtain currency without checking >es Req: Allow short-cut option.
exchange rates. Allow user to specify amount in ¹est: Both variations where user selects currency and
;K currency or in foreign currency. amount with and without checking rate changes.

2.2.7. Task dependencies

Bank account containing su.cient cash. Bank Card. >es, evaluation ¹est: System could be tested when account does not hold
Knowledge of PIN and withdrawal limit. condition enough money to provide currency amount user requires.

2.2.8. Physical/mental demands

¸ow physical demand. No
¸ow mental demand after initial use.

2.2.9. Risk resulting from error (e.g. forgetting PIN)

¸oss of card. >es Req: Provide means for user to register problem at the
Not receiving money required. time with the machine, and to get 00receipt11 to allow checking
by bank sta+.

2.2.10. Safety critical demands

Generally not hazardous. Possible robbery of people No Req: Provide alert button for user to press if they feel
withdrawing. Growing problem of fraud. unsafe. ¹his alerts bank sta+ and suspends transaction.
Iris or ,nger print recognition for user identi,cation.

473
474 M. MAGUIRE

TABLE 9
¹echnical environment description
Context of Use A4ects User requirements
usability? or test conditions

3. TECHNICAL ENVIRONMENT

3.1. Hardware
A¹M linked via network to bank1s >es, control Req and test: New multimedia bank
computer. terminal with video link and speech
handset also adapted to needs of
disabled users.

3.2. Software
Bespoke transaction software. >es, control Req: ;se -exible development software
to allow for changes.
Include colour/graphic display to
increase attractiveness to customers.

3.3. Network
Established bank communications *
network.

3.4. Reference materials

¹hrough post when card received. >es, control Req: Develop instruction card to send
to new customers in post.
¹est: System to be tested, in the main,
without instructional materials but
allow small number of users to read card
beforehand.

3.5. Other equipment

¹elephone handset for speech >es, ¹est: Set up additional evaluation task
interaction. evaluation to test system using speech interaction
condition and video link.

7. Case studies
Two examples are described here of Context of Use analysis being used to help develop
plans for usability evaluations. Both examples relate to EC projects being coordinated by
the Central Library in Dublin. For both projects, there was a requirement to plan
usability evaluations of prototype systems. HUSAT were asked to guide the evaluation
process.
The "rst example is based on the EC TAP MUMLIB project within the Framework
4 Telematics Applications Programme. Here Dublin City Library, working with partner
organizations Lisbon University and the Dansk Biblioteks Center, had developed a
CD-ROM of modern literature and poetry representing work in Ireland, Portugal and
Denmark. The product had been developed as an educational resource for use in
libraries in the three countries. This was done in both cases by holding a context meeting
with librarians involved both in the project and in supporting the general public visiting
CONTEXT OF USE 475

the Reference Library. A context meeting was held by the author (representing HUSAT)
working through the various stages of Context of Use analysis. The main stakeholders
were members of the general public. The meeting identi"ed a range of typical questions
that the user may wish to answer using the CD-ROM e.g. &&Which novels has Roddy
Doyle produced?'', &&What were the in#uences on the writing career of Sheamus Heaney?''
and &&Which women have made a strong impact in modern Irish literature?'' The
environmental context was also analysed, the main factors being: use without support in
the Reference Library initially (although librarian support could be given if required),
and use in relatively undisturbed environment at a desk. It was found to be very
convenient to replicate this in the context of measurement.
It was decided to develop an evaluation plan control for di!erent levels of user
experience and drawing from di!erent study groups including students, working adults
and librarians. The evaluations were carried out in all three partner countries so the
Context of Use study helped produce a plan where the factors to be kept consistent in the
trials within each country were identi"ed. Thus, for example, the user tasks for Irish users
had to be replicated with similar tasks for users in Portugal and Denmark. The test ran
successfully with both performance and attitude measurements being taken. Recommen-
dations for change were also identi"ed from the results which formed part of the study
report by the author, completed in October 1996.
A second study was part of the EC TAP PDWEB project. Here partners in Ireland
(Dublin City Library), the UK (Calderdale Council) and Sweden (the town of Bastad)
had set up local kiosks in towns and cities providing information for the public. Again
a Context of Use analysis was performed at a meeting involving partners from di!erent
countries and chaired by the author. The main stakeholders identi"ed for study were
local members of the community and tourists. Both groups were included in a usability
evaluation with relevant sets of tasks being developed for each. Thus for local members
of the public, the questions were oriented towards local council information, employ-
ment opportunities, and business start-up information. Questions for tourists empha-
sized local attractions, restaurants and hotels, and how to locate places. The Context of
Use analysis was particularly helpful in identifying environmental factors such as use in
a public place (indoors and outdoors), possibly with people queuing behind them, limited
assistance, and variable lighting and weather conditions. The tests were held on kiosks
located in a variety of places to gather data of real use. In one Swedish "shing town the
kiosk was set in a small boat, placed vertically to create a housing. Tests were run in three
countries and again user performance results and attitude feedback were obtained. The
data were passed to the author to analyse and a report was produced with recommenda-
tions to improve kiosk usability. The work was completed in September 1997.
In both case studies, the author found it helpful to work through the forms identifying
stakeholders, and Context of Use characteristics, i.e. user, task and environmental
characteristics, with the project teams. These were listed on a whiteboard. After deciding
to focus on the end-users for the evaluation work, there was further discussion about the
design of the evaluation plan and which contextual factors should be represented in it
(the Context of Measurement). The author then took this information and developed the
evaluation plan, specifying preparations to be made, how to run each user session, what
measures to take, etc. This approach of discussing the factors at a context/evaluation
planning meeting and producing the outline of a practical evaluation plan helped to cut
 TABLE 10

476
Physical environment description

Context of Use A4ects User requirements or

usability? test conditions

4. PHYSICAL ENVIRONMENT
4.1. Workplace conditions

4.1.1. Atmospheric or weather conditions

Indoor: Comfortable conditions. No
Outdoor: ;K weather conditions2may be uncomfortable >es Outdoor req: Some type of shelter for outdoor kiosk.
e.g. rain, snow wind.

4.1.2. Auditory environment

Indoor: ¸ow noise level. No
Outdoor: ;K urban street. Noise will vary from quiet street >es, control Outdoor test speech interaction outside under normal
at night to busy shopping street heavy tra.c. street conditions.

4.1.3. Thermal environment

Indoor: Generally comfortable temperatures. No
Outdoor: ;K outdoor temperatures varying from Yes, ignore Outdoor test: =ill simulate with winter clothing2see below.
!53C to 303C.

4.1.4. Visual environment

Indoor: Public building lighting. >es, control Indoor and outdoor req: Provide installation guidance
to avoid placement where lighting or glare from
the sun may a+ect machine usage.
Outdoor: ;K urban street. From night time with street >es, Outdoor test: In normal light, darkened and bright
lighting to full sun. evaluation sunlight conditions.
condition Outdoor req: Self-lit keys for night-time use. Shaded display
to avoid glare.

M. MAGUIRE
4.1.5. Environmental instability
None. *

4.2. Workplace design

 CONTEXT OF USE
4.2.1. Space and furniture
Indoor and outdoor: A¹M mounted 1m. above ground, >es, control Indoor and outdoor test: 1 m above ground level.
inset in wall sometimes with small ledge below.

4.2.2 User posture

Indoor and outdoor: Standing. =heelchair users sitting. >es, control Indoor and outdoor req: ¹o have two machines, one for
standing and one for wheelchair use.
Indoor and outdoor test: Include standing and
wheelchair users.

4.2.3. Location
Indoor: Inside bank building. No
Outdoor: Street, public thoroughfares. >es, real or Outdoor test: ¹est outside if possible. Otherwise set up
control lab simulating environmental conditions.

4.3. Health and safety

4.3.1. Health hazards

None 2

4.3.2. Protective clothing and equipment

Indoor and outdoor: =inter clothing would include gloves, >es, evaluation Indoor and outdoor test: Include a test with users
mittens etc. condition wearing gloves.

477
 TABLE 11

478
Organizational environment description

Context of Use A4ects User requirements or

usability? test conditions

5. ORGANIZATIONAL ENVIRONMENT
5.1. Structure

5.1.1. Group working

Single user or small group. May be parent with children. >es, control ¹est: Evaluation based on single users.

5.1.2. Work practice

Not relevant.

5.1.3. Assistance
Possibly available from bank sta+ or member of public >es, control ¹est: No assistance.
in queue.

5.1.4. Interruptions
;sually none. No

5.1.5. Management structure

Not relevant.

5.1.6. Communications
structure
Not relevant.

5.1.7. Salary or payment

Not relevant.

5.2. Attitudes and culture

M. MAGUIRE
5.2.1. IT Policy
All bank branches to have own A¹M and to encourage No
usage to reduce sta+ time on routine transactions.
 CONTEXT OF USE
5.2.2. Organizational aims
Not relevant. 2

5.2.3. Industrial relations

Not relevant. 2

5.3. Job design/user control

5.3.1. Job functions

Not relevant. 2

5.3.2. Hours of work

Not relevant. 2

5.3.3. Job 6exibility

Not relevant. 2

5.3.4. Performance monitoring

PINS monitored, for security, together with response No
speeds and number of transactions per day.

5.3.5. Performance feedback

Receipt of money and receipt. >es, control ¹est: Money and receipt will always be given (i.e. no
simulation of money or paper running out).

5.3.6. Pacing
Queue pressure during busy periods. >es, control
or ignore ¹est: Possibly simulate queue or limited time to complete
tasks. However, bank may implement machines in cubicles
where e+ect of queue is reduced.

5.3.7. Autonomy or discretion

May decide to go into branch if user feels unsafe or >es, control ¹est: May be su.cient to test with no queue.
queue is too long. or ignore

479
480 M. MAGUIRE

down on the amount of time and e!ort needed to perform the full Context of Use
analysis. The issue of the e!ort required to perform the method is discussed further in the
following section.

8. Discussion
The Context of Use analysis presented in this paper is a structured method that provides
a number of bene"ts.
E It ensures that all relevant usability variables are considered when specifying or
evaluating a product.
E It provides a basis for developing an evaluation plan that can be replicated.
E It provides a focused approach, and a shared view that fosters group working between
members of the design team involved (including both managers, users, developers and
usability personnel).
E It helps ensure contextual validity of evaluation "ndings.
Although the Context of Use work on the MUSiC project focused on helping to
specify the evaluation of a user system, a Context of Use analysis can also be used to help
generate user requirements as demonstrated within Tables 6}11 above. However,
Context of Use is only part of the user requirements analysis process; other
aspects such as improving current processes, user cost}bene"t analysis and the develop-
ment of an acceptable design concept may also be part of the process of establishing
user requirements, as described for example by the RESPECT framework (Maguire,
1998).
The issue of reconciling technical and business requirements with user requirements
remains. For example, in the ATM machine illustration, putting an interactive tutorial
on the machine might increase individual transaction time and lead to longer queuing
times, something the banks are anxious to avoid. The requirements process will also need
to include a list of technical or business constraints or requirements that impact on the
user, such as the need to maintain a certain level of customer throughput for bank
machines. This may lead to the development of a new user requirement, i.e. to provide
special bank terminals for training purposes or for more complex transactions that can
be used for longer periods.
The advantage of applying Context of Use analysis throughout the design lifecycle is
that it forms a complementary method for both user requirements speci"cation early on
and user-based testing at later stages. If, for example, a contextual factor at the require-
ments stage is &&user has impaired motor control'', this may lead to the proposed
requirement for a speech-based user interface. Prototyping with potential users (also
speci"ed by the Context of Use) will show whether the use of speech with the chosen
recognition system is feasible. The same Context of Use description can later be used for
more formal user testing to see whether the system can be used successfully for real tasks
in the intended operational environment.
Are there any disadvantages? The reader may feel that the method is too heavyweight
and will require the generation of lots of paperwork by several people. This is fair
comment. In fact, those who are most likely to "nd the Context of Use analysis approach
useful, in this documented form, are those who have never performed this type of analysis
CONTEXT OF USE 481

before. For experienced usability personnel, they may prefer not to complete the Context
of Use forms in the detail shown previously but may wish to use them as a checklist to
identify the main stakeholders and the contextual factors. However, they should, of
course, still document the context of measurement so that others may run similar tests in
future if required.
Another possible criticism is that the headings for user characteristics and environ-
mental characteristics re#ect "xed and more complex contexts such as a process plant,
a large o$ce or command and control centre. Again, there is some truth in this and
arguably there is a greater range of contextual factors that will a!ect these situations
which therefore must be considered. However, for smaller or simpler systems it is still
important to consider the context of use when analysing user requirements and specify-
ing the usability evaluation plan. But the analyst may "nd it helpful to simplify the list of
Context of Use components shown in Table 2 at the start to meet their speci"c situation.
They may also wish to add components that represent the environment they are working
in. For telematic systems in a car (e.g. for vehicle navigation, tra$c information or
driving assistance), it may be important to have context headings for: other passengers,
type of road, tra$c conditions, etc.
Another question is how the Context of Use should be addressed in a more dynamic
development environment through a series of prototypes, where the requirements,
expectations and perceived opportunities are evolving all the time. It is recommended
that a lightweight Context of Use description document is maintained throughout this
process to show the background against which the prototype is being developed. This
will be helpful to ensure that the evolving prototype does not become isolated from the
real situation in which the "nished system will be employed.
In summary, the Context of Use analysis method presented in this paper should be
seen as a means of supporting the user-centred design process and not inhibiting it. It
may be followed in a step-by-step fashion as described or it may be used as an aide
memoir for experienced usability professionals to help them make sure they avoid
forgetting about major contextual factors in the design process.

9. Conclusion
This paper has argued that the usability of a system or product depends on its Context of
Use, so context analysis is an essential pre-requisite for any work on usability. An
understanding of the Context of Use forms a useful input to the process of specifying
usability requirements, constructing a design prototype which can be evaluated and
evaluating the prototype with typical end-users.

The author is grateful to his colleagues who were co-developers of Context of Use concepts and
methods within the ESPRIT MUSiC project. At the HUSAT Research Institute, these
included: Dr Andrew Dillon, Dr Marian Sweeney and Ms Clare Davies. At the National
Physical Laboratory's Usability Department (now Serco Usability Services) they included: Dr
Nigel Bevan, Jonathan Maissel, Ralph Rengger, Miles Macleod, Richard Corcoran and Cathy
Thomas. The author would also like to thank Gordon Allison for inviting him to present the
Context of Use workshop at Human Factors 2000 and to Emeritus Professor Brian Shackel for
encouraging him to write it up as a paper and for his valuable editing role to support its
production.
482 M. MAGUIRE

References
BEVAN, N. & MACLEOD, M. (1994). Usability measurement in context. Behaviour and Information
¹echnology, 13, 132}145.
BROOKE, J. B. (1986). Usability engineering in o$ce product development. In M. D. HARRISON
& A. F. MONK, Eds. People and Computers: Designing for ;sability2Proceedings of the
Second Conference of the BCS HCI Specialist Group, 23}26 September 1986, pp. 249}259.
Cambridge: Cambridge University Press.
BURY, K. F. (1984). The iterative development of usable computer interfaces. In B. SHACKEL, Ed.
Human}Computer Interaction IN¹ERAC¹+84, pp. 343}348. Amsterdam: North-Holland.
CLARK, J. (1992). ¹he Illustrated History of Art. London: Mallard Press.
DERBYSHIRE, D. (1999). Cash machine phobia. Daily Mail, 14 July, p. 31.
EASON, K. D. (1981). A task}tool analysis of the manager}computer interaction. In B. SHACKEL,
Ed. Man}Computer Interaction, pp. 289}307. Amsterdam: Sijtho! and Noordho!.
ISO (1991). ISO 9126: Software product evaluation2quality characteristics and guidelines for their
use. Geneva: International Standards Organisation. Also available from the British Standards
Institute, London.
ISO (1997). ISO 9241-11: Ergonomic requirements for o.ce work with visual display terminals
(<D¹s). Part 11~guidelines for specifying and measuring usability. Geneva: International
Standards Organisation. Also available from the British Standards Institute, London.
ISO (1999). ISO 13407: Human-centred design processes for interactive systems. Geneva:
International Standards Organisation. Also available from the British Standards Institute,
London.
KARAT, C.-M. (1989). Iterative usability testing of a security application. Proceedings of the Human
Factors Society 33rd Annual Meeting, Vol. 1, pp. 273}277, October 16}20. Denver, CO, USA.
Santa Monics, CA: Human Factors & Ergonomics Society.
MAGUIRE, M. C. (1998). ;ser-centred Requirements Handbook. EC Telematics Applications Pro-
gramme, Project TE 2010 RESPECT (Requirements Engineering and Speci"cation in Telem-
atics), WP4 Deliverable D4.2, Version 3.3, May.
MAISSEL, J., DILLON, A., MAGUIRE, M., RENGGER, R. & SWEENEY, M. (1991). Context Guidelines
Handbook. MUSiC Project Deliverable IF2.2.2, National Physical Laboratory, Teddington,
UK.
MILLER, R. B. (1971). Human Ease of ;se Criteria and ¹heir ¹radeo+s. IBM Technical Report No.
TR 00.2185. 12 April, Ploughkeepsie, NY: IBM Corporation.
NEAL, A. S. & SIMON, R. M. (1984). Playback: a method for evaluating the usability of software and
its documentation. IBM Systems Journal, 23, 82}96.
ROSENBAUM, S. (1989). Selecting appropriate subjects for documentation usability testing. In M. J.
SMITH & G. SALVENDY, Eds. =ork with Computers: Organizational, Management, Stress and
Health Aspects, pp. 620}627. Amsterdam: Elsevier.
ROSS, T. & BURNETT, G. (2001). Evaluation of the human}machine interface for complex system
interaction: a case study in vehicle navigation systems. International Journal of Human}
Computer Studies, 55, 661}674. doi:10.1006/ijhc.2001.0495.
SHACKEL, B. (1984). The concept of usability. In J. L. BENNETT, D. CARVER, J. SANDELIN & M.
SMITH, Eds. <isual Display ¹erminals: ;sability Issues and Health Concerns, pp. 45}88.
Englewood Cli!s, NJ: Prentice-Hall.
SHACKEL, B. (1986). Ergonomics in design for usability. In M. D. HARRISON & A. F. MONK, Eds.
People and Computers: Designing for ;sability2Proceedings of the Second Conference of the
BCS HCI Specialist Group, pp. 44}64. 23}26 September. Cambridge: Cambridge University
Press.
SHACKEL, B. (1991). Usability*context, framework, de"nition, design & evaluation. In B.
SHACKEL & S. J. RICHARDSON, Eds. Human Factors for Informatics ;sability, pp. 21}37.
Cambridge: Cambridge University Press.
THOMAS, C. & BEVAN, N. (1995). ;sability Context Analysis: a Practical Guide. National Physical
Laboratory, Teddington, Middlesex, TW11 0LW, UK. (Now available from N. Bevan, Serco
Usability Services, 22 Hand Court, London WC1V 6JF).
CONTEXT OF USE 483

TAYLOR, B. (1990). The HUFIT planning, analysis and speci"cation toolset. In D. DIAPER, G.
COCKTON, D. GILMORE & B. SHACKEL, Eds. Human}Computer Interaction2IN¹ER-
AC¹+90, pp. 371}376. Amsterdam: North-Holland.
WHITESIDE, J., BENNETT, J. & HOLTZBLATT, K. (1988). Usability engineering: our experience and
evolution. In M. HELANDER, Ed. Handbook of Human}Computer Interaction, pp. 791}817.
Amsterdam: Elsevier.
WOLF, C. G. (panel organizer) (1989). The role of laboratory experiments in HCI: help, hindrance
or Ho-hum? (Panel session). Proceedings of CHI+89 conference, pp. 265}268. Austin, TX, 30
April}4 May 1989. New York: ACM.