HCI 510 : HCI Methods I Context of Use. HCI 510: HCI Methods I Context of Use –Users –Tasks...

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)?


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.


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.


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 - Users

Defining the User

1. Assign a unique name to this kind of user

2. User category nameSome 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 RoleDirect user, Indirect user, Supporting user, Monitoring user, Other.


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


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


Defining the User

7. User Job Characteristics

• Job Function (title)• Job History• Hours of Work / Operation• Job Flexibility• Work Autonomy






Context of Use - Tasks

Defining the Task

1. Assign a unique name to this task

2. Task ObjectiveExplain 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


Defining the Task

4. Task Flow

• Task input / starting condition• Task output / finishing condition• Task side effects• Task dependencies• Linked tasks• Task Postponement


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






Defining the Environment

1. Assign a unique name to this environment

2. Social Environment

• Multi / single user environment• Assistance available (eg help desk)• Interruptions



3. Organisational Environment

• Policy• Aims• Culture• Procedures • Mode of communication• User monitoring in progress• Feedback on job given



4. Technical Environment

• Standalone / networked• (Supporting) software required• Hardware required• Additional hardware / software resources required• Type of network connection required



5. Physical Environment

• Standard Office, • Laboratory or training class, • Home / Informal, • Other.



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



Lets have a go ….


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.

http://www.youtube.com/watch?v=-njbSZWPTyo&feature=player_embedded



• Task Analysis– Hierarchical– Cognitive– Activity

http://www.youtube.com/watch?v=1KML29WefLo

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 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.


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 cost-effective 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 - 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.


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.


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.


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.







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.


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 - 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.


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)



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:


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.



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, high-level 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.



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.



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 cognitive-processing 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 – 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 information-processing 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).


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.



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.



Flowcharting has a language of its own.

The following are the generally accepted conventions for flowcharting.




Task Analysis - Software

Task Analysis - Comparison

Date post:	17-Dec-2015
Category:	Documents
Upload:	meagan-fisher
View:	231 times
Download:	0 times

HCI 510 : HCI Methods I Context of Use. HCI 510: HCI Methods I Context of Use –Users –Tasks...

Documents