PART II : DESIGN PRACTICE

Topic 4a
Requirements : User and Task Analysis
Requirements Gathering
The outcome of any design is judged by how
successful it meets the needs of the product desired
by both users and organisation that commissioned it.
Designer must understand
Clear and detailed knowledge of the users
What users can do with the product  tasks users can
perform using the product
How the product in used in the organisation  the
environment where the product is used
Why Study Users?
Users decide whether to use a product, not designers
or supervisors
Even if dictated by the supervisors, how the product is
used is self-determined.
This is affected by :
Likes and dislikes
Habits and skills
Education and training

 The more we know about users, the better we can

design for them
Understanding Users
We need to discover the answers for the following
questions:
What are the individual characteristics that may
affect their behaviour with the software of information
we design?  preference / problems
What values to they bring to the job? Are they
enthusiastic learners? Do they hope that their
interaction with the interface will be fun, not boring?
Are they interested in saving money, saving time,
becoming expert, having an easy job to do?  attitude,
motivation
Understanding Users
(Continued):
What do they know about the subject matter and the
tools they use today, or the ones we might present in
the new interface?  knowledge, expectations
What is their prior experience using similar tools and
interfaces?
What are their actual jobs and tasks? What reasons do
they have for using the product?  roles,
responsibilities
User Profile
Users have ‘characteristics’ that are relevant to UI
design  user profile
User profile includes:
Age
Gender
Culture
Physical abilities and disabilities
Educational background
Computer/IT experience
Motivation
Attitude
User Profile
 Example of user profile of ATM customers

Age Will range in age from about 12 to 80+. Will be of varying

heights
Gender Both male and female

Physical limitations May be fully able-bodied or may have some physical limitations
in relation to hearing, sight, mobility, use of hands, or
wheelchair use.
Educational May have only minimal education qualifications and possess
background limited literacy and numeracy skills
Computer/IT skills May have little or no prior experience of computer or IT use

Motivation May be very motivated to use the ATM, particularly if they can
do their banking quickly and avoid waiting in long lines at the
bank
Attitude Attitudes to use may vary, depending on the services the ATM
offers, the reliability of the technology itself, and the attitude of
users toward computers
User Profile
 The user profile is translated into UI Requirements, eg.:

Age range from 12 to 80+
May be fully able-bodied or
may have some physical
limitations
May have some physical
limitations in relation to
hearing
May have some physical
limitations in relation to sight
May have some physical
limitations in relation to use of enough to locate
hands
Little or no experience of
computer/IT use
ATM screen height needs to accommodate users of
varying height
ATM screen height needs to accommodate able-bodied
users as well as users with walking sticks or
wheelchairs.
All user inputs should have both visual and auditory
feedback
Screen text should be of a reasonably large font, in
order to be read by both the visually impaired and
unimpaired
Touchscreens, if used, should have target area large
Touchscreens, if used, should be sensitive enough to
respond to users with decreased strength in fingers
The application should be easy to learn and use.
User Profile
Smaller user groups are easier to design for
Different user group use a system differently
The user profile for ATM customers can be broken
into 3 user groups:
Teens / young adults
Young adults to middle age
Middle age to senior citizen
User Profile
 The user characteristics for “teens/young adults”

Age 12 to 25

Gender Both male and female

Physical limitations May be fully able-bodied or may have some physical

limitations in relation to, e.g. hearing or sight. Height
varies.
Educational May have minimal or no educational qualifications
background
Computer/IT use Probably have some prior experience of computer or IT
use
Motivation Probably very motivated to use the ATM, especially in
relation to their banking habits
Attitude Attitudes to use may vary, depending on the services the
ATM offers and the reliability of the technology itself
User Profile
 The user characteristics for “young adults to middle age”

Age 25 to 50
Gender Both male and female
Physical limitations May be fully able-bodied or may have some physical
limitations in relation to, e.g. hearing or sight. Height
varies.
Educational May have only minimal educational qualifications
background
Computer/IT use May have little or no prior experience of computer/IT use

Motivation Could be very motivated to use the ATM, especially if

they can do their banking quickly and avoid standing in
line at the bank
Attitude Attitudes to use may vary, depending on the services the
ATM offers and the reliability of the technology itself
User Profile
 The user characteristics for “middle age to senior citizens”

Age 50 to 80+
Gender Both male and female
Physical limitations May be fully able-bodied or may have some physical
limitations in relation to, e.g. hearing or sight, mobility, or
use of hands. Height varies.
Educational May have only minimal educational qualifications
background
Computer/IT use May have little or no prior experience of computer/IT use

Motivation Could be very motivated to use the ATM, but would

probably prefer to stand in a line in the bank
Attitude Attitudes to use may vary, depending on the services the
ATM offers and the reliability of the technology itself
Persona
Derived from patterns observed during interviews
with and observations of users and potential users
(sometimes customers) of a product
A precise description of a user and what he or she
wishes to do when using a system
Could also be an imaginary example of the real users
Give as specific as possible about the ‘made-up’
details
Serve as a concrete person in the designer’s mind
Persona
Example of persona for the ATM users: the user group
“teens/young adults”

Felix is 13 years old. He gets an allowance every week,

but spends it while out with his friends, and there
usually is not anything left over to bank. He often gets
money from his grandparents and uncles for his birthday
and at Christmas, and this money is always deposited
into his bank account. He saves this for more expensive
or extravagant purchases; for example, he has a game
console and likes to have the newest games. Plus he likes
to be trendy and have the newest jeans and trainers.
Felix’s account allows him to withdraw small amounts of
money from ATMs.
Persona
Example of persona for the ATM users: the user group
“young adults to middle age”

Sandra is 30 years old. She is married to Jason, and they

have two children: Todd, age 6, and Carly, age 18 months.
When Carly was born the family moved into one of the
newly built housing areas in the town; local amenities such
as shops, bars, or a bank have yet to be built. This means
that any shopping or banking must be done in the town
center, which is six-mile round-trip from the family home.
Jason uses the car for work, and he works long hours – he
is often gone from 6:45 am to 8 pm.
Persona
Sandra is partially sighted, so she does not drive and
depends on public transportation to get anywhere. She
tries to do any errands, like shopping and banking, during
Todd’s school hours, as handling one child by public
transportation can be difficult (especially with a stroller),
but it is far easier than trying to cope with two. Sandra
likes the ATM for depositing and withdrawing money and
for checking her balance because she can see the screen if
she gets near enough to it, and she has learned the menu
sequence. The ATM is in the front wall of the bank, and
there is no canopy to protect customers from poor weather
conditions.
Persona
Example of persona for the ATM users: the user group
“middle age to senior citizen”

Grandpa Maurice is 68 years old. His pension is

automatically credited to his bank account once a month.
Every week he goes into the bank to withdraw enough
cash for the week as he prefers to pay for his groceries and
other day-to-day expenses with cash. While standing in
line is a bit difficult (Grandpa Maurice has arthritis in his
hip), he does it because he prefers to get his money from a
person. Also, he is not very comfortable with technology,
he does not have an ATM card.
Why Analyse Tasks?
Each task performed by users aims to accomplish a
certain goal
Goals determine the success of users’ jobs
To ensure a job is successful, the design should
support users to accomplish all the goals of all the
tasks required

 The more we know about the tasks, the better we

can design for them
Task Analysis
Task analysis  the activity system designers use to gain
an understanding of what a computer must do and the
functionality that the system must provide if it is to
support users in their goals and tasks.
Goal  an end result to be achieved
Task  a structured set of related activities that are
undertaken in some sequence
Action  an individual operation or step that
needs to be undertaken as part of the task
Task Analysis
Like users, tasks have ‘characteristics’ that affect UI design :
 The extent to which tasks vary from one occasion to another 
similarity and differences
 Whether tasks will be carried out regularly, infrequently, or only once
 frequency
 The knowledge and kinds of skill required to perform tasks
 How much of the work is affected by changes in the environment
 Whether time is critical for work
 Whether there are safety hazards
 Whether the user will do the work alone or with others  collaboration
 Whether the user will normally be switching between several tasks 
interruption, sequence
Tasks Analysis
To understand the users’ work, need to look at several
levels of detail:
Work-flow analysis  how workers communicate and
how they coordinate their work to get the job done
Job analysis  look at responsibilities of individual
workers and examine what they do in their jobs
Task list and task inventory  what the users have to be
able to accomplish
Process analysis and task sequence  How individual
users do a process / task
Task Hierarchy  levels of tasks and their
compositions
Models of Tasks Analysis
 Models describing steps required to complete a
task
 Scenarios
 Use cases
 Hierarchical Task Analysis (HTA)
Scenarios
Task scenario  a narrative description of a task
Personalised, and describe a specific instance and
situation of use :
Step-by-step procedures to complete a task
Features and behaviour of the system
Problems and difficulties that users may have had with
the current system
Scenarios : Example
Emily Adams has just arrived at Kuala Lumpur airport
en route to a large conference. Looking around for a bank
in order to get some local currency, she sees a foreign
currency exchange ATM that seems similar to the one she
uses at home.
She parks her suitcase, takes out a credit card, and
inserts it into the slot. A message is displayed on the
screen:
Enter your PIN.
Emily thinks for a few moments and then types a four-
digit number on the numerical pad, listening to the
reassuring beep that follows each key press. The machine
pauses for a few seconds and then displays:
Select currency required.
Scenarios : Example
Emily pauses again. What is the currency in Malaysia?
Fortunately the machine offers a default of “Ringgit”, so she
guesses that must be the local currency and presses the key.
The machine displays the message:
Exchange rate is 3.75 Ringgit to one dollar US.
Enter amount required in Ringgit in units of 10.
Press (Proceed).
Emily enters 380 and presses <Proceed>. There is a
whirring noise and a few other indeterminate clunks and
clicks. Her credit card is returned from the card entry slot
and the money is deposited in the delivery slot, along with a
print-out of the transaction.
Exercise 1
Based on your own mobile phone, write a scenario for
storing a contact number of a person who just called
you.
Task Analysis : Use Cases
Use cases can be used
 As part of requirements gathering
 in the design phase
Concrete use case
 similar to task scenario, a detailed description of a
task, but not personalised
Essential use case
 describes a task at a high level of abstraction
 contains no assumptions about the UI or technology
used
Concrete Use Case : Example
User Action System Response
User inserts credit card System requests PIN.
into the slot.
User types in 4-digit PIN System verifies user’s identity.
number using the keypad. System requests foreign currency required, to be
selected using menu keys.
User presses the key System displays the exchange rate.
corresponding to the System requests the user to enter the amount of
required currency. foreign currency required using the keypad.
The unit of currency is also displayed, as the
system only deals with banknotes.
User enters amount System returns the credit card via the slot.
required using the keypad. System dispenses the currency via the currency
delivery slot.
System delivers a printout of the transaction via
the receipt slot.
Essential Use Case : Example
User ‘s Purpose System Responsibility
Identify self. Validate user’s identity.
Display currencies available.
Select currency required. Display exchange rate.
Enter amount of foreign Calculate amount multiplied by
currency required. exchange rate.
Confirm amount. Request initiation of payment.
Obtain authorization for amount.
Give money
Take money and go.
Exercise 2
Based on your own mobile phone, write a concrete
use case for calling a person using the number stored
in your contacts list.
Task Analysis :
Hierarchical Task Analysis (HTA)
Breaks a task down into subtasks and then into sub-
subtasks and so on.
These sub-subtasks are then grouped together as plans
that specify how tasks might be performed in an actual
situation
Focuses on the physical and observable actions that are
performed, and includes looking at actions that are not
related to software or an interaction device at all
HTA

: Example
An HTA for borrowing a book from the library:

0. In order to borrow a book from the library

1. go to the library
2. find the required book
2.1. access library catalog
2.2. access the search system
2.3. enter search criteria
2.4. identify required book
2.5. note location
3. go to correct shelf and retrieve book
4. take book to checkout counter
Plan 0: do 1-3-4. If book isn’t on the shelf expected, do 2-3-4
Plan 2: do 2.1-2.4-2.5. If book not identified do 2.2-2.3-2.4-2.5.
Exercise 4
Write a Hierarchical Task Analysis (HTA) for
registering HCI course at the beginning of semester
using SMP