• Email to ogden@nmsu.edu
– Names of your group members
– Possible topics
Exam 1 Scores
100
90
82
80
70
63
60
50
40
48
66
86 87 87
84 84 85 85
91 91 92 92
89 89 89 90
96 96 96 97
94 95
100 100 100 100
Vending machines
Describe the
conceptual
model
underlying
the two
vending
machines
Which is
easiest to
use?
The Task-Centered Design Process
• figure out who's going to use the system to do
what
• choose representative tasks for task-centered
design
• plagiarize
• rough out a design
• think about it
• create a mock-up or prototype
• test it with users
• iterate
• build it
• track it
• change it
Getting to Know Users and Their
Tasks
• Customers are often illusory
– Don't get soft on this step or illusions will stay.
• Building to specs doesn't alleviate the need
• Getting in Touch With Users
• Find real people who would be potential
users of what you are going to build.
– watch out for generic and designer users
Homework
• Pick a common task
– Start a car. Microwave some popcorn. Check
out a book in the library. Etc.
• List all the steps necessary to complete
the task
• Watch someone do the task
• Did their behavior match your task
description?
Requirements:
What, how and why?
•What
Two aims:
1. Understand as much as possible
about users, task, context
2. Produce a stable set of
requirements via a set of task
descriptions that focus on users.
• How
•Personas
•Task analysis
What, how and why?
•Why:
Requirements
definition: the
stage where
failure occurs
most commonly
Getting requirements right is crucial
What, how and why?
•Why:
Requirements
definition: the
stage where
failure occurs
most commonly
Getting requirements right is crucial
An extreme environment example
Different kinds of requirements
• Users: Who are they?
— Characteristics: ability, background, attitude to
computers
— System use: novice, expert, casual, frequent
— Novice: step-by-step (prompted), constrained, clear
information
— Expert: flexibility, access/power
— Frequent: short cuts
— Casual/infrequent: clear instructions, e.g. menu paths
You have to get in the users’ head
• Field research
– Watching people doing real things in the real
world: (e.g. online shopping – real world
shopping)
– Watching people use other related software:
(e.g. other online shopping sites)
Persona
• A persona is a fictional person who
represents a major user group for your
product.
• Personas help you identify major user
groups. You select the characteristics that
are most representative of those groups
and turn them into a persona.
Personas
• Capture user characteristics
• Not real people, but synthesised from real
user characteristics
• Should not be idealised
• Bring them to life with a name,
characteristics, goals, personal background
• Develop multiple personas
Data gathering for requirements
Direct observation:
— Gain insights into stakeholders’ tasks
— Good for understanding the nature and
context of the tasks
— But, it requires time and commitment
from a member of the design team, and
it can result in a huge amount of data
Indirect observation:
— Not often used in requirements activity
— Good for logging current tasks
Contextual Inquiry
• An approach to ethnographic study where user is expert,
designer is apprentice
• A form of interview, but
— at users’ workplace (workstation)
— 2 to 3 hours long
• Four main principles:
— Context: see workplace & what happens
— Partnership: user and developer collaborate
— Interpretation: observations interpreted by user and
developer together
— Focus: project focus to understand what to look for
Problems with data gathering (1)
• Identifying and involving stakeholders:
users, managers, developers, customer reps?, union
reps?, shareholders?
• Involving stakeholders: workshops, interviews,
workplace studies, co-opt stakeholders onto the
development team
• ‘Real’ users, not managers:
traditionally a problem in software engineering,
but better now
• Availability of key people
Some basic guidelines
• Focus on identifying the stakeholders’ needs
• Involve all the stakeholder groups
• Involve more than one representative from each
stakeholder group
• Use a combination of data gathering techniques
Some basic guidelines
• Support the process with props such as prototypes and
task descriptions
• Run a pilot session
• You will need to compromise on the data you collect and
the analysis to be done, but before you can make
sensible compromises, you need to know what you’d
really like
• Consider carefully how to record the data
Qualitative research
• Better than quantitative for understanding
human activities.
• Helps us understand the domain context
and constraints of a product (i.e.)
– Existing products and how they are used
– How current users currently approach problems
new products address
– Vocabulary and social aspects
Frank McDonough
Senior programmer
United Parcel Service of America Inc.
During the peak holiday season, UPS encourages its IT
employees to pitch in and help on delivery trucks.
McDonough spent two and a half weeks helping route drivers
deliver packages.
The job:
Inventory, scan and load packages; drive to houses; scan
deliveries; get signatures; download DIAD (a portable delivery
information acquisition device that all UPS route people carry).
Also pick up and deliver lost puppies, help ladies rearrange
living room furniture and provide other assistance as needed.
Lessons learned:
McDonough saw "how crucial the DIAD is to the business,
how important technology is for the drivers and how they
appreciate it and rely on it. It also gave me a great hands-on
view of the services UPS provides and simplified everything
so I could understand all the package and service codes.
"Right now, we're going through a rearchitecture in the
billing apps area. Being on the route has enlightened me to
what it all means, and so I'm better able to think about how
to organize the information and how to report. Instead of
building a monster, I can build a smaller app if I know what
I'm doing."
Mark Nardone
Manager of IT
1-800-Flowers Inc.
Nardone's job is to keep IT aligned with business
objectives by spending most of his time with
businesspeople, often in the retail flower stores. He
passes his insights on to the manager of development in
IT.
The job:
Prepare, cut, arrange, sell and deliver flowers; work with
marketing and other business units.
Lessons learned:
"You get a lot of insights into human behavior selling flowers.
On Valentine's Day, I was taking orders on the phone, and
someone called in ordering for five different women, and the
message for each was, 'You're the only one,' he says. "I
spent 15 years in development. Seeing how it really works
with people gives you a different perspective. Now I'm a
florist first and an IT guy second. I'm excited about what it
can do for our business.
"For example, we were doing craft workshops at the stores,
and we decided during a marketing meeting that we wanted
to let our telephone customers know about that. So I said [to
IT]: 'Guys, this is what we want to do.' Now, when an
associate takes a customer's ZIP code on the phone, [the
system gives him] a prompt on his screen to tell customers if
there's a workshop happening in their area," Nardone says.
In the word of Yogi Beara
You can observe a lot just by watching
inContex
• Example design firm that uses customer
field data in their design process
• http://www.incent.com/cd/cdhow.html
• Interested in:
–
–
–
–
Structure and language used in the work
Individual and group actions and intentions
The culture affecting the work
Explicit and implicit aspects of the work
Personas
Modeling the user
• Archetypal characters created to
represent the needs and goals of the
people for whom the product will be
designed.
• Defining functionality to satisfy the goals
of a real person, rather than an abstract
notion of "the user," enables you to avoid
development roadblocks caused by personal
preferences or biases.
Wrong way to use personas
Right way to use personas
Personas as a user model
• Determines what a product should do and
how it should behave.
• Communicate with stakeholder, developers
and other designers and focus on user
experience with a common language.
• Protects against:
– The elastic user – everyone has a slightly
different idea about who the user is
– Self-referential designs – people designing for
themselves
– Designing for edge cases – keeps unusual cases
in perspective
Personas
• Describe how people behave – not job descriptions.
– Multiple persons w/same job or same person w/multiple
jobs.
• Add life to the personas, but remember they're
design tools first
• Use the right goals
– Life goals (e.g. retire at 50)
• Use rarely
– Experience goals (e.g. avoid feeling stupid)
• Use when specific to the interface product
– End goals ( e.g. find the best price)
• Should be the main focus
•
•
Perfecting your personas
Origin of Personas
Personas
• Are based on research
• Are represented as individuals
– Personifications simplify the user model
• Represent classes of users in context
– Archetypes not stereotypes
• Based on observed behavior not on biased assumptions
• Have motivations
Example of a Persona
USDA Senior Manager Gatekeepers
Matthew Johnson Program Staff Director, USDA
•
Matthew is 51-year-old married father of three children and one
grandchild. He has a Ph.D. in Agricultural Economics who spends his work
time requesting and reviewing research reports, preparing memos and briefs
for agency heads, and supervising staff efforts in food safety and
inspection. He is focused, goal-oriented within a strong leadership role. One
of his concerns is maintaining quality across all output of programs. He is
comfortable using a computer and refers to himself as an intermediate
Internet user. He is connected via a T1 connection at work and dial-up at
home. He uses email extensively and uses the web about 1.5 hours during his
work day. He is most likely heard saying: “Can you get me that staff analysis
by Tuesday?”
Learning About the Users' Tasks
• Develop lists of things the users would like
to do
– Say what the user is doing, not how they do it
– Be specific with details.
– Describe the complete job
• key point because transition between tasks are
covered
– The tasks should say who the users are
Task analysis
• Task descriptions are often used to envision new
systems or devices
• Task analysis is used mainly to investigate an
existing situation
• It is important not to focus on superficial
activities
What are people trying to achieve?
Why are they trying to achieve it?
How are they going about it?
• Many techniques, the most popular is Hierarchical
Task Analysis (HTA)
Task Inventory
• What is a task?
– It has an observable action with a beginning and
end
• What level of granularity?
– Make dinner? or Peel Potatoes?
• Make it a reasonable length
– 7 ± 2 ? Probably 10-20
Partial task list for e-mail program
•
•
•
•
•
•
•
•
•
•
Write a message
Send a message
Receive a message
Read a message that you received
Reply to a message
Save a message to look at it later
Forward a message to someone else
Send a formatted file with the message
Send the same message to several people
Keep an address book
Detail task list for e-mail program
• Write and send a message to
ogden@nmsu.edu about missing class
• Forward the message sent to ogden to
someone else in the class.
• Send the same message to everyone in the
class.
•
•
•
Example
• What overall tasks are users trying to accomplish
at our Web site?
– Trying to find a nursing home near you for an elderly relative.
– Trying to get information about options for treatment for skin
cancer.
– Trying to sign up to receive an email notice when a payment is
due.
• How are users currently doing the task?
– People are completing that task using something other than the
web.
– Users are on our Web site now.
– Users are using another Web site trying to complete the same
or similar tasks.
Hierarchical Task Analysis
• Involves breaking a task down into subtasks, then
sub-sub-tasks and so on. These are grouped as
plans which specify how the tasks might be
performed in practice
• HTA focuses on physical and observable actions,
and includes looking at actions not related to
software or an interaction device
• Start with a user goal which is examined and the
main tasks for achieving it are identified
• Tasks are sub-divided into sub-tasks
Example Hierarchical Task Analysis
0.
In order to borrow a book from the library
1.
go to the library
2.
find the required book
2.1 access library catalogue
2.2 access the search screen
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
Example Hierarchical Task Analysis
(plans)
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.
Example Hierarchical Task
Analysis (graphical)
Borrow a
book from
the library 0
plan 0:
do 1-3-4.
If book isn’t on the shelf expected, do 2-3-4.
go to the
library
1
find required
book
2
retrieve
book from
3
shelf
take book
to counter
4
plan 2:
do 2.1-2.4-2.5.
If book not identified from information available, do 2.2-2.3-2.4-2.5
access
catalog
2.1
access
search
screen 2.2
enter
search
2.3
criteria
identify
required
book2.4
note
location
2.5
Example task analysis
I.
Buy An Anvil
A. Find The Anvil
A. Search For Anvil
A. Type in "anvil" in Search box
A. Read results
B. Browse the Store
C. View anvil
B. Purchase The Anvil
Using the Tasks in Design
• Send task descriptions to the users
• develop a DESIGN SCENARIO for each
task
–
–
–
–
these are design specific
discuss these with the users and designers
gives CONTEX to the discussions.
Represented with STORYBOARDS (sequences
of sketches showing what the screen shows and
actions taken)
Scenarios should
•
•
•
•
Say who the users are – personas
What their goals are
When they are using your interface
What other people, objects they interact
within the same time frame.
Homework
• Pick a common task
– Start a car. Microwave some popcorn.. Etc.
• List all the steps necessary to complete
the task
• Watch someone do the task
• Did what they do match your task
description?