Lecture5

The process of
interaction design
 Overview
• What is involved in Interaction
Design?
– Importance of involving users
– Degrees of user involvement
– What is a user-centered approach?
– Four basic activities

• Some practical issues

– Who are the users?
– What are ‘needs’?
– Where do alternatives come from?
– How do you choose among alternatives?
 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,
and 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

 What is a user-centered
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 analysed
– Iterative design: when problems are found in user
testing, fix them and carry out more tests
 A simple interaction design
lifecycle model

Exemplifies a user-centered design approach ISO -13407

Four basic activities in UCD
Interaction Design

1. Establishing requirements

2. Designing alternatives

3. Prototyping

4. Evaluating
 Some practical issues
• Who are the users?
• What do we mean by ‘needs’?
• How to generate alternatives
• How to choose among alternatives
• How to integrate interaction design
activities with other models?
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 competitor’s products
• Three categories of user (Eason, 1987):
– primary: frequent hands-on
– secondary: occasional or via someone else
– tertiary: affected by its introduction, or will
influence its purchase
– Facilitating: involved in development or
deployment of system
 who are the stakeholders?
Example: Classifying stakeholders – an airline booking
system
An international airline is considering introducing a new
booking system for use by associated travel agents to sell
flights directly to the public.
Primary stakeholders: travel agency staff, airline booking
staff
Secondary stakeholders: customers, airline management
Tertiary stakeholders: competitors, civil aviation
authorities, customers’ travelling companions, airline
shareholders
Facilitating stakeholders: design team, IT department
staff
 Who are the stakeholders?
Check-out operators

• Suppliers
• Local shop
owners

Customers
Managers and owners
What do we mean by ‘needs’?
• Users rarely know what is possible
• Users can’t 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
Identifying needs
and establishing
requirements
 Representation of
User Needs
• Requirements
• Personas
• Task descriptions:
•Scenarios
•Use Cases
•Essential use cases

• Task analysis:
•Hierarchical Task Analysis
Requirements: What, how
• What
and why?
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
 What, how and why?

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

Getting requirements right is crucial

 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
Different kinds of requirements
• Functional:
—What the system should do
• Non-functional:
memory size, response time…
• Data:
—What kinds of data need to be stored?
—How will they be stored?
— (e.g. database)
Different kinds of requirements
Environment or context of use:
— Physical: dusty? noisy? vibration?
light? heat? humidity?
— Social: sharing of files, of displays,
in paper, across great distances, work
individually, privacy for clients
— Organisational: hierarchy, IT
department’s attitude and remit, user
support, communications structure and
infrastructure, availability of training
An extreme 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
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 devices
— height if designing a physical kiosk
— strength - a child’s toy requires little strength to operate,
but greater strength to change batteries
— disabilities (e.g. sight, hearing, dexterity)
Volere shell
Volere requirements
template
 Kinds of requirements
(Activity)
What factors (environmental, user,
usability) would affect the following
systems?
 Self-service filling and payment
system for a petrol (gas) station
 Fashion clothes website
 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
 Persona Template

http://www.agile-ux.com/tag/user-experience/
Personas
 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
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
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
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
 Some examples

Diary and
interview

Cultural
probes
Data gathering for requirements
• Contextual Enquiry:
• 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
 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
Problems with data gathering (3)
• Political problems within the organisation

• Dominance of certain stakeholders

• Economic and business environment

changes

• Balancing functional and usability

demands
 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
Data interpretation and analysis
• Start soon after data gathering session

• Initial interpretation before deeper

analysis

• Different approaches emphasize different

elements e.g. class diagrams for object-
oriented systems, entity-relationship
diagrams for data intensive systems
 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
 Scenarios
• “Scenarios are stories. They are stories
about people and their activities.” (John
M. Carroll) (Carroll, 1999)
• Scenario’s elements(Carroll, 1999):
– Setting: description of the starting
state of the episode and objects that are
involved
– Actors
– Goals
– Actions : things that actors do
– Events: things that happen to actors
 Types of Scenarios
• Scenario types(Rosson & Carroll, 2002; Palotta,
2007):
– Problem scenarios: describe current
situation features (what users can do)
– Activity scenarios: propose transformation
from current practice into new design features
– Information scenarios: how users perceive,
interpret and make sense of information
– Interaction scenarios: physical actions and
system responses that enact and respond to
the users’ task goals and needs
 Scenario for travel organizer
“The Thomson family enjoy outdoor activities and want to try their
hand at sailing this year. There are four family members: Sky (10
years old), Eamonn (15 years old), Claire (35), and Will (40). One
evening after dinner they decide to start exploring the possibilities.
They all gather around the travel organizer and enter their initial set of
requirements – a sailing trip for four novices in the Mediterranean.
The console is designed so that all members of the family can interact
easily and comfortably with it. The system’s initial suggestion is a
flotilla, where several crews (with various levels of experience) sail
together on separate boats. Sky and Eamonn aren’t very happy at the
idea of going on vacation with a group of other people, even though
the Thomsons would have their own boat. The travel organizer shows
them descriptions of flotillas from other children their ages and they
are all very positive, so eventually, everyone agrees to explore flotilla
opportunities. Will confirms this recommendation and asks for detailed
options. As it’s getting late, he asks for the details to be printed so
everyone can consider them tomorrow. The travel organizer prints out
a summary of the different options available.”
 Use case for travel organizer
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 country’s 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.
 Alternative courses for travel
organizer
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.
Example use case diagram for travel organizer
 Example essential use case for travel
organizer
retrieveVisa

USER INTENTION SYSTEM RESPONSIBILITY

find visa requirements
request destination and
nationality
supply required information
obtain appropriate visa info
obtain copy of visa info
offer info in different formats
choose suitable format
provide info in chosen format
 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)
 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 buy a DVD
1. locate DVD
2. add DVD to shopping basket
3. enter payment details
4. complete address
5. confirm order

plan 0: If regular user do 1-2-5.

If new user do 1-2-3-4-5.
Example Hierarchical Task
Analysis (graphical)
 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
Designing Alternatives
 How to generate alternatives

• Humans stick to what they know works

• But considering alternatives is important to
‘break out of the box’
• Designers are trained to consider alternatives,
software people generally are not
• How do you generate alternatives?
—‘Flair and creativity’: research and
synthesis
—Seek inspiration: look at similar products
or look at very different products
 IDEO TechBox
• Library, database, website - all-in-one
• Contains physical gizmos (tools) for inspiration

From: www.ideo.com/
The TechBox
 How to choose among
alternatives
• Evaluation with users or with peers, e.g.
prototypes
• Technical feasibility: some not possible
• Quality thresholds: Usability goals lead to
usability criteria set early on and check regularly
—safety: how safe?
—utility: which functions are superfluous?
—effectiveness: appropriate support? task
coverage, information available
—efficiency: performance measurements
Testing prototypes to choose
among alternatives
 How to integrate interaction
design in other models
• Lifecycle models from other disciplines
• Agile software development promising
– have development and design running in
separate tracks
– maintain a coherent vision of the interface
architecture

http://msdn.microsoft.com/en-us/
magazine/dd882523.aspx
 Summary
Four basic activities in the design process
1. Establishing requirements
2. Designing alternatives
3. Prototyping
4. Evaluating

User-centered design rests on three principles

1. Early focus on users and tasks
2. Empirical measurement using quantifiable &
measurable usability criteria
3. Iterative design
 Prototyping
and Construction
 Overview
• Conceptual design

• Physical design

• Prototyping and construction

• Generating prototypes

• Support for design

 Conceptual design: from
requirements to design
• Transform user requirements/needs into a
conceptual model
• “a description of the proposed system in terms
of a set of integrated ideas and concepts about
what it should do, behave and look like, that
will be understandable by the users in the
manner intended”
• Don’t move to a solution too quickly. Iterate,
iterate, iterate
• Consider alternatives: prototyping helps
Is there a suitable metaphor?
• Interface metaphors combine familiar
knowledge with new knowledge in a way that
will help the user understand the product.
• Three steps: understand functionality, identify
potential problem areas, generate metaphors
• Evaluate metaphors:
How much structure does it provide?
How much is relevant to the problem?
Is it easy to represent?
Will the audience understand it?
How extensible is it?
Considering interaction types
• Which interaction type?
How the user invokes actions
Instructing, conversing, manipulating
or exploring

• Do different interface types provide

insight?
WIMP, shareable, augmented reality,
etc
 Expanding the conceptual model
• What functions will the product perform?
What will the product do and what will the
human do (task allocation)?
• How are the functions related to each other?
Sequential or parallel?
Categorisations, e.g. all actions related to
telephone memory storage
• What information needs to be available?
What data is required to perform the task?
How is this data to be transformed by the
system?
 Using scenarios in conceptual
design
• Used throughout design in various ways
•concrete examples of tasks representing
requirements
•scripts for user evaluation of prototypes
•as a means of co-operation across
professional boundaries
Generate storyboard from
scenario
 Generate card-based
prototype from use case
Prototyping and construction
• What is a prototype?
• Why prototype?
• Different kinds of prototyping
low fidelity
high fidelity
• Compromises in prototyping
vertical
horizontal
• Construction
 What is a prototype?

In other design fields a prototype is a

small-scale model:
• a miniature car
• a miniature building or town

• the example here comes

from a 3D printer
 What is a prototype?
In interaction design it can be (among other things):
• a series of screen sketches
• a storyboard, i.e. a cartoon-like series of scenes
• a Powerpoint slide show
• a video simulating the use of a system
• a lump of wood (e.g. PalmPilot)
• a cardboard mock-up
• a piece of software with limited functionality
written in the target language or in another
language
 Why prototype?
• Evaluation and feedback are central to
interaction design
• Stakeholders can see, hold, interact with a
prototype more easily than a document or a
drawing
• Team members can communicate effectively
• You can test out ideas for yourself
• It encourages reflection: very important aspect
of design
• Prototypes answer questions, and support
designers in choosing between alternatives
Filtering dimensions of
prototyping
Manifestation dimensions of
prototyping
 What to prototype?

• Technical issues

• Work flow, task design

• Screen layouts and information display

• Difficult, controversial, critical areas

 Low-fidelity Prototyping
• Uses a medium which is unlike the
final medium, e.g. paper, cardboard

• Is quick, cheap and easily changed

• Examples:
sketches of screens, task sequences,
etc
‘Post-it’ notes
storyboards
‘Wizard-of-Oz’
 Storyboards
• Often used with scenarios, bringing
more detail, and a chance to role play.
• It is a series of sketches showing how a
user might progress through a task
using the device.
• Used early in design.

Storyboard depicting how to fill a car with gas

 Sketching
• Sketching is important to low-fidelity
prototyping
• Don’t be inhibited about drawing ability.
Practice simple symbols
 Card-based prototypes

• Index cards (3 X 5 inches)

• Each card represents
one screen or part of screen
• Often used in website
development
‘Wizard-of-Oz’ prototyping
• The user thinks they are interacting with a
computer, but a developer is responding to
output rather than the system.
• Usually done early in design to understand
users’ expectations
• What is ‘wrong’ with this approach?

User

>Blurb blurb
>Do this
>Why?
 High-fidelity prototyping
• Uses materials that you would expect to be
in the final product.
• Prototype looks more like the final system
than a low-fidelity version.
• For a high-fidelity software prototype common
environments include Macromedia Director, Visual
Basic, and Smalltalk.
• Danger that users think they have a full
system…….see compromises
 Physical Design
• Paper Prototyping
– "Paper prototyping is a variation of
usability testing where representative
users perform realistic tasks by
interacting with a paper version of the
interface that is manipulated by a
person ‘playing computer,’ who doesn’t
explain how the interface is intended to
work."

http://www.paperprototyping.com/what.html
Paper Prototyping
Compromises in prototyping
•All prototypes involve compromises
•For software-based prototyping maybe there is a
slow response? sketchy icons? limited
functionality?
•Two common types of compromise
• ‘horizontal’: provide a wide range of
functions, but with little detail
• ‘vertical’: provide a lot of detail for only a
few functions
•Compromises in prototypes mustn’t be ignored.
Product needs engineering
 Construction
• Taking the prototypes (or learning from
them) and creating a whole
• Quality must be attended to: usability (of
course), reliability, robustness,
maintainability, integrity, portability,
efficiency, etc
• Product must be engineered
Evolutionary prototyping
‘Throw-away’ prototyping
 Summary
• Different kinds of prototyping are used for different
purposes and at different stages
• Prototypes answer questions, so prototype
appropriately
• Construction: the final product must be engineered
appropriately
• Conceptual design (the first step of design)
• Consider interaction types and interface types to
prompt creativity

• Storyboards can be generated from scenarios

• Card-based prototypes can be generated from use
cases
Evaluation
 The aims
• Explain the key concepts used in evaluation.
• Introduce different evaluation methods.
• Show how different methods are used for
different purposes at different stages of the
design process and in different contexts.
• Show how evaluators mix and modify
methods.
• Discuss the practical challenges
• Illustrate how methods of data gathering
and analysis are used in evaluation and
describe some methods that are specific to
evaluation.
Why, what, where and when to
evaluate
Iterative design & evaluation is a continuous
process that examines:
• Why: to check users’ requirements and that
users can use the product and they like it.
• What: a conceptual model, early prototypes
of a new system and later, more complete
prototypes.
• Where: in natural and laboratory settings.
• When: throughout design; finished products
can be evaluated to collect information to
inform new products.
 Types of evaluation
• Controlled settings involving users
– eg. usability testing & experiments in
laboratories and living labs.
• Natural settings involving users
– eg. field studies to see how the
product is used in the real world.
• Any settings not involving users,
– eg. consultants critique; to predict,
analyze & model aspects of the
interface analytics.
Usability lab

http://iat.ubalt.edu/usability_lab/
 Living labs
• People’s use of technology in their
everyday lives can be evaluated in
living labs.
• Such evaluations are too difficult to
do in a usability lab.
• e.g. the Aware Home was embedded
with a complex network of sensors
and audio/video recording devices
(Abowd et al., 2000).
Usability testing & field studies
can compliment
 Evaluation case studies

• Experiment to investigate a computer

game
• In the wild field study of skiers
• Crowdsourcing
 Challenge & engagement in a
collaborative immersive game
• Physiological measures
were used.
• Players were more
engaged when playing
against another person
than when playing
against a computer.
What does this data tell you?
high values indicate more variation

Playing against Playing against

computer friend
M ean St. Dev. M ean St. Dev.
Boring 2.3 0.949 1.7 0.949
Challenging 3.6 1.08 3.9 0.994
Easy 2.7 0.823 2.5 0.850
Engaging 3.8 0.422 4.3 0.675
Exciting 3.5 0.527 4.1 0.568
Frustrating 2.8 1.14 2.5 0.850
Fun 3.9 0.738 4.6 0.699
Source: M andryk and Inkpen (2004).
 Why study skiers in the wild ?

Jambon et al. (2009) User experience in the wild. In: Proceedings of CHI ’09, ACM Press, New York,
p. 4070-4071.
 e-skiing system components

Jambon et al. (2009) User experience in the wild. In: Proceedings of CHI ’09, ACM Press, New York,
p. 4072.
Crowdsourcing-when might
you use it?
 Evaluation methods
Method Controlled Natural Without
settings settings users

Observing x x

Asking x x
users
Asking x x
experts
Testing x
Modeling x
 The language of evaluation
Analytics In the wild
Analytical evaluation
evaluation Living laboratory
Controlled Predictive evaluation
experiment Summative
Expert review or crit evaluation
Field study Usability laboratory
Formative User studies
evaluation Usability testing
Heuristic evaluation Users or participants
 Key points
 Evaluation & design are closely integrated in
user-centered design.
 Some of the same techniques are used in
evaluation as for establishing requirements but
they are used differently
(e.g. observation interviews & questionnaires).
 Three types of evaluation: laboratory based with
users, in the field with users, studies that do not
involve users
 The main methods are: observing, asking users,
asking experts, user testing, inspection, and
modeling users’ task performance, analytics.
 Dealing with constraints is an important skill for
evaluators to develop.