user centred design and pact analysis

8/11/2019 User Centred Design and Pact Analysis

1/18

User Centred Design

Gould and Lewis 1975

Early focus on users and tasks

Empirical measurement

Iterative design


2/18

User Centred Design Principles

Users tasks and goals are driving force behind

development

Users behaviour and context of use are studied and

the system is designed to support them

Users characteristics are captured and designed for

Users are consulted throughout the development and

their input taken into account

All design decisions are taken within the context of

the users, their work and the environment

(Preece et al 2002)


3/18

User needs analysis/PACT

User characterisation orStakeholder

analysis

Primary users

Secondary users

Task analysis/description

Context Analysis

aka Environment Analysis


4/18

Who are the Users ?

People who interact directly with the product to achieve a

task?Primary Users

Those likely to be frequent hands-on user of the system

Secondary Users

Occasional users or those who use the system through anintermediary

Tertiary Users

Those affected by the introduction of the system or who willinfluence its purchase

Facilitating Users

Those who are involved with design, development and maintenanceof the system.


5/18

User Characterisation

user characteristics physical abilities and skills

general abilities

knowledge computer familiarity

naive

novice

skilled

expert

frequency of use casual


6/18

Task description

Who?

What?

Where?

When?

How often?

Task dependencies


7/18

Task analysis

goal, device, tasks, sub-tasks, actions

Edit letter Print letter

Enter text Amend ......

...... ......

Move cursor

TASKSGOAL

Produce a letter

Selecting a device

determines the tasks

DEVICE

(Preece et al, p412)


8/18

Goals, tasks, actions :

terminology

Goal = external task, such as producing a letter

Device = method, tool, or technique appropriate forachieving goals

Tasks = activities necessary to achive goals using adevice

Subtasks = components of tasks

Actions = simple tasks w/ no control structureMethod = plan = number of tasks or actions linked

into a sequence


9/18

Diagrammatic HTA


10/18

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


11/18

Refined HTA for making tea


12/18

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


13/18

Environment analysis

Physical environment location of activity

physical objects heat, light, noise etc

Social and Organisational context location of people

communication

interruptions


14/18

Technology

New/old computers

Fast/slow network connections

Large/small screens

Desktop/portable/pervasive/wearable


15/18

Interaction Design

Identifying needs and establishing

requirements Developing alternative designs

Building interactive versions of designs

Evaluating designs


16/18

Standards and Guidelines

Principles

strive for consistency

Rules adopt a consistent format for the location of

various display features from one display to

another

House styles

Standards and directives


17/18

Prototyping

Low fidelity

High fidelity

Horizontal

Vertical

Throw away

Evolutionary


18/18

Premises:

The system should be designed to

match user requirements - people

should not have to change to fit in withthe system

People should be able to concentrate

on their activities rather than on how touse the system

user centred design and pact analysis

Documents