1

Chapter Five
Interaction Design and HCI
in the Software Process
 Objectives of today’s class 2

Interaction design basics:

 Design
 The design process
 User Focus
 Scenarios
 Navigation design
 Screen design and Layouts
 User action and control
 Iteration design and prototypes
 3
Interaction design
What is interaction design?
 Interaction design is not just about the artifact that is
produced, whether a physical device or a computer
program, but about understanding and choosing how that
is going to affect the way people work.
 Interaction design basics 4
 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!
 What is design? 5
Achieving goals within constraints.
 Goals - purpose
 Who is it for, why do they want it.
 Constraints
 Materials, platforms
Golden rule of design:-
• Understand your materials: E.g. for Human–Computer Interaction
• Understand computers: LIMITATIONS, CAPACITIES, TOOLS,
PLATFORMS
• Understand people: PSYCHOLOGICAL, SOCIAL ASPECTS, HUMAN
ERROR
• and their interaction …
 To err is human 6

 accident reports ..
 air crash, industrial accident, hospital mistake
 enquiry … blames … ‘human error’
 human ‘error’ is normal
 we know how users behave under stress
 so design for it!
 treat the user at least as well as physical materials!
 The user 7

The process of design

 Steps… 8
 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
 … but how can I do it all !! 9

 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
 10

User Focus
know your user
personae
cultural probes
 know your User 11

 Who are they?

 Probably not like you!
 Talk to them
 Watch them
 Use your imagination
 Persona 12

 Description of an ‘example’ user

 Not necessarily a real person
 Use as surrogate user
 What would ‘Haymanot’ think
 Details matter
 Makes her ‘real’
 13

Scenarios
stories for design
use and reuse
 Scenarios 14
 Stories for design
 communicate with others
 validate other models
 understand dynamics
 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
 Use scenarios to… 15

 Communicate with others.

 designers, clients, users
 Validate other models.
 ‘play’ it against other models
 Express dynamics.
 screenshots – appearance
 scenario – behaviour
 the systems 16

info and help management messages

start
add user remove user

main
screen
remove
user
confirm
Navigation design
local structure – single screen
add user
global structure – whole site
 Levels 17
 Widget choice
 menus, buttons etc.
The web
 Screen design
 Application navigation  Widget choice - elements and tags E.g
<a href=“...”>
design  screen design - page design
 Environment  navigation design - site structure
 environment -the web, browser,
 other apps, O/S external links
 …continued 18
Physical devices

 WIDGET CHOICE – Controls

e.g buttons, knobs, dials
 SCREEN DESIGN - physical layout
 NAVIGATION DESIGN - modes of device
 ENVIRONMENT - the real world
Goal seeking 19
Goal seeking 20
Goal seeking 21
Goal seeking 22
Goal seeking 23
 Hierarchical diagrams 24
 Typically functional separation
 Network diagrams 25
 Show different paths through system

• What leads to
what?
• What happens
when?
• Including
branches…
 26

Screen design and layout

basic principles
grouping, structure, order
ABCDEFGHIJKLM
NOPQRSTUVWXYZ

alignment
use of white space
 Basic principles 27

 Ask Available tools

 what is the user doing?  Grouping of items
 Think  Order of items
 what information,  Decoration - fonts, boxes etc.
comparisons, order  Alignment of items
 Design  White space between items
 form follows function
 Grouping and structure 28

logically together  physically together

Billing details: Delivery details:
Name Name
Address: … Address: …
Credit card no Delivery time

Order details:
item quantity cost/item cost
size 10 screws (boxes) 7 3.71 25.97
…… … … …
 Order of groups and items 29

 Think! - what is natural order.

 Should match screen order.
 use boxes, space etc.
 Instructions
 follow the logical structure and follow.
 Decoration 30

 Use boxes to group logical items.

 Use fonts for emphasis, headings.
 But not too many!!

ABCDEFGHIJKLM
NOPQRSTUVWXYZ
 Alignment - text 31

 You read from left to right (English and European) -

Align left hand side.
Some what
Willy Wonka and the Chocolate Factory but readable!
Winston Churchill - A Biography
Wizard of Oz
Xena - Warrior Princess

Willy Wonka and the Chocolate Factory

Winston Churchill - A Biography
Fine for special effects Wizard of Oz
but hard to read Xena - Warrior Princess
 Alignment - Numbers 32

 Think purpose! 532.56 627.865

 Which is biggest? 179.3 1.005763
Visually:- 256.317 382.583
long number = big number 15 2502.56
align decimal points
73.948 432.935
or right align integers
1035 2.0175
3.142 652.87
497.6256 56.34
 White space 33

* Space to separate * Space to structure

 34

User action and control

entering information
knowing what to do
 Entering information 35

 Forms, dialogue boxes Name: Alan Dix

Address: Lancaster
 similar layout issues
 alignment-N.B. different label lengths
 Logical layout
 use task analysis
Name:


Alan Dix
Address: Lancaster

?
 groupings Name: Alan Dix
 natural order for entering information Address: Lancaster

 top-bottom, left-right (depending on culture)

 set tab order for keyboard entry
 Knowing what to do 36

 What is active what is passive

 where do you click
 where do you type
 Consistent style helps
 e.g. web underlined links
 Labels and icons
 standards for common actions
 language – bold = current state or action
• Knowing countries and cultures. E.g colours
 37

Interaction and prototyping

getting better …
… and starting well
 Prototyping 38

 Preparing a model or sample.

 If at first you don’t succeed …

OK?
design prototype evaluate done!

re-design
 Pitfalls of prototyping 39

1. need a good start point

2. need to understand what is wrong
 40

Chapter 5 (ctd)
HCI in the Software
Process
 Objectives of today’s class 41

 The software life cycle

 Usability engineering
 Design rationale
 The software life cycle 42
 The software life cycle is an attempt to identify the activities
that occur in software development.
 These activities must then be ordered in time in any
development project and appropriate techniques must be
adopted to carry them.
 In the development of a software product, we consider two
main parties:-
 The customer who requires the use of the product
 The designer who must provide the product.
 Activities in the life cycle 43
Activities in the Waterfall Model of the software life cycle
 1. Requirement Specification 44
 In requirements specification, the designer and customer try to capture
a description of what the eventual system will be expected to provide.
 This is in contrast to determining how the system will provide the
expected services, which is the concern of later activities.
 Requirements specification involves eliciting information from the
customer about the work environment, or domain, in which the final
product will function.
 Requirements specification begins at the start of product development.
 2. Architectural design 45
 How the system provides the services expected from it.
 Sub system decomposition of the system is performed.
3. Detailed design
 The detailed design is a refinement of the component description
provided by the architectural design.
 The behavior implied by the higher-level description must be
preserved in the more detailed description.
 4. Coding and Unit Testing 46

 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.
 5. Integration and Testing 47
 Once enough components have been implemented and
individually tested, they must be integrated as described in
the architectural design.
 It is also possible at this time to perform some acceptance
testing with the customers to ensure that the system meets
their requirements.
 6. Maintenance 48

 After product release, all work on the system is considered under

the category of maintenance, until such time as a new version of
the product demands a total redesign or the product is phased out
entirely.
 Maintenance involves the correction of errors in the system which
are discovered after release and the revision of the system services
to satisfy requirements that were not realized during previous
development.
 Therefore, maintenance provides feedback to all of the other
activities in the life cycle.
 49
The formality gap between the real world and structured
design:-
 Usability Engineering 50
 One approach to user-centered design has been the
introduction of explicit usability engineering.
 The ultimate test of a product’s usability is based on
measurements of users’ experience with it.
 Therefore, since a user’s direct experience with an
interactive system is at the physical interface, focus on the
actual user interface is understandable.
 Design rationale 51
 The design process is composed of a series of decisions, which pare down
the vast set of potential systems to the one that is actually delivered to the
customer.
 In this sense, design rationale does not fit squarely into the software life
cycle described.
 Rather, design rationale relates to an activity of both reflection (doing
design rationale) and documentation (creating a design rationale) that
occurs throughout the entire life cycle.
End 52
of to
d ay’s
class
!