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?For police station employer and plaintiff
Goals of our system

-> they need the system to overcome the problem

with time to search , give decision and manage
Achieving goals within constraints: the case .

• Goals : the purpose of the design we are intending to

produce Constraints ;
1. the user no more access the platforms

• who is it for, why do they want it

2.

• 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
6
• and their interaction …
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
wanted implement
notations
and deploy
evaluation
heuristics prototype
architectures
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? 
• deciding what to fix? 
• 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 no longer afford to take the time. Her vision
is perfect, but her right-hand movement is slightly restricted following an
industrial accident 3 years ago. She is enthusiastic about her work and is happy
to delegate responsibility and take suggestions from her staff. However, she
does feel threatened by the introduction of yet another new computer system
(the third in her time at SBE).
18
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
Scenarios
• 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
• easy to understand
• But no alternatives
21
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

33
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

34
The waterfall model
Requirements
specification

Architectural
design

Detailed
design

Coding and
unit testing

Integration
and testing

35
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
36
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 some extent on subjective means of proof
Management and contractual issues 37
design in commercial and legal contexts
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

38
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
39
• possible early in design satisfying a usability specification
• 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 40
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?
41
some metrics from ISO 9241
Usability Effectiveness Efficiency Satisfaction
objective measures 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 42

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 43
• 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.

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

45
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

46
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
47
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 48
• 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) 49

• 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 50

• 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 51
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 order to make a choice

• DRL(Decision Representation Language) – similar to QOC with a

52
larger language and more formal semantics
the QOC notation
Criterion
Option

Question Option Criterion

Option
Criterion

… Consequent …
Question
Question
53
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
• psychological claims of system made explicit
• negative aspects of design can be used to improve next iteration of design
54
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 55
• process vs. structure