Chapter Four

Interaction Design and

HCI in the Software Process

abrham 1
 Chapter Content

1. Interaction Design (Introduction, What is

design?, User focus, Scenarios, Navigation
design, Screen design and layout,
Interaction and prototyping)
2. HCI in the Software Process (Introduction,
The software lifecycle, Usability
engineering, Interactive design and
prototyping, Design rationale)
abrham 2
 Interaction Design - Introduction (1.1)

Introduction
• design:
– what it is, interventions, goals, constraints
• the design process
– what happens when
• users
– who they are, what they are like …
• scenarios
– rich stories of design
• navigation
– finding your way around a system
• iteration and prototypes
– never get it right first time!

abrham 3
 Interaction Design - What is design ? (1.2)

• Definition
– “achieving goals within constraints”
• Goals - purpose
– who is it for, why do they want it
• Constraints
– materials, platforms
• Trade-offs
– Choosing which goals or constraints can be
relaxed so that others can be met.

abrham 4
Golden rule of Design
• Understand your materials
– understand computers
• limitations, capacities, tools, platforms
– understand people
• psychological, social aspects
• human error
• and their interaction
• The central message – the user
abrham 5
The Process of Design

abrham 6
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
– making it and getting it out there

abrham 7
How can I do it all ?
• Limited time  design trade-off
• Usability?
– finding problems and fixing them?
– deciding what to fix?
• A perfect system is badly designed
– too good  too much effort in design
abrham 8
 Interaction Design – User Focus (1.3)

User focus design - Know your User

• Who are they?
• Probably not like you!
• Talk to them
• Watch them
• Use your imagination
– Persona - description of an ‘example’ user
– Cultural probes - direct observation sometimes
hard

abrham 9
abrham 10
 Interaction Design – Scenarios (1.4)

Scenarios
• Stories for design (rich stories of interaction)
– communicate with others
– validate other models
– understand dynamics

abrham 11
• what will users want to do?
• step-by-step walkthrough
– what can they see (sketches, screen shots)
– what do they do (keyboard, mouse etc.)
– what are they thinking?
• use and reuse throughout design

abrham 12
Explore Depths
• explore interaction
– what happens when
• explore cognition
– what are the users thinking
• explore architecture
– what is happening inside

abrham 13
• Scenarios are a resource that can be used and
reused throughout the design process:
– helping us see what is wanted,
– suggesting how users will deal with the potential
design,
– checking that proposed implementations will
work, and
– generating test cases for final evaluation.

abrham 14
 Interaction Design – Navigation Design (1.5)

Levels of Interaction
• Focusing on the computer system , you
interact at several levels:
– widget choice (menus, buttons etc.)
– screen design
– application navigation design
– environment (other apps, O/S)

abrham 15
abrham 16
Structures
• Local
– looking from this screen out (Within a screen)
• Global
– structure of site, movement between screens
• Wider still
– relationship with other applications

abrham 17
Local
Goal Seeking
goal
start

• try to avoid these bits.

abrham 18
Golden Rule
• There are four things to look for when looking at
a single web page, screen or state of a device.
– knowing where you are
– knowing what you can do
– knowing where you are going
• or what will happen
– knowing where you’ve been
• or what you’ve done

abrham 19
 Where you are – breadcrumbs (shows path
through web site hierarchy)
top level category sub-category
web site this page

live links
to higher
levels
abrham 20
Button Trap

things other things

the thing from

more things
outer space

abrham 21
• lock to prevent accidental use …
– remove lock - ‘c’ + ‘yes’ to confirm
– frequent practiced action
• if lock forgotten
– in pocket ‘yes’ gets pressed
– goes to phone book
– in phone book …
‘c’ – delete entry
‘yes’ – confirm

abrham 22
Global
• between screens within the application
Hierarchical Diagrams

abrham 23
Network Diagrams
• what leads to what
• what happens when
• including branches
• more task oriented then hierarchy

abrham 24
Wider Still
• between applications and beyond
• Style issues:
– platform standards, consistency
• Functional issues
– cut and paste
• Navigation issues
– embedded applications
– links to other apps … the web

abrham 25
Interaction Design – Screen Design and Layout (1.6)

Basic Principles
• Ask
– what is the user doing?
• Think
– what information, comparisons, order
• Design
– form follows function (let the required
interactions drive the layout)
abrham 26
Tools for Layout
–grouping of items
–order of items
–decoration - fonts, boxes etc.
–alignment of items
–white space between items

abrham 27
abrham 28
abrham 29
abrham 30
abrham 31
 Interaction Design – Prototyping (1.7)

• you never get it right first time

• if at first you don’t succeed

OK?

design prototype evaluate

done!

re-design

abrham 32
• There are two things you need in order for
prototyping methods to work:
– To understand what is wrong and how to improve.
– A good start point.

abrham 33
 HCI in the Software Process – Introduction (2.1)

• Within computer science there is already a large

sub discipline that addresses the management
and technical issues of the development of
software systems – called software engineering.
• One of the cornerstones of software engineering
is the software life cycle.
• HCI affecting the usability of interactive systems
are relevant within all the activities of the
software life cycle.
abrham 34
 HCI in the Software Process – Life Cycle (2.2)

• 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

abrham 35
The Waterfall Model
Requirements
specification

Architectural
design

Detailed
design

Coding and
unit testing

Integration
and testing

Operation and
maintenance

abrham 36
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 modules to
be implemented separately the refinement is governed by the nonfunctional
requirements

abrham 37
Coding and unit testing
The detailed design for a component of the system
should be in such a form that it is possible to
implement it in some executable programming
language. After coding, the component can be
tested to verify that it performs correctly, according to
some test criteria that were determined in earlier activities.
• Integration and testing
Once enough components have been implemented
and individually tested, they must be integrated as
described in the architectural design.
• Maintenance
After product release, all work on the system is
considered under the category of maintenance
abrham 38
Verification and Validation
• 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
– design in commercial and legal contexts

abrham 39
Interactive Systems Life Cycle
cannot assume a linear
Requirements
specification
sequence of activities
as in the waterfall model
Architectural
design

Detailed
design

Coding and
unit testing

Integration
and testing
• lots of feedback!
Operation and
maintenance
abrham 40
HCI in the Software Process – Usability Engineering
(2.3)

• 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
– does not necessarily satisfy usability

abrham 41
• Part of a usability specification for a VCR (Video Cassette
Recorder)
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
abrham 42
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?

abrham 43
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

errors corrected correcting errors error handling
successfully

abrham 44
 HCI in the Software Process – Iterative Design and
Prototyping (2.4)

• 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
– contracts
abrham 45
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
diagnosing real usability problems in prototypes …. and not
just the symptoms
abrham 46
HCI in the Software Process – Design Rationale (2.5)

• 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
– capturing contextual information

abrham 47
 Summary

• design:
– what it is, interventions, goals, constraints
• the design process
– what happens when
• users
– who they are, what they are like …
• scenarios
– rich stories of design
• navigation
– finding your way around a system
• iteration and prototypes
– never get it right first time!
abrham 48
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
– process vs. structure

abrham 49