Human Computer Interaction

User Centered Design & Task Analysis

 PART 1

Introduction to User
Centered Design
 Outline
Some Everyday Design Examples
Designs that Hinder Users
Designs that Help Users
Why Poor Design Happens
The Process of Interaction Design
What is User-Centered Design?
What is Task Analysis?
What is Personas and Task Scenarios?
Designs
 Designs that Hinder Users
My Stove--A Classic Example

The burners are arranged

in a square
The controls are arranged
in a straight line
It takes mental energy to
select the right control for
the desired burner--and
its easy to make a
mistake
Example drawn from The Design of
Everyday Things by Don Norman
 Designs that Hinder Users
Palm Beach County Ballot Another Example of Poor Mapping

Many voters
associated the
second block of
candidates and
the second hole
in the ballot--
erroneously
voting for the
Reform Party.
Designs that Hinder Users
My Bathtub - The Case of the Missing Shower Control

How do you turn on

the shower?
Few who visit us
figure this out
 Designs that Help Users
Often, good design involves simple changes

Clear mapping between the

item and its control.

Highly visible shower control.

 Designs that Help Users
Dade County Ballot

Clear mapping between candidates and punch hole

 Why does poor design happen?
No designer purposely sets out to confuse or
irritate users

Two factors contribute:

Visual aesthetics trump function
Reliance on interior thinking about a problem
 Aesthetics Trump Function
My Bathtub Faucet

I suspect the designer here

was going for a clean look to
the controls
But, the control is difficult to
discover and hard to grasp with
the water running
 Aesthetics and Function
It is often more work but it is possible to
create products that are both aesthetically
pleasing and easy to use.
 Reliance on Interior Thinking
A common fallacy: the most usable solution is
OBVIOUS by interior thinking about the
problem
If it makes sense to me, it will make sense to
everyone else
This doesnt make sense to me so it wont make
sense to anyone else
Reliance on Interior Thinking
Reference Information for Java

WOW !!!

How do I
navigate this
website?
 But the target audience
loved this approach
Organization was highly meaningful & powerful
It reflects how users think about the information

Packages

Classes
 The Lesson
Relying solely on interior thinking is a risky
approach to design
It risks making incorrect assumptions about
the people who will use a system
 Minimizing Design Risks
The Goal of UCD

The goal of UCD is to create products that are

useful and usable for the intended audience
It is both a philosophy and a process
 Design Factors
Tasks:
Shopping on eBay
Conducting a Video Conference Call
Printing Annual Stock take Reports

Tasks

Environment: Organisational &

Light Social Issues:
Noise Business Cases

Or ocia
&
t
en

ga
S
Indoor Policies
nm

nis l Issu
i ro

ati
Outdoor Security
v

on es
En

al
Weather Design Management

Technology Culture Users

Technology Users:
Portable Device Experts, Novice,
Desktop Computer Culture & Design: Plumbers, Doctors,
Operating System Read Direction of Text Engineers, Artist
Colour
Symbols
Language
 User Interface Design Process
Maintain & Evaluate

Start Test Usability

Evaluate

Observe

Analysis Design

Refine
Explore

Develop
 PART 2

The Process of
Interaction Design
 What is Interaction Design?

Designing interactive products to support the way

people communicate and interact in their everyday
and working lives
[Sharp, Rogers and Preece, 2011]

The design of spaces for human communication and

interaction
[Winograd, 1997]
 Goals of Interaction Design

Develop usable products

Usability means easy to learn, effective to use and
provide an enjoyable experience

Involve users in the design process

 What is involved in Interaction
Design?
It is a process:
a goal-directed problem solving activity informed by
intended use, target domain, materials, cost, and
feasibility
a creative activity
a decision-making activity to balance trade-offs

Four approaches:
user-centered design,
activity-centered design,
systems design
genius design
 Importance of Involving Users

Expectation management
Realistic expectations
No surprises, no disappointments
Timely training
Communication, but no hype

Ownership
Make the users active stakeholders
More likely to forgive or accept problems
Can make a big difference to acceptance and
success of product
 Degrees of User Involvement

Member of the design team

Full time: constant input, but lose touch with users
Part time: patchy input, and very stressful
Short term: inconsistent across project life
Long term: consistent, but lose touch with users

Newsletters and other dissemination devices

Reach wider selection of users
Need communication both ways

User involvement after product is released

Combination of these approaches

 Basic Activities
There are four basic activities in
Interaction Design:
1. Identifying needs and establishing
requirements
2. Developing alternative designs
3. Building interactive versions of the designs
4. Evaluating designs
 A Simple Interaction
Design Model
Exemplifies a user-centered design approach
 Some Practical Issues
Who are the users?
What are needs?
Target Users
 Who are the users/
stakeholders?
Not as obvious as you think:
those who interact directly with the product
those who manage direct users
those who receive output from the product
those who make the purchasing decision
those who use competitors products

Three categories of user (Eason, 1987):

primary: frequent hands-on (direct user)
secondary: occasional or via someone else ( boss )
tertiary: affected by its introduction, or will influence its purchase
 Who are the stakeholders?
Check-out operators

Suppliers
Local shop
owners

Customers
Managers and owners
 What are the users
capabilities?
Humans vary in many dimensions:
size of hands may affect the size and positioning of input
buttons
motor abilities may affect the suitability of certain input
and output device
height if designing a physical kiosk
strength - a childs toy requires little strength to operate,
but greater strength to change batteries
disabilities (e.g. sight, hearing, dexterity)
Users Needs
 What are needs?
Users rarely know what is possible
Users cant tell you what they need to help them achieve
their goals
Instead, look at existing tasks:
their context
what information do they require?
who collaborates to achieve the task?
why is the task achieved the way it is?
Envisioned tasks:
can be rooted in existing behaviour
can be described as future scenarios
 PART 3

User-Centered Design
(UCD)
 What is User-Centered
Design? (1)
An approach to UI development and system
development
Focuses on understanding:
Users, and
Their goals and tasks, and
The environment (physical, organizational, social)
Pay attention to these throughout
development
 What is User-Centered
Design? (2)
Puts users and consideration of user
needs and capabilities at the centre of the
design process
The basic idea
Analyse users and their world
Evaluate ideas, ideally with potential users
Test to be sure design works well with users
and iterate!
 ISO on User-Centered
Design (1)
ISO 13407 describes human-centered design
processes for interactive systems
Principles of human-centered design:
Active involvement of users
Appropriate allocation of function between user
and system
Iteration of design solutions
Multidisciplinary design teams
 ISO on User-Centered
Design (2)
Essential activities in human-centered design:
Understand and specify the context of use
Specify the user and organizational requirements
Produce design solutions (prototypes)
Evaluate designs with users against requirements
 What is a User-Centered
Design approach?
User-centered approach is based on:
Early focus on users and tasks: directly studying
cognitive, behavioral, anthropomorphic &
attitudinal characteristics
Empirical measurement: users reactions and
performance to scenarios, manuals, simulations &
prototypes are observed, recorded and analyzed
Iterative design: when problems are found in user
testing, fix them and carry out more tests
 User-Centered Design Process
Gather information
which impacts the User
Analyze Interface Design
Observations,
Interviews, User Interface Design
Activities, takes place at this stage
User Profiling,
Task & Application Analysis
Design
Interaction Design
Information Design
Visual Design
HTA Evaluate
Usability Testing,
Heuristic Evaluation,
Cognitive Walkthrough,
Plurastic Walkthrough,
Stoaryboard Consistency Inspection,
Protoyping Feature Inspection,
Standards Inspection

Transcript &
Evaluation Report
 User-Centered Design Process
Problem Observation of
statement existing systems

Task analysis HTA

Usability guidelines
& heuristics
Technical & legal etc.
constraints Requirements Requirement statement
Functional
gathering Non-functional

Design and Storyboard

storyboarding

Prototype Prototype
implementation

Evaluation Transcript &

evaluation report

Installation Final
implementation
 Task Analysis
Problem statement
Output
Observation of existing A hierarchical task
systems analysis

Input

Why?
A clear understanding of what clients
want
A clearer understanding of what users
want
 Requirements Gathering

Hierarchical task analysis

Output
Usability principles, etc Requirements statement
Other constraints

Input

Why?
Testable, explicit description of what is wanted
of the system
 Requirements Gathering

What the system should do...

...without worrying too much about how it
does it
An attempt to explicitly describe whats
needed of the new system
Usually where it all goes horribly
wrong...
 Design & Storyboarding
Requirements statement Output
Usability principles, etc.
Other constraints Storyboard design
Evaluation of previous iterations

Input

Why?
Justification why is the system going to be
the way it is?
 Design & Storyboarding

A design of how the system works and

what it looks like
Still not much emphasis on technology
Is this going to be programmed in Java script,
or PERL, or...
Who cares?
Gives the users an idea of the system at
very low cost
 Prototype Implementation
Storyboard design Outputs
Evaluation from previous
iterations (tweaks) Working, testable
prototype

Inputs

Why?
Get something that real users can usefully
test
 Evaluation

Prototype
Outputs
Requirements Transcripts
Evaluation report: are requirements
met? If not, why not?

Inputs

Why?
Tangible evidence of how the system is
actually used
 Evaluation

Outputs
Fully featured prototype
Acceptable evaluation Finished system

Inputs
Other Design Processes (1)
U.S. Department of Health & Human Services.
Other Design Processes (2)
Stamford Interactive Design Process
 Other Design Processes (3)
1
Make it a
priority
7 2
Review Create
Feedbac Persona
k s

3
6
Discover
Launch
Goals

5 4
Diagram from
Test Design Microsoft
TechNet 2007
 Summary
User-centered design places the user,
their goals, needs, activities at the
centre of design process
Involves a re-think of traditional
development processes
Key aspects are evaluation and iteration
 PART 4

Task Analysis
 Objectives

Explain the purpose of task analysis and

modelling
Distinguish between different types of
task analysis
Carry out Hierarchical Task Analysis (HTA)
Explain and show how results of HTA can
be used to improve interaction
 What is task analysis?
Means of analysing and describing the jobs
people do
Method and notation
A method/set of methods for understanding the
tasks users carry out with a product/system
To analyze the underlying rationale and purpose
of what people are doing; what are they trying to
achieve, why are they trying to achieve it, and
how are they going about it?
 Task Analysis
To investigate an existing situation
Can be used for many different purposes
within design and evaluation activities
Focus on
User Analysis involves learning about the user
peoples goals and the actions they carry out
things people know
the things they act on
 What is a Task?
A set of human actions that contributes to a
functional objective and to the goal of the
system.
Scope or size of a task is determined by the
definition of the objectives.
Each task should be approximately equal in
size.
But not always the case
 Task - Decomposition
state of the system that a human
Goal wants to accomplish.

activities required, used, or

Task deemed necessary to achieve a
goal.

steps required to complete the

Actions task.
 Data Collection - Where do
tasks come from?
How can we find out about what people do
this?
Watch them
Talk to them
Read documentation, training material, etc.
Do the task ourselves
Become familiar with existing systems
 Visiting Real Users

Important to analyse real tasks

Not imaginary ones
Not the task of the designer
Contextual enquiries
Genuine studies of what real users do in the
workplace
Task analysis is about gathering and
analysing data
 Task Analysis
What do you learn from task analysis?
Users goals
How the user achieves their goals
Personal, social, and cultural characteristics that influence
the user in doing their tasks
How the physical environment affects them in completing
their tasks
How previous experience knowledge influence their
thinking
how they approach work and the workflow they use to
complete tasks
 Task Analysis
Questions to ask the user:
What are the overall tasks you are trying to achieve?
What process do you follow to complete the task?
What likes and dislikes you have in the way you complete
tasks?

Things to consider:
Does the user efficiently complete the task?
What other ways are their to complete the task?
Is their a more efficient way?
 Task Analysis
How does Task Analysis benefits us?
Determine:
The tasks the system has to support
The scope of the system
Develop a
Streamlined interaction method.
Logical structured user interface
Create a system that reflects
Users goals
Tasks
Workflow
 Task Analysis
Putting it together:
Identify the task to be analyzed.
Break this down into between 4 and 8 subtasks.
Draw the subtasks as a layered diagram
Decide upon the level of detail into which to
decompose.
Validate the analysis with team members
 Issues to Consider

Who are the users?

Diversity
Question people who dont use the system

What do they do?

What do they really do?
Dont give false goals
Observe goals as well as tasks
 Approaches to TA

Several approaches
Focus on goals and actions users carry out
Focus what users know about their work
and tasks
Focus on the objects and entities users act
on
 Task Analysis
Hierarchical task analysis of tea making
 Hierarchical Task Analysis
(HTA)
One of the most common forms of TA
Involves
Identifying goals that user wants to achieve
Decomposing goals into tasks
Further decomposing into subtasks
Repeat; stop at the level of actions
 Hierarchical Task Analysis
(HTA)
HTA is a commonly used means of breaking
tasks down into a hierarchy of goals,
operations (actions) and plans
It involves breaking a task down into subtasks
and then into sub subtasks
These are then grouped together as plans that
specify how the tasks might be performed in
an actual situation
 Hierarchical Task Analysis
(HTA)
Represent the goals, sub goals, operations and
plans using either:
non-graphical methods (e.g. tabulation, outlines,
textual)
graphical views (boxes and arrows)
 HTA Textual Representation
HTA can also be written as a list like this:

0. to clean house
1. get vacuum cleaner
2. clean rooms
2.1 clean hall
2.2 clean living rooms
2.3 clean bedrooms etc
3. empty dust bag
4. put vacuum cleaner away
Plan 0: do 1,2,4
when dust bag full, do 3
Plan 2: do any of 2.1, 2.2, 2.3 in any order depending on which rooms
need cleaning.
HTA Graphical view
 HTA Example (1) :
withdrawing cash from an ATM

Withdrawing cash from an ATM requires

tasks from the user...

What are those tasks?

 Textual Presentation
0 Withdraw cash
1 Check machine will work
1.1 Look at status indicator
1.2 Look for card logo
2 Insert card
3 Enter PIN number
4 Initiate withdrawal transaction
4.1 Select withdraw cash
4.2 Enter amount
5 Complete transaction
5.1 Take card
5.2 Take cash
 Adding Plans
Hierarchical diagram / text specifies what
subtasks are part of a task
Does not specify how the subtasks are
carried out
Plans are used to describe
order of subtasks
conditional or optional subtasks
repetition
etc.
 Plans

A plan needed for each decomposed task

Plan 0: do 1; if possible do 2; repeat 3 until
PIN correctly entered; do 4; do 5.
Plan 1: do 1.1, 1.2 in any order
Plan 4: do 4.1; do 4.2
Plan 5: wait until card available; do 5.1; wait
until cash available; do 1.2
 HTA Example (2)
Microwave Oven
What is the overall goal?
Cook food!

How is this done?

Prepare meal
Put meal in oven
Select programme
Listen for bell to ring
Remove meal
 HTA Example (2)
Microwave Oven
Selecting a programme - How is this done?
Set to auto sensor
Set to defrost
Set timer to cook

What are the rules that influence the order in

which tasks/subtasks take place? (the plans)
HTA Example (2)
Microwave Oven
 HTA Example (3)
Filing documents

The manual task of filing documents in a

filing cabinet...
You have an unsorted stack of documents
Your filing cabinet contains folders that
are ordered somehow
How do you get all the documents into
the correct folder?
 Filing Cabinet
You probably act differently if you have a lot of
documents to file rather than a few...
0. Store documents in filing cabinet
1. File lots of documents
2. File one or two documents

Plan 0: Do 1 or 2
 Filing One or Two Things

Simply find the appropriate folder and put the documents

in...
2. File one or two documents
2.1. Open cabinet
2.2. File each document
2.3. Close cabinet

Plan 2: Do 2.1., (2.2. repeatedly) then 2.3.

 Filing Each Document

2.2. File each document

2.2.1. Find appropriate file
2.2.2. Open file
2.2.3. Place document in file
2.2.4. Close file

Plan 2.2: Do 2.2.1, 2.2.2., 2.2.3., then 2.2.4.

 Filing Lots of Documents

Sort the documents into order first

then split the sorted documents up into
categories (i.e. all the documents whose
author begins with A)
then work through the filing cabinet,
putting each category into the right file
 Filing Lots of Documents

1. File lots of documents

1.1. Choose criteria on which documents are sorted
1.2. Sort all documents to be filed into order
1.3. Split documents up into categories
1.4. Open cabinet
1.5. Place each category of document into file
1.6. Close cabinet

Plan 1: Do 1.1., 1.2., 1.3., 1.4., (1.5. repeatedly) then 1.6.

 Choosing Sorting Criteria

1.1. Choose criteria on which documents are sorted

1.1.1. Choose alphabetical by title of
document
1.1.2. Choose alphabetical by author of
document
1.1.3. Choose date order

Plan 1.1:Do any one of 1.1.1., 1.1.2., or 1.1.3.

 Placing Categories in Files

1.5. Place each category of document into

file
1.5.1. Open file
1.5.2. Place each document in file
1.5.3. Close file

Plan 1.5: Do 1.5.1., (1.5.2. repeatedly) then 1.5.3.

 Things to Note...

The overall task is numbered 0

The tasks are all described by verbs
Each task that is decomposed must have a
plan to go with it
Plan X must only refer to sub-tasks to X
 Things to Think About...

Imagine that you are designing an

electronic filing system...
What does this HTA tell you about filing
systems?
Which bits of the manual task would you
keep, and which would you do away with
or redesign?
Why?
 Activity: Example HTA

Jill creates a stack of new catalogues in a corner of her kitchen.

When she is preparing dinner, she can flip through a catalogue to see
whats new or on sale or what strikes her interest. In the evening she
may pick out five or six catalogues to look at while the family is
watching TV. She may even take a few to bed, or to the bath.
Generally she simply browses through pictures, reading descriptions
only when the pictures look interesting. When she finds something
interesting she may dog-ear the page, draw a circle round it or mark
the page with a sticky note. She keeps catalogues with marked
pictures around until she wants to make a purchase.
 Example

0.Using catalogues
1. Browse items
2. Mark items
 Example

0. Using catalogues
1. Browse items
1.1. Browse by whats new
1.2. Browse by sales
1.3. Browse by items that interest
1.4. Browse by catalogues
1.4.1. Browse in kitchen
1.4.2. Browse while watching TV
1.4.3. Browse in bed
2. Mark items
 Example

0.Using catalogues
1. Browse items
2. Mark items
2.1. Circle item
2.2. Mark page
2.2.1. Dog-ear page
2.2.2. Sticky on page
 Example plans

The source doesnt say much about how

the tasks are done, but
Plan 0: do 1 then 2 if item found
Plan 1: do 1.1 or 1.2 or 1.3 or 1.4
Plan 2: do 2.1 or 2.2
 Example
What does this tell us?
Need flexible system
Need portable system
Need system that allows lots of different
browsing criteria
Possibly need to improve system for marking
selected items
These are passed as requirements to the
design cycle
 Summary

Task analysis gives designers a means of

describing how people do their jobs
Serves different purposes in design and
development
 PART 5

Creating A Persona
 Personas
What is a persona?
A description of a specific fictional person who is
a target user of a system being designed.

Developed from interviews with users

Documented in a brief CV-like document

Developing personas is relatively quick

 Personas
Benefits:
Eases the decision making in the design process
Behavior and goals of the persona are well understood
Helps avoid making assumptions
Ensure the needs of various users are represented
Avoids the trap of designing what users wish to have
rather than what they really need
Designs can be constantly evaluated against the personas
Design disagreements can be resolved by referring to
personas
 Personas
Limitations:
Personas have to be related to a design problem
They can not be re-used for different jobs
Context specificity is essential
Behaviours and goals must be specific to the
domain
Different personas must be created for each
product
 Personas
Creating a persona
Collect background data from your target users
Take primarily tasks, behaviour, goals, attitudes
and environment into account
Add personal and motivational details
Make the personas come to life by including real
photos
Check back with different stakeholders and people
who have regular customer contact
Check them in context with market segments
 Why Are Personas Needed?
Traditionally user-centered design involved researching the
needs of as many users as possible and collecting all of their
requirements. This resulted in a long list of needs with no
sense of priority. This lack of direction typically translated into
designs that tried to serve all users but ended up serving no
user particularly well.

Creating Personas allow you to identify discrete sets of users

and create typical users to represent each group.
 Example of a Personas
Nikki is 50 and works as a Doctor
in the Royal Melbourne Hospital.
She is a specialist in cardiology and
has over 18 years experience in that
field of research. She often uses
a computer tomography or ultrasound
machine. Nikki makes judgments
rationally. She wants the software
that comes with the medical devices to give her results fast and in graphical
format with the opportunity to zoom things to the max. Nikki has a positive
attitude in terms of technology as she has
experienced it as a great support. She is confident using a
computer even though hes not an expert.
 ..from Nikkis Persona Profile

Nikkis goals when using the software, she

wants the software that comes with the medical
devices to give her results fast and in graphical
format with the opportunity to zoom things to the
max.
Example of a Persona
 ..from Bobs Persona Profile
Bobs goals when using the internet
wants to avoid feeling stupid
would like to retain status as mentor
make him more informed when interacting with
customers
 PART 6

Writing A Scenario
 Writing Scenarios

What is a Scenario?
A narrative description that describes how a user
is intending to use a system
Goal or Task-based
Can include textual descriptions, illustrated
stories, animations or even videos
Presents the user's point of view
 Writing Scenarios
Benefits:
Highlights an application within the work context
Powerful communication tool
Useful for testing of early prototypes
Helps users understand the design
Provides a contextual basis for testing
Scenarios test the integrity of requirements and
processes
Gives an idea of current and future needs
 Writing Scenarios
Analyze
Analysis
Claims about
Stakeholders Problem Scenarios current practice
Field Studies

Design
Metaphors, Iterative analysis
information Activity Scenarios
of usability claims
technology, Information Design Scenarios and redesign
HCI theory,
guidelines Interaction Design Scenarios

Prototype & Evaluation Formative

Summative
evaluation Usability Specifications evaluation
 Writing Scenarios
How to write a scenario:
Determine the target group and analyse their
context of use
Transform user goals into activities
Determine the user tasks, and the system tasks.
List in dot point the sequence of tasks
Re-write task list into simple narrative language.
Ensure you omit in your wording, any links to the
technology
Review the scenario to ensure it represents a real
use context.
 Writing Scenarios
How to write a scenario for using the ATM:
Persona: Brad, 45, carefree office worker, travel
often but does not have good time management
User goal: Withdraw money fastly from the ATM
Tasks :
Identify himself
Key in the transaction details
The system responds
Transaction ends
 Example Writing Text-
Based Scenarios
Re-write task list into simple narrative language
It's Thursday afternoon and Brad is flying to Sydney. He doesn't have
enough money for a taxi to the airport, and he's running late. He goes to
the local ATM and identifies himself. He specifies that he wants $200 from
his savings account. He'd like the money in $50 notes so that he can give
the taxi driver the correct change. He doesn't want a printed receipt, as
he doesn't bother keeping track of transactions in this account, besides
hes already late. The system draws out his money, and the transaction
ends.

Ensure you omit in your wording, any links to the technology

Review the scenario to ensure it represents a real use context
 Activity
Create personas and scenarios for your group project
Create one or two personas for each of your user group
Identify roughly 4 functions that your system/application
offers
Based on the functions, create the scenario of how your
persona might use your proposed system/application
Use the same document from your updated project
proposal
 Any
Questions?