Chapter

5
Interaction Design and HCI in the Software Process

1
Outline
• Interaction Design
• Process of interaction design
• HCI in software Process

2
Interaction design is about developing
high quality interactive systems and
products that support, enhance, and extend
the way people work, communicate, and
interact

3
 What is
Design?
Achieving goals within constraints:
• Goals : the purpose of the design we are intending to
produce
• who is it for, why do they want it
• Constraints: the limitations on the design process
by external factors
• Like materials, platforms, cost, time, health and
safety
• Trade-offs: choosing which goals or constraints can be
4
relaxed so that others can be met.
golden rule of
design

understand your materials

5
for Human–Computer
Interaction

understand your materials

• understand computers
• limitations, capacities, tools, platforms
• understand people
• psychological, social aspects
• human error
• and their interaction … 6
To err is human
• accident reports ..
• aircrash, industrial accident, hospital mistake
• enquiry … blames … ‘human error’
• but …
• concrete lintel breaks because too much weight
• blame ‘lintel error’ ?
… no – design error
we know how concrete behaves under stress
• human ‘error’ is normal
• we know how users behave under stress
• so design for it! 7

• treat the user at least as well as physical materials!

Central message …

the user
• The core of interaction design: put the user first, keep
the user in the center and remember the user at the end.
8
 Interaction design process

scenarios
task analysis
what is guidelines

wanted principles precise

analysis specification
what is there
vs.
design
what is
dialogue
implement
notations
wanted and
evaluation deploy
prototype
architectures
heuristics documentation
9
help
Steps …
• requirements
• what is there and what is wanted …
• analysis
• ordering and understanding
• design
• what to do and how to decide
• iteration and prototyping
• getting it right … and finding what is really needed!
• implementation and deployment 10
• making it and getting it out there
 Interaction Design Processes

1. Identifying needs and establishing requirements.

2. Developing alternative designs that meet those requirements.
3. Building interactive versions of the designs/prototyping/
4. Evaluating designs

11
 … but how can I do it
all ! !
• limited time  design trade-off

• usability?
• finding problems and fixing them?
 what to fix?
• deciding 
• Which usability problem is worth fixing??

• a perfect system is badly designed

• too good  too much effort in design
12
Interaction Design Cont.
• Three key characteristics of the interaction design
process
• User focus
• Specific usability criteria
• Iteration

13
User Focus
It is the way of identifying your users
• Who are they?
• Probably not like you!
• Talk to them
• Watch them
• Where they are going to use the product
• Kind of activities people are doing while interacting with the
product.
14
Activity 1
• How does making of a phone call differs when using
• A public phone box
• A cell phone?

• How have these devices been designed to take in to account

• The kind of the users
• Type of activities
• Context of use

15
 User focus
Cont.
• Gather as much information as possible about the future users of the
system.
• Stakeholders: people affected directly or indirectly by a system.
• Participatory design: bringing a potential user fully into the design
process
• Persona: rich picture of an imaginary person who represents your
core user group.
• Cultural probes provide a way of gathering information about
people and their activities.
• Use your imagination. 16
persona
• description of an ‘example’ user
• not necessarily a real person
• use as surrogate user
• what would Betty think
• details matter
• makes her ‘real’
17
 example
persona
• Betty is 37 years old,She has been Warehouse
Manager for five years and worked for Simpkins
Brothers Engineering for twelve years. She
didn’t go to university, but has studied in her
evenings for a business diploma. She
has two children aged 15 and 7 and does not like to
work late. She did part of an introductory
in-house computer course some years ago, but it
was interrupted when she was promoted and could
18
no longer afford to take the time. Her
 cultural
probes
• direct observation
• sometimes hard
• in the home
• psychiatric patients, …

• probe packs
• items to prompt responses
• e.g. glass to listen at wall, camera, postcard
• given to people to open in their own environment
they record what is meaningful to them
19
• used to …
• inform interviews, prompt ideas, enculture designers
20
Scenario
s
•are stories for design
Explore the depth
• Explore interaction-
what happens when
• Explore cognition-
what are the users
thinking
• Explore architecture-
what is happening
inside
• scenarios are linear – they represent a single path amongst all
the potential interactions
Scenarios Cont.

Use scenarios to:

• Communicate with others-designers, clients, users
• Validate other models-‘play’ it against other models
• Express dynamics
• Screenshots – appearance
• pictures – behaviour

22
HCI in Software Process

32
 HCI in the software
process
• Software engineering and the design process for interactive
systems

• Usability engineering

• Iterative design and prototyping

• Design rationale

24
the software lifecycle

• Software engineering is the discipline for understanding the

software design process, or life cycle

• Designing for usability occurs at all stages of the life cycle, not as a
single isolated activity

25
The waterfall model
Requirements
specification

Architectural
design

Detailed
design

Coding and
unit
testing
Integration
and
testing
26
Operation and
maintenance
Activities in the life cycle
Requirements specification
designer and customer try capture what the system is expected to provide
can be expressed in natural language or more precise languages, such as a
task analysis would provide

Architectural design
high-level description of how the system will provide the services required
factor system into major components of the system and how they are
interrelated needs to satisfy both functional and nonfunctional requirements

Detailed design
refinement of architectural components and interrelations to identify
27
modules to be implemented separately the refinement is governed by the
nonfunctional requirements
 Verification and validation
Real-world
requirements
and constraints The formality gap

Verification
designing the product right
Validation
designing the right product

The formality gap

validation will
always rely to 28
some extent on
subjective means
of proof
The life cycle for interactive systems
cannot assume a linear
Requirements sequence of activities
specification
as in the waterfall model
Architectural
design

Detailed
design

Coding and
unit
testing
lots of feedback! Integration
and
testing
29
Operation and
maintenance
Usability engineering
The ultimate test of usability based on measurement of user experience

Usability engineering demands that specific usability measures be made explicit as

requirements

Usability specification
• usability attribute/principle
• measuring concept
• measuring method
• now level/ worst case/ planned level/ best case

Problems
• usability specification requires level of detail that may not be
• possible early in design satisfying a usability specification 30
• does not necessarily satisfy usability
part of a usability specification for a VCR

Attribute: Backward recoverability

Measuring concept: Undo an erroneous programming
sequence
Measuring method: Number of explicit user actions
to undo current program
Now level: No current product allows such an undo
Worst case: As many actions as it takes to
program-in mistake
Planned level: A maximum of two explicit user actions
Best case: One explicit cancel action 31
ISO usability standard 9241
adopts traditional usability categories:

• effectiveness
• can you achieve what you want to?
• efficiency
• can you do it without wasting effort?
• satisfaction
• do you enjoy the process?
32
some metrics from ISO 9241
Usability Effectivenes Efficiency Satisfactio
objective s measures n
measures measures
Suitability Percentage of Time to Rating scale
for the task goals achieved complete a task for satisfaction

Appropriate for Number of power Relative efficiency Rating scale for

trained users features used compared with satisfaction with
an expert user power features

Learnability Percentage of Time to learn Rating scale for

functions learned criterion ease of learning

Error tolerance Percentage of Time spent on Rating scale for 33

errors corrected correcting errors error handling
successfully
Iterative design and prototyping
• Iterative design overcomes inherent problems of incomplete requirements

• Prototypes
• simulate or animate some features of intended system
• different types of prototypes
• throw-away
• incremental
• evolutionary

• Management issues
• time
• planning
• non-functional features 34
• contracts
Throw-away Prototyping
The prototype is built and tested. The design knowledge gained from this
exercise is used to build the final product, but the actual prototype is
discarded.

35
 Incremental Prototyping
• The final product is built as separate components, one at a time.
• There is one overall design for the final system, but it is partitioned into independent
and smaller components. The final product is then released as a series of products,
each subsequent release including one more component.

36
 Evolutionary Prototyping
• The prototype is not discarded and serves as the basis for the next iteration of
design. In this case, the actual system is seen as evolving from a very limited initial
version to its final release

37
 Techniques for prototyping
Storyboards
need not be computer-based
can be animated

Limited functionality simulations

some part of system functionality provided by designers
tools like HyperCard are common for these
Wizard of Oz technique

Warning about iterative design

design inertia – early bad decisions stay bad
38
diagnosing real usability problems in prototypes….
…. and not just the symptoms
Design rationale
Design rationale is information that explains why a
computer system is the way it is.

Benefits of design rationale

• communication throughout life cycle
• reuse of design knowledge across products
• enforces design discipline
• presents arguments for design trade-offs
• organizes potentially large design space 39
• capturing contextual information
Design rationale (cont’d)
Types of DR:
• Process-oriented
• preserves order of deliberation and decision-making
• Structure-oriented
• emphasizes post hoc structuring of considered design
alternatives

• Two examples:
• Issue-based information system (IBIS) 40
• Design space analysis
 Issue-based information system (IBIS)
• basis for much of design rationale research
• process-oriented
• main elements:
issues
– hierarchical structure with one ‘root’ issue
positions
– potential resolutions of an issue
arguments
– modify the relationship between positions and issues 41

• gIBIS is a graphical version

 structure of gIBIS
supports
Position Argument
responds to
Issue
responds to
objects to
Position Argument
specializes

Sub-issue generalizes

questions

Sub-issue

Sub-issue 42
Design space analysis
• structure-oriented
• QOC – hierarchical structure:
questions (and sub-questions)
– represent major issues of a design
options
– provide alternative solutions to the
question
criteria
– the means to assess the options in
• DRL(Decision Representation
order to make a choice Language)
– similar to QOC with a
43
larger language and more formal semantics
the QOC notation
Criterion
Option

Question Option Criterion

Option
Criterion

… Consequent …
Question
Question
44
Psychological design rationale
• to support task-artefact cycle in which user tasks
are affected by the systems they use
• aims to make explicit consequences of design for
users
• designers identify tasks system will support
• scenarios are suggested to test task
• users are observed on system
45
• psychological claims of system made explicit
Summary
The software engineering life cycle
• distinct activities and the consequences for interactive system
design
Usability engineering
• making usability measurements explicit as requirements
Iterative design and prototyping
• limited functionality simulations and animations
Design rationale
• recording design knowledge 46
• process vs. structure