Task analysis

TASK ANALYSIS

Grau en Enginyeria Informàtica

User Centred Design

Roles tasks

• Roles are only a tiny part of the picture when it comes to the needs and behaviors of users. They tell us, approximately, what kind of activities a user may undertake, but they say nothing about how and when tasks are performed. • So, for example, we may identify an accounting or bookkeeping

role, but we would need to do user research to discover that some tasks are performed many times a day while others are relatively rare. The implications of these differences are significant for interactive systems design.

William Hudson. 2013. User stories don't help users: introducing persona stories.

Interactions 20, 6 (November 2013), 50-53. DOI=10.1145/2517668 http://doi.acm.org/10.1145/2517668

Task Analysis - User Centred Design 2 / 48

http://doi.acm.org/10.1145/2517668

http://doi.acm.org/10.1145/2517668

Task Analysis - User Centred Design

People use computers and computerized equipement to help them carry out tasks, as part of their work or in pursuit of

other goals outside their working life[P. Johnson, Human computer interaction

psychology, task analysis, and software engineering]

Use

of t

ask

mod

els

in th

e de

sign

cyc

leF

abio

Pat

ernò

IST

I-C

.N.R

.

3 / 48

Introduction

• Task analysis is the

• Techniques for task analysis:• decomposition of tasks into subtasks• taxonomic classification of task knowledge• listing things used and actions performed

• Sources of information:• Existing documentation• Observation• Interviews• User profiles

• Using task analysis to design:• Manuals, documentation and New systems


study perform existingenvision will perform non-existing of the way people tasks with systems

4 / 48

Definitions

• Task• Goal• Basic Task• Task Analysis <> Activity analysis • Task Modeling


What is the point of Task Analysis?

• Determine people's jobs:• what people DO• what THINGS they work with• what is the INFORMATION

they know or/and the information they must know for performing their work

• Cover all/most cases

• Cover all/most users


• Example: job of housekeeping

• in order to clean the house• get the vacuum cleaner out • fix the appropriate attachments• clean the rooms• when the dust bag gets full, empty it• put the vacuum cleaner and tools away

• must know about:• Where vacuum cleaners are• Where are their attachments• How to remove the dust bags• Where are the new bags• Evaluate if the rooms are clean or

need to be cleaned• ...

6 / 48

Task analysis & its relationship to idea generation and development


TA

Implementation of first prototype

Test

OK

Modification of prototype

Stop

Y

N

User’s task knowledge Other knowledge

Task Analyst

Software DesignerTask Analyst

User

Idea Generation

Idea Development

Software Expert

7 / 48

Approaches to task analysis

• Task decomposition• splitting task into (ordered) subtasks

• Knowledge based techniques• what the user knows about the task• and how it is organized

• Entity/object based analysis• relationships between objects, actions and the people who perform

them

• Lots of different notations/techniques


Differences from other techniques

Systems analysis vs Task analysis

system design focus on the user

Cognitive models vs Task analysis

internal mental state

focus on external actions

practiced ‘unit’ task focus on whole job

Task analysis of word processing would include activities such as fetching documents from the filling cabinet, changing the printer ribbon ... as well as the interaction with the computer.

Task analysis tends to look more at the observable behaviour of users than their internal mental state.


Engineering task MODELS

• Flexible and expressive notations• Systematic methods able to indicate how to use

information in the task models• Availability of automatic tools to use such information

efficiently

• Why Model-Based approaches?• Highlight important information• Help to manage complexity • Useful to support methods• One important aspect of most development methods• ...


Use of Task Models

• Better understanding of the application (and in particular its use)

• Record discussions (multidisciplinary)• Help design• Help usability evaluation• Help performance evaluation• Help user in performing the tasks (contextual help)• Documentation (content + structure)


Representations of Task Models

• GOMS family• Goals, Operators, Methods, and Selection rules

• UAN• User Action Notation

• K-MADe• Kernel of Model for Activity Description environment

• Hierarchical Task Analysis (HTA)• Ex.: AMBOSS (HTA especially for safety critical systems)• Tool: TaskArchitect (http://taskarchitect.com)

• Concur Task Trees (CTT)• uses LOTOS temporal operators

• Human-centered Assessment and Modeling to Support Task Engineering for Resilient Systems (Hamsters)

What in common?• Different syntax (textual vs

graphical)• Different level of formality• Different set of operators for task

composition

http://www.irit.fr/recherches/ICS/softwares/hamsters

• http://www.w3.org/2012/02/ctt• http://giove.isti.cnr.it/tools/CTTE/home


http://taskarchitect.com/

http://taskarchitect.com/



http://www.w3.org/2012/02/ctt

http://www.w3.org/2012/02/ctt

http://giove.isti.cnr.it/tools/CTTE/home



GOMS (Goals, Operators, Methods, and Selection rules) Example

GOAL: EDIT-MANUSCRIPTGOAL: EDIT-UNIT-Task repeat until no more unit tasks

GOAL: ACQUIRE-UNIT-TASKGET-NEXT-PAGE if at end of manuscriptGET-NEXT-TASK

GOAL: EXECUTE-UNIT-TASKGOAL:LOCATE-LINE

[select: USE-QS-METHODUSE-LF-METHOD]

GOAL: MODIFY-TEXT[select: USE-S-METHOD

USE-M-METHOD]VERIFY-EDIT


Limitations of GOMS

• It does not consider user errors• It does not consider the possibility of interruptions• It considers only sequential tasks• It can be inadequate for distributed applications (such as

web-based applications)


UAN - User Action Notation

• 2 complementary set of information• A hierarchy of tasks LOTOS (similar to CTT)• A table for describing states and feedback

• Textual notation • Introduced in 1992 (Hix & Hartson huge success

Developing user interfaces Ensuring, Usability Through Product & Process)


Example of UAN specification

Task: SelApplication User Action Interface Feedback Interface State ~[x,y in AppICON] (t<tdoubleClick)

w’!: w’-! UnMap(PrevAppliMenu) Map(AppMenu) UnMap(AppICON)

CurAppli=App CurMenu=AppMenu


Task: BuildRequest:((SelR | ClearR | IconifyR)*--> SpecField+)

16 / 48

HTA: Textual description

• Hierarchy description ...0. in order to clean the house

1. get the vacuum cleaner out

2. get the appropriate attachment

3. clean the rooms3.1. clean the hall

3.2. clean the living rooms

3.3. clean the bedrooms

4. empty the dust bag

5. put vacuum cleaner and attachments away

• ... and PLANSPlan 0: do 1 - 2 - 3 - 5 in that order. when the dust bag gets full do 4

Plan 3: do any of 3.1, 3.2 or 3.3 in any order depending on which rooms need cleaning

only the plans denote order


Parse scenario using HTA

0. in order to clean the house 1. get the vacuum cleaner out 2. get the appropriate attachment 3. clean the rooms 3.1. clean the hall 3.2. clean the living rooms 3.3. clean the bedrooms 4. empty the dust bag 5. put vacuum cleaner and attachments away

get out cleanerfix carpet headclean dinning roomclean main bedroomempty dustbagclean sitting roomput cleaner away

1.

2.

3.2.

3.3.

3.2.

3.

4.

5.

0.


HTA. Graphic notation


Diagrammatic HTA


waiting …

• is waiting part of a plan?… or a task?

• generally• task – if ‘busy’ wait

• you are actively waiting

• plan – if end of delay is the event• e.g. “when alarm rings”, “when reply arrives”

• in this example …• perhaps a little redundant …• TA not an exact science


Refining the description

Given initial HTA (textual or diagram)How to check / improve it?

Some heuristics:paired actions e.g., where is 'turn on gas'

restructure e.g., generate task 'make pot'

balance e.g., is 'pour tea' simpler than making pot?

generalise e.g., make one cup ….. or more


Refined HTA for making tea


Types of plan

fixed sequence - 1.1 then 1.2 then 1.3

optional tasks - if the pot is full 2

wait for events - when kettle boils 1.4

cycles - do 5.1 5.2 while there are still empty cups

time-sharing - do 1; at the same time ...

discretionary - do any of 3.1, 3.2 or 3.3 in any order

mixtures - most plans involve several of the above


ConcurTaskTrees

• Focus on Actions and Tasks • Hierarchical Structure• Graphical Syntax• Rich set of temporal operators• Task allocation• Objects and task attributes


Task Models vs Scenarios

• Scenarios are informal descriptions of a specific use in a specific context

• Task models describe the possible activities and their relationships

• Scenarios can support task development• Task models can support scenarios identification


Moving from scenarios to tasks

• Find verbs = tasks• Find words = objects • Find adverbs = temporal relationships


Moving from scenarios to tasks


ConcurTaskTrees Notation

Main features• (very intuitive) Hierarchical structure, has two advantages:

• it provides a large range of granularity allowing large and small task structures to be reused,

• it enables reusable task structures to be defined at both a low and a high semantic level

• Graphical syntax, more easy to interpret, reflecting the logical structure and with a tree-like form

• Concurrent notation, operators for temporal ordering are used to link subtasks at the same abstraction level.

• Focus on activities, it allows designers to concentrate on the most relevant aspects when designing interactive applications


CTT. Node notation


Temporal Operators

• Enabling T1 >> T2 or T1 [ ]>> T2 • Disabling T1 [> T2 • Interruption T1 |> T2• Choice T1 [ ] T2 • Iteration T1* or T1{n} • Concurrency T1 ||| T2 T1 |[]| T2• Concurrency (must finish first) T1 |=| T2 • Optionality [T]


T1 [] T2 Elección. Selección alternativa entre dos tareas. Una vez que se esta realizando una de ellas la otra no esta disponible al menos hasta que termine la que esta activa.

T1 |=| T2 Independiencia de orden. Las acciones de las dos tareas pueden realizarse en cualquier orden.

T1 ||| T2 Entrelazado (concurrencia independiente) Interleaving. Las acciones de las dos tareas concurrentes pueden realizarse en cualquier orden.

T1 |[]| T2 Sincronización (Concurrencia con intercambio de Información). Las dos tareas tiene que sincronizarse en alguna de sus acciones para intercambiar información.

T1 >> T2 Activar (enabling). Cuando termina la T1 se activa la T2. Las dos tareas se realizan de forma secuencial.

T1 []>> T2 Activar con paso de información. Cuando termina T1 genera algún valor que se pasa a T2 antes de ser activada.

T1 [> T2 Desactivación. Cuando se da la primera acción de T2, la tarea T1 se desactiva.

T1* Iteración infinita. La tarea T1 se realiza de forma repetitiva. Se estará realizando hasta que otra tarea la desactive.

[T1] Opcional. No es obligatorio que se realice la tarea. Cuando describimos las subtareas existente en la tarea de rellenar un formulario algunas de las subtareas pueden ser opcionales (las de los campos que sean opcionales).

T1 |> T2 Suspender/Reanudar. Da a T2 la posibilidad de interrumpir T1, y cuando T2 termina se reanuda T1 en el estado en que fue suspendida.

CTT. Relation between nodes




Operators Priority

• Ambiguity in the model

• Ambiguity removed

• Priority: [], |||, [>, >>


Interaction tasksSelection

Edit

Control

…

Application taskOverview

Comparison

Locate

Grouping

...

Tasks types


Inheritance of relationships


Relationships task/subtasks


Optional tasks


Tool Support in CTTE

• Flexible editing of the task model• Using informal descriptions in modelling • Checking completeness of the specification• Saving the specification in various formats• Simulating the task model • Comparing task models• Running scenarios• http://giove.cnuce.cnr.it/ctte.html• http://giove.isti.cnr.it/CTTE/ctteVis.html


Download

CTT tool

40 / 48

http://giove.cnuce.cnr.it/ctte.html

http://giove.isti.cnr.it/CTTE/ctteVis.html

CTT Editor


Task Simulator


User1

User2 User3

Cooperative part

t1t2

t3

t1(User1) t3(User3)

Modelling Multi-User Applications


Cooperative aspects


The task model structure

• Grouping tasks that share the same parent task• Communicating concurrent tasks (|[]|) are presented close

to each other


Supporting enabling operator

• Both sets are shown in the same presentation unit (when they exchange information, []>>)

• The sets are presented at different times• The sets are presented in different presentation unit at the

same time

Jo*

Submit

Name:

Name AgeJohansen 52Jones 27Joxibon 18

Jo*

Submit

Name:

Age:

Name AgeJohansen 52Jones 21

Results:

>20

Results:

Situation 1 Situations 2 and 3


Tasks-interface relationships


Tasks-interface relationships


Documents

Task analysis