9/15/2019
1
PV182
Human Computer Interaction
Lecture 2
Task-Centered System Design
Fotis Liarokapis
liarokap@fi.muni.cz
16th September 2019
The Cheap Shop Catalog Store
In Cheap Shop, people shop by browsing paper
catalogs scattered around the store.
When people see an item they want, they enter
its item code from the catalog onto a form.
People give this form to a clerk, who brings the
item(s) from the back room to the front counter.
People then pay for the items they want. Item code Amount
Screen 1
Screen 2
Cheap Shop Seat-of-your-pants interface design
•Is this a good or bad interface?
– do you go by gut feel?
– do you go by how it looks?
– do you judge it by familiarity to other interfaces?
– if there are problems, are they minor or serious?
– did you miss anything that you really shouldn’t have?
– is your opinion correct?
– how can you tell?
•Alternative: are there methods where you can
– systematically determine if this interface matches the needs of its end
users?
– systematically discover the usability bugs?
Requirements analysis
•A software perspective
– exactly what functions should the system have?
The User
a person who will mould
themselves to fit your system
Mary Franklin
a real person with real
constraints trying to get her
job done
Requirements analysis
•An end-users perspective
– exactly who would use the system to do exactly what?
9/15/2019
2
Task Centered System Design
•An end-users perspective
– exactly who would use the system to do exactly what?
•Phases:
•1. Identification
identify specific users and articulate their concrete tasks
2. Requirements
decide which of these tasks and users the design will support
3. Design
base design representation & dialog sequences on these tasks
4. Walkthrough Evaluations
using your design, walk through these tasks to test the interface
Adapted from Lewis, C. and Rieman, J. (1993) Task-Centered User Interface Design: A Practical Introduction. http://hcibib.org/tcuid/
Foreshadowing…
•Task example 1
– Fred Johnson, who is caring for his demanding toddler son, wants a
good quality umbrella stroller (red is preferred, but blue is
acceptable).
– He browses the catalog and chooses the JPG stroller
(cost $98. item code 323 066 697).
– He pays for it in cash, and uses it immediately.
– Fred is a first-time customer to this store, has little computer
experience, and says he types very slowly with one finger. He lives
nearby on Dear Bottom Avenue NW.
Foreshadowing…
JPG Stroller. This well made but
affordable stroller fits children
between 1-3 years old. Its wheels
roll well in light snow and mud.
…$98.
Red: 323 066 697
Blue: 323 066 698
Foreshadowing…
•Discussion
– Fred has many properties of our typical expected user:
• many customers are first time shoppers,
• a good number have no computer experience
• a good number are poor typists.
– The task type is routine and important.
• many people often purchase only one item
• a good number of those pay by cash
• as with Fred, people often have a general sense of what they want
to buy, but decide on the actual product only after seeing what is
available.
Phase 1: Identify users + tasks
•Get in touch with real people who will be
potential users of your system
• prototypical categories
• extremes
•Learn about their real tasks
– articulate concrete, detailed examples of tasks
they perform or want to perform
that your system should support
• routine
• infrequent but important
• infrequent and incidental
Phase 1: Identify users + tasks
•How do you identify tasks?
Immerse yourself in a real person’s environment
Observe people in their actual work context
Interview people as they do their work
Shadow a person over the course of his or her day
Serve people’s requests
…
9/15/2019
3
Phase 1: Identify users + tasks
•If there are no real users or tasks…
– think again, there probably are!
Jeff Hawkins, the inventor of the Palm Pilot, was said to
have carried a small block of wood around in his shirt pocket … As
various everyday situations arose, he would take out the block of
wood and imagine how he would use the device.
The same technique can be used to evoke a response from expected end-
users
video Tangible Camera
Phase 1: Identify users + tasks
•If all else fails…
– describe your expected set of users,
– describe your expected set of tasks
•These will become your ‘assumed users and
tasks’
– verify them later as information comes in
– modify them as needed
Ph 1: Developing good task examples
1. Says what the user wants to do but does not
say how they would do it
–no assumptions made about the interface
–can be used to compare design alternatives in a fair way
• 2. Are very specific
–says exactly what the user wants to do
–specifies actual items the user would somehow
want to input
Ph 1: Developing good task examples
•3. Describes a complete job
– forces designer to consider how interface features work together
– contrasts how information input / output flows through the dialog
• where does information come from?
• where does it go?
• what has to happen next?
Do not, do not, do not …
• create a list of simple things the system should do
• present a sub-goal independent of other sub-goals
Ph 1: Developing good task examples
•4. Says who the users are
– name names, if possible
– says what they know
– Why?
• design success strongly influenced by what users know
• can go back and ask them questions later
• reflects real interests of real users
• helps you find tasks that illustrate functionality in that person’s
real work context
Ph 1: Developing good task examples
5. Are evaluated
– Circulate descriptions to users, and rewrite if needed
• ask users for
– omissions
– corrections
– clarifications
– suggestions
6. As a set, identifies a broad coverage of users
and task types
– the typical ‘expected’ user, typical routine tasks
– the occasional but important user, infrequent but important tasks
– the unusual user unexpected or odd tasks
9/15/2019
4
Phase 2: Requirements
•Which user types will be addressed by the
interface?
– designs can rarely handle everyone!
– includes why particular users are included / excluded
•Which tasks will be addressed by the interface?
– designs can rarely handle all tasks
– requirements listed in terms of how they address tasks
• Absolutely must include:
• Should include
• Could include:
• Exclude:
– Discussion includes why items are in those categories
Phase 3: Design as Scenarios
•Develop designs to fit users and specific tasks
– ground interfaces in reality
•
Use tasks to
– get specific about possible designs
– consider the real world contexts of real users
– consider how design features work together
•what would the user do / see step-by-step when performing this task?
Phase 4: Walk-through Evaluation
•Good for debugging an interface
•Process
• 1 Select one of the task scenarios
• 2 For each user’s step/action in the task:
a) can you build a believable story that motivates the user’s actions?
b) can you rely on user’s expected knowledge and training about system?
c) if you cannot:
• you’ve located a problem in the interface!
• note the problem, including any comments
• assume it has been repaired
d) go to the next step in the task
The Cheap Shop Catalog Store
In Cheap Shop, people shop by browsing paper
catalogs scattered around the store.
When people see an item they want, they enter
its item code from the catalog onto a form.
People give this form to a clerk, who brings the
item(s) from the back room to the front counter.
People then pay for the items they want. Item code Amount
Developing task examples: Cheap Shop
•Task example 1
– Fred Johnson, who is caring for his demanding toddler son, wants a
good quality umbrella stroller (red is preferred, but blue is
acceptable).
– He browses the catalog and chooses the JPG stroller
(cost $98. item code 323 066 697).
– He pays for it in cash, and uses it immediately.
– Fred is a first-time customer to this store, has little computer
experience, and says he types very slowly with one finger. He lives
nearby on Dear Bottom Avenue NW.
Developing task examples: Cheap Shop
•Discussion
– Fred has many properties of typical expected user:
• many customers are first time shoppers,
• a good number have no computer experience
• a good number are poor typists.
– The task type is routine and important.
• many people often purchase only one item
• a good number of those pay by cash
• people often have a general sense of what they want to buy, but
decide on the actual product only after seeing what is available.
9/15/2019
5
Developing task examples: Cheap Shop
•Task example 2
– Mary Vogel is price-comparing the costs of a child’s bedroom set,
consisting of a wooden desk, a chair, a single bed, a mattress, a
bedspread, and a pillow all made by Furnons Inc.
– She takes the description and total cost away with her to check against
other stores.
– Three hours later, she returns and decides to buy everything but the
chair.
– She pays by credit card,
– She asks for the items to be delivered to her daughter’s home at
31247 Lucinda Drive, in the basement suite at the back of the house.
– Mary is elderly and arthritic.
Developing task examples: Cheap Shop
•Discussion
– Like Mary,
• a reasonable number of store customers are elderly, with
infirmities that inhibit their physical abilities.
• a modest number of them also enjoy comparison shopping,
perhaps because they have more time on their hands or because
they are on low income.
– The task type is less frequent, but still important.
• although this would be considered a ‘major’ purchase in terms of
the total cost, the number of items purchased is not unusual.
• delivery of large items is the norm
• most customers pay by credit card for larger orders.
Developing task examples: Cheap Shop
•Task example 3
– John F, the sole salesperson in the store, is given a list of 10 items by a
customer who does not want to use the computer.
– The items are:
• 4 pine chairs, 1 pine table, 6 blue place mats, 6 “lor” forks, 6 “lor”
table spoons, 6 “lor” teaspoons, 6 “lor” knives, 1 “tot” tricycle, 1 red
ball, 1 “silva” croquet set
– After seeing the total, the customer tells John he will take all but the
silverware
– The customer then decides to add 1 blue ball to the list.
– The customer starts paying by credit card, but then decides to pay cash.
The customer tells John he wants the items delivered to his home the day
after tomorrow. While this is occurring, 6 other customers are waiting for
John.
– John has been on staff for 1 week, and is only partway through his training
program
Developing task examples: Cheap Shop
•Discussion
– This task introduces the clerk as a system user.
• Because of a high turnover in its staff, new employees such as John
are also common.
• Thus John reflects a ‘rare’ but important group of users.
– The task type is less frequent, but still important
• The task is fairly typical i.e., people making large numbers of
purchases often ask the clerk to help them.
• The customers often change their mind partway through a transaction
i.e., by changing what they want to buy and/or by changing how they
want to pay for it.
• Customers, however, rarely give specific delivery dates, with most
wanting delivery as soon as possible.
• Lineups for clerks are common during busy times.
Screen 1
Screen 2
Cheap Shop Specifications
To create an order
• On screen 1, shoppers enter their personal information and their
first order
• text is entered via keyboard
• the tab or mouse is used to go between fields.
Further orders
• shoppers go to the 2nd screen by pressing the Next Catalog Item
button
Order completion
• shoppers select ‘Trigger Invoice’.
• the system automatically tells shipping and billing about the order
• the system returns to a blank screen #1
9/15/2019
6
Specifications
To cancel order
• Shoppers do not enter input for 30 seconds (as if they walk away)
• The system will then clear all screens and return to the main
screen
Input checking
• all input fields checked when either button is pressed.
• erroneous fields will blink for 3 seconds, and will then be cleared.
• the shopper can then re-enter the correct values in those fields.
Walkthrough template
Description of
Step
Does the user have the
knowledge/training to do
this?
Is it believable that they
would do it?
Are they motivated?
Comment / solution
Task number: ____
A walkthrough for this exercise is found in Greenberg, S. “Working through Task-Centered System Design. in Diaper, D. and Stanton, N. (Eds) The Handbook of Task
Analysis for Human-Computer Interaction. Lawrence Erlbaum Associates.
Are there better ways to do it?
•A task-centered prototype
– partial wizard approach to tasks
– prototyped several different ways
• paper - 45 minutes
• scripted animation
- 2 hours
•
Does it work?
– do a task-centered
walkthrough
to find out!
Goal-centered system design
•Articulate user goals instead of task sequences
– Goal:
• a desired end condition
• tend to be stable
– Task:
• an intermediate process needed to achieve the goal
• may change as technology / work patterns change
See Allan Cooper ‘The inmates are running the asylum’, Sams (Macmillan), especially Chapter 9 and 11.
Goal-centered system design
•Designer
– looking for solutions that satisfy these goals
– task sequence may differ substantially from current process
•Approach:
– Develop a persona
• precise, specific description of the user and the goal they wish to
accomplish
• a pretend user that are hypothetical archetypes of actual users
• discovered as a by-product of investigating the problem domain
– Develop a cast of characters
• 3 – 12 unique personas
• one will be the primary persona – the main focus of the design
You know now
•How to develop concrete task examples
•How to use task examples to motivate your
designs
•How to evaluate designs through task-centered
walkthroughs
9/15/2019
7
Articulate:
•who users are
•their key tasks
User and
task
descriptions
Goals:
Methods:
Products:
Brainstorm
designs
Task
centered
system
design
Participatory
design
User-
centered
design
Evaluate
tasks
Psychology of
everyday
things
User
involvement
Representation
& metaphors
low fidelity
prototyping
methods
Throw-away
paper
prototypes
Participatory
interaction
Task
scenario
walk-
through
Refined
designs
Graphical
screen
design
Interface
guidelines
Style
guides
high fidelity
prototyping
methods
Testable
prototypes
Usability
testing
Heuristic
evaluation
Completed
designs
Alpha/beta
systems or
complete
specification
Field
testing
Interface Design and Usability Engineering
Scripted Prototype
Example
9/15/2019
8
Printing…
To recall this order,
scan the bar code on
the printout
Questions
Acknowledgements
• Prof. Ing. Jiří Sochor