Exam 1

1
Exam 1

• Feb 19.
• Practice exam will be posted next week

2
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

3
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

4
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?

5
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)

6
What, how and why?

• What
• Two aims
• 1. Understand as much as possible about users,
  task, context
• 2. Produce a stable set of requirements
• How
• Data gathering activities
• Data analysis activities
• Expression as requirements
• All of this is iterative

7
What, how and why?

• Why
• Requirements definition the stage where failure
  occurs most commonly

Getting requirements right is crucial
8
What, how and why?

• Why
• Requirements definition the stage where failure
  occurs most commonly

Getting requirements right is crucial
9
Establishing requirements

• What do users want? What do users need?
• Requirements need clarification, refinement,
  completion, re-scoping
• Input requirements document (maybe)
• Output stable requirements
• Why establish?
• Requirements arise from understanding users
  needs
• Requirements can be justified related to data

10
Different kinds of requirements

• Functional
• What the system should do
• Historically the main focus of requirements
  activities
• (Non-functional memory size, response
  time...)
• Data
• What kinds of data need to be stored?
• How will they be stored (e.g. database)?

11
Different kinds of requirements

• Environment or context of use
• physical dusty? noisy? vibration? light? heat?
  humidity? . (e.g. OMS insects, ATM)
• social sharing of files, of displays, in paper,
  across great distances, work individually,
  privacy for clients
• organisational hierarchy, IT departments
  attitude and remit, user support, communications
  structure and infrastructure, availability of
  training

12
An extreme example
13
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

14
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

15
Data gathering for requirements

• Interviews
• Props, e.g. sample scenarios of use,
  prototypes, can be used in interviews
• Good for exploring issues
• But are time consuming and may be infeasible
  to visit everyone
• Focus groups
• Group interviews
• Good at gaining a consensus view and/or
  highlighting areas of conflict
• But can be dominated by individuals

16
Data gathering for requirements

• Questionnaires
• Often used in conjunction with other
  techniques
• Can give quantitative or qualitative data
• Good for answering specific questions from a
  large, dispersed group of people
• Researching similar products
• Good for prompting requirements

17
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

18
Data gathering for requirements

• Studying documentation
• Procedures and rules are often written down in
  manuals
• Good source of data about the steps involved
  in an activity, and any regulations governing
  a task
• Not to be used in isolation
• Good for understanding legislation, and
  getting background information
• No stakeholder time, which is a limiting
  factor on the other techniques

19
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

20
Problems with data gathering (1)

• Identifying and involving stakeholdersusers,
  managers, developers, customer reps?, union
  reps?, shareholders?
• Involving stakeholders workshops, interviews,
  workplace studies, co-opt stakeholders onto the
  development team
• Real users, not managerstraditionally a
  problem in software engineering, but better now

21
Problems with data gathering (2)

• Requirements management version control,
  ownership
• Communication between parties
• within development team
• with customer/user
• between users different parts of an organisation
  use different terminology
• Domain knowledge distributed and implicit
• difficult to dig up and understand
• knowledge articulation how do you walk?
• Availability of key people

22
Problems with data gathering (3)

• Political problems within the organisation
• Dominance of certain stakeholders
• Economic and business environment changes
• Balancing functional and usability demands

23
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

24
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 youd really like
• Consider carefully how to record the data

25
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

26
Research questions

• What problems are people encountering with their
  current ways of doing what the product hopes to
  do?
• Into what broader contexts in peoples lives does
  the product fit and how?
• What are the basic goals people have in using the
  product, and what basic tasks help people
  accomplish them.

27
Frank McDonoughSenior programmerUnited 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.
28
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.
29
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."
30
Mark NardoneManager of IT1-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.
31
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.
32
In the word of Yogi Beara
You can observe a lot just by watching
33
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

34
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.

35
Wrong way to use personas
36
Right way to use personas
37
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

38
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

39
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

40
Scenarios organize personas and goals

• Stories which detail how a typical user would use
  your interface
• Scenarios are powerful tools in the design
  process. They force you to think the way users
  act - not rationally, but impulsively and
  emotionally.
• Dont put too many details about the interface
  technology, but focus on personality and goals of
  the users.

41
"Wile E. Coyote just used up his last anvil in an
attempt to hunt a road runner in the middle of
the desert. Leading a nomadic lifestyle, he
enjoys using the Web to purchase from Acme, as he
can do it any time and from anywhere Wile stops
into a cybercafe and calls up the Acme Products
site to order new supplies. He doesn't see what
he wants on the home page, but there's a text box
available for him to enter a search, so he types
in 'anvil'..."
42
John Clark is a student at NMSU and wants to make
sure he gets some good classes next semester so
he wants to register on-line as soon as he is
able. He is a Psychology major and a mid-year
Sophomore so he knows there are some requirements
he must have like PSY 310, but he doesnt think
he needs to take them next semester. He really
wants to take a tennis class for one of his PE
requirements and since he will be taking it in
the spring, knows that it will be really cold in
the morning at the beginning of the semester but
really hot in the afternoon at the end of the
semester so he would like a mid-day class.
43
Task descriptions

• Scenarios
• an informal narrative story, simple, natural,
  personal, not generalisable
• Use cases
• assume interaction with a system
• assume detailed understanding of the interaction
• Essential use cases
• abstract away from the details
• does not have the same assumptions as use cases

44
Scenario for holiday planner
The Thomson family enjoy outdoor activity
holidays and want to try their hand at sailing
this year. There are four members of the family
Sky who is 10 years old, Eamonn who is 15 years
old, Claire who is 35, and Will who is 40. While
out on a shopping trip they call by at the travel
agents in their local town to start exploring the
possibilities ... The travel organizer is located
in a quiet corner of the agents office, where
there are comfortable seats and play things for
young children. They all gather around the
organizer and enter their initial set of
requirementsa sailing holiday for four novices.
The stand-alone console is designed so that all
members of the family can interact easily and
comfortably with it. The systems initial
suggestion is that they should consider a
flotilla holiday, where several novice crews go
sailing together and provide mutual support for
first-time sailors
45
Use case for holiday planner
1. The system displays options for investigating
visa and vaccination requirements. 2. The user
chooses the option to find out about visa
requirements. 3. The system prompts user for the
name of the destination country. 4. The user
enters the countrys name. 5. The system checks
that the country is valid. 6. The system prompts
the user for her nationality. 7. The user enters
her nationality. 8. The system checks the visa
requirements of the entered country for a
passport holder of her nationality. 9. The system
displays the visa requirements. 10. The system
displays the option to print out the visa
requirements. 11. The user chooses to print the
requirements.
46
Alternative courses for holiday planner
Some alternative courses 6. If the country name
is invalid 6.1 The system displays an error
message. 6.2 The system returns to step 3. 8. If
the nationality is invalid 8.1 The system
displays an error message. 8.2 The system returns
to step 6. 9. If no information about visa
requirements is found 9.1 The system displays a
suitable message. 9.2 The system returns to step
1.
47
Example use case diagram for holiday planner
48
Example essential use case for holiday planner
retrieveVisa USER INTENTION SYSTEM
RESPONSIBILITYfind visa requirements re
quest destination and nationalitysupply required
information obtain appropriate visa
infoobtain copy of visa info offer info in
different formatschoose suitable
format provide info in chosen format
49
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)

50
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

51
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
52
Example Hierarchical Task Analysis (plans)
plan 0 do 1-3-4. If book isnt 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.
53
Example Hierarchical Task Analysis (graphical)
Borrow a book from the library
0
plan 0 do 1-3-4. If book isnt on the shelf
expected, do 2-3-4.
go to the library
find required book
retrieve book from shelf
take book to counter
3
2
1
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 search screen
enter search criteria
identify required book
access catalog
note location
2.1
2.2
2.3
2.4
2.5
54
Summary

• Getting requirements right is crucial
• There are different kinds of requirement, each is
  significant for interaction design
• The most commonly-used techniques for data
  gathering are questionnaires, interviews, focus
  groups, direct observation, studying
  documentation and researching similar products
• Scenarios, use cases and essential use cases can
  be used to articulate existing and envisioned
  work practices.
• Task analysis techniques such as HTA help to
  investigate existing systems and practices

55
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.

56
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

57
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

58
Detail task list for e-mail program

• Write and send a message to ogden_at_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.

59
Example task analysis

• Buy An Anvil
• Find The Anvil
• Search For Anvil
• Type in "anvil" in Search box
• Read results
• Browse the Store
• View anvil
• Purchase The Anvil

60
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

61
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)

62
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?