L.

ANAND
Asst.Professor
SRM University, Kattankulathur

School of Computing, Department of IT 1

The contents of the slides are solely for the
purpose of teaching students at SRM
University. All copyrights and Trademarks of
organizations/persons apply even if not
specified explicitly.

School of Computing, Department of IT 8/22/2011 2

interaction design
basics
 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!
design interactions not just interfaces
not just the immediate interaction
e.g. stapler in office – technology changes interaction style
 manual: write, print, staple, write, print, staple, …
 electric: write, print, write, print, …, staple

designing interventions not just artefacts

not just the system, but also …
 documentation, manuals, tutorials
 what we say and do as well as what we make
 achieving goals within constraints

 goals - purpose
 who is it for, why do they want it
 constraints
 materials, platforms
 trade-offs
understand your materials
 understand your materials

 understand computers
 limitations, capacities, tools, platforms
 understand people
 psychological, social aspects
 human error

 and their interaction …

 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!
 treat the user at least as well as physical materials!
the user
 scenarios
what is task analysis
wanted guidelines
principles
interviews analysis precise
ethnography specification
design
what is there
vs. dialogue implement
what is wanted notations and deploy
evaluation
prototype
heuristics architectures
documentation
help
 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
 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
know your user
personae
cultural probes
 who are they?
 probably not like you!
 talk to them
 watch them
 use your imagination
 description of an ‘example’ user
 not necessarily a real person
 use as surrogate user
 what would Betty think
 details matter
 makes her ‘real’
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).
stories for design
use and reuse
 stories for design
 communicate with others
 validate other models
 understand dynamics

 linearity
 time is linear - our lives are linear
 but don’t show alternatives
 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

Brian would like to see the new film “Moments of Significance” and
wants to invite Alison, but he knows she doesn’t like “arty” films. He
decides to take a look at it to see if she would like it and so connects to
one of the movie sharing networks. He uses his work machine as it has a
higher bandwidth connection, but feels a bit guilty. He knows he will be
getting an illegal copy of the film, but decides it is OK as he is intending
to go to the cinema to watch it. After it downloads to his machine he
takes out his new personal movie player. He presses the ‘menu’ button
and on the small LCD screen he scrolls using the arrow keys to
‘bluetooth connect’ and presses the select button. On his computer the
movie download program now has an icon showing that it has recognised
a compatible device and he drags the icon of the film over the icon for
the player. On the player the LCD screen says “downloading now”, a
percent done indicator and small whirling icon. … … …
 mock up device
 pretend you are doing it
 internet-connected swiss army knife …

but where is that thumb?

use toothpick as stylus

 explore interaction
 what happens when

 explore cognition
 what are the users thinking

 explore architecture
 what is happening inside
 communicate with others
 designers, clients, users

 validate other models

 ‘play’ it against other models

 express dynamics
 screenshots – appearance
 scenario – behaviour
Scenarios – one linear path through system

Pros:
 life and time are linear
 easy to understand (stories and narrative are natural)
 concrete (errors less likely)
Cons:
 no choice, no branches, no special conditions
 miss the unintended

 So:
 use several scenarios
 use several methods
 the systems

info and help management messages

start

add user remove user

local structure – single screen

global structure – whole site

main remove
confirm
screen user

add user
 widget choice
 menus, buttons etc.
 screen design
 application navigation design
 environment
 other apps, O/S
 widget choice • elements and tags
– <a href=“...”>
 screen design • page design
 navigation design • site structure
 environment • the web, browser,
external links
 widget choice • controls
– buttons, knobs, dials
 screen design • physical layout
 navigation design • modes of device
 environment • the real world
 within a screen
 later ...
 local
 looking from this screen out
 global
 structure of site, movement between screens
 wider still
 relationship with other applications
from one screen looking out
 goal
start
 goal
start

progress with local knowledge only ...

 goal
start

… but can get to the goal

 goal
start

… try to avoid these bits!

 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
 shows path through web site hierarchy

top level category sub-category

web site this page

live links
to higher
levels
 things other things

the thing from

more things
outer space

 where do they go?

 lots of room for extra text!
 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
… oops !
 between screens
within the application
 the system

info and help management messages

add user remove user

 parts of application
 screens or groups of screens
 typically functional separation

the systems

info and help management messages

add user remove user

 deep is difficult!

 misuse of Miller’s 7 ± 2
 short term memory, not menu size

 optimal?
 many items on each screen
 but structured within screen
 what does it mean in UI design?

Minister: do you name take this woman …

Man: I do
Minister: do you name take this man …
Woman: I do
Minister: I now pronounce you man and wife
 what does it mean in UI design?

Minister: do you name take this woman …

• marriage service
 general flow, generic – blanks for names
 pattern of interaction between people
• computer dialogue
 pattern of interaction between users and system
 but details differ each time
 main remove
confirm
screen user

add user

 show different paths through system

 what leads to what
 what happens when
 including branches
 more task oriented then hierarchy

main remove
confirm
screen user

add user
between applications
and beyond ...
 style issues:
 platform standards, consistency
 functional issues
 cut and paste
 navigation issues
 embedded applications
 links to other apps … the web
 basic principles
grouping, structure, order
alignment
use of white space

ABCDEFHIJKLM
NOPQRSTUVWXYZ
 ask
 what is the user doing?
 think
 what information, comparisons, order
 design
 form follows function
 grouping of items
 order of items
 decoration - fonts, boxes etc.
 alignment of items
 white space between items
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
…… … … …
 think! - what is natural order

 should match screen order!

 use boxes, space etc.
 set up tabbing right!

 instructions
 beware the cake recipie syndrome!
… mix milk and flour, add the fruit
after beating them
 use boxes to group logical items
 use fonts for emphasis, headings
 but not too many!!

ABCDEFHIJKLM
NOPQRSTUVWXYZ
 you read from left to right (English and European)

 align left hand side

Willy Wonka and the Chocolate Factory

boring but
Winston Churchill - A Biography readable!
Wizard of Oz
Xena - Warrior Princess

Willy Wonka and the Chocolate Factory

Winston Churchill - A Biography
Wizard of Oz
fine for special effects Xena - Warrior Princess
but hard to scan
 Usually scanning for surnames
 make it easy!

Alan Dix


Janet Finlay
Gregory Abowd
Dix , Alan

Finlay, Janet


Russell Beale Abowd, Gregory
Beale, Russell
Alan Dix
Janet Finlay
Gregory Abowd
Russell Beale
think purpose! 532.56
179.3
which is biggest? 256.317
15
73.948
1035
3.142
497.6256
visually:
627.865
long number = big number
1.005763
align decimal points 382.583
or right align integers 2502.56
432.935
2.0175
652.87
56.34
 scanning across gaps hard:
(often hard to avoid with large data base fields)

sherbert 75
toffee 120
chocolate 35
fruit gums 27
coconut dreams 85
 use leaders

sherbert 75
toffee 120
chocolate 35
fruit gums 27
coconut dreams 85
 or greying (vertical too)

sherbert 75
toffee 120
chocolate 35
fruit gums 27
coconut dreams 85
 or even (with care!) ‘bad’ alignment

sherbert 75
toffee 120
chocolate 35
fruit gums 27
coconut dreams 85
WHAT YOU SEE
 WHAT YOU SEE

THE GAPS BETWEEN

 grouping of items
defrost settings
defrost
type settings
of food
time
typeto
ofcook
food
time to cook
 grouping of items
 order of items

1) type of heating
1
2) temperature

3) time to cook
2
4) start
3

4
 grouping of items
 order of items
 decoration
 differentcolours
for different
different functions
colours for
different
 lines functions
around related
buttons
lines around related
buttons (temp up/down)
 grouping of items
 order of items
 decoration
 alignment
 centered text in buttons
? easy to scan ?
centred text in buttons
? easy to scan ?
 grouping of items
 order of items
 decoration
 alignment
 white space
 gaps to aid grouping

gaps to aid grouping

entering information
knowing what to do
affordances
 Name: Alan Dix
 forms, dialogue boxes Address: Lancaster
 presentation + data input
 similar layout issues
 alignment - N.B. different label lengths Name:

 Alan Dix
Address: Lancaster

?
 logical layout
 use task analysis (ch15) Name: Alan Dix
 groupings
Address: Lancaster
 natural order for entering information
 top-bottom, left-right (depending on culture)
 set tab order for keyboard entry
 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
 psychological term mug handle
 for physical objects
‘affords’
 shape and size suggest actions grasping
 pick up, twist, throw
 also cultural – buttons ‘afford’ pushing
 for screen objects
 button–like object ‘affords’ mouse click
 physical-like objects suggest use
 culture of computer use
 icons ‘afford’ clicking
 or even double clicking … not like real buttons!
 presenting information
aesthetics and utility
colour and 3D
localisation & internationalisation
 purpose matters
 sort order (which column, numeric alphabetic) name size
 text vs. diagram
chap10
chap1 17
12
 scatter graph vs. histogram chap10
chap5 12
16
chap11
chap1 51
17
chap12
chap14 262
22
 use paper presentation principles! chap13
chap20 83
27
chap14
chap8 22
32
…… …
 but add interactivity
 softens design choices
 e.g. re-ordering columns
 ‘dancing histograms’ (chap 21)
 aesthetically pleasing designs
 increase user satisfaction and improve productivity
 beauty and utility may conflict
 mixed up visual styles  easy to distinguish
 clean design – little differentiation  confusing
 backgrounds behind text
… good to look at, but hard to read
 but can work together
 e.g. the design of the counter
 in consumer products – key differentiator (e.g. iMac)
 both often used very badly!
 colour
 older monitors limited palette
 colour over used because ‘it is there’
 beware colour blind!
 use sparingly to reinforce other information

 3D effects
 good for physical information and some graphs
 but if over used …
e.g. text in perspective!! 3D pie charts
 over use - without very good reason (e.g. kids’ site)
 colour blindness
 poor use of contrast
 do adjust your set!
 adjustyour monitor to greys only
 can you still read your screen?
 localisation & internationalisation
 changing interfaces for particular cultures/languages
 globalisation
 try to choose symbols etc. that work everywhere

 simply change language?

 use ‘resource’ database instead of literal text
… but changes sizes, left-right order etc.
 deeper issues
 cultural assumptions and values
 meanings of symbols
e.g tick and cross … +ve and -ve in some cultures
… but … mean the same thing (mark this) in others

 
 getting better …
… and starting well
 you never get it right first time
 if at first you don’t succeed …

OK?
design prototype evaluate done!

re-design
 moving little by little … but to where
 Malverns or the Matterhorn?

1. need a good start point

2. need to understand what is wrong
HCI in the software
process
 Software engineering and the design process for
interactive systems
 Usability engineering
 Iterative design and prototyping
 Design rationale
 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
Requirements
specification

Architectural
design

Detailed
design

Coding and
unit testing

Integration
and testing

Operation and
maintenance
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
 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
design in commercial and legal contexts
 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

Operation and
maintenance
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
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
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?
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
 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
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
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
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)
 Design space analysis
 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
 gIBIS is a graphical version
 supports
Position Argument
responds to
Issue
responds to
objects to
Position Argument
specializes

Sub-issue generalizes

questions

Sub-issue

Sub-issue
 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 – similar to QOC with a larger language and

more formal semantics
 Option Criterion

Question Option Criterion

Option
Criterion

… Consequent …
Question
Question
 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
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
design rules
Designing for maximum usability
– the goal of interaction design

 Principles of usability
 general understanding

 Standards and guidelines

 direction for design

 Design patterns
 capture and reuse design knowledge
 principles
 abstract design rules
 low authority

increasing generality
 high generality Guidelines

increasing generality
 standards
 specific design rules
 high authority
Standards
 limited application
 guidelines
 lower authority increasing authority
increasing authority
 more general application
Learnability
the ease with which new users can begin effective
interaction and achieve maximal performance

Flexibility
the multiplicity of ways the user and system exchange
information

Robustness
the level of support provided the user in determining
successful achievement and assessment of goal-directed
behaviour
Predictability
 determining effect of future actions based on
past interaction history
 operation visibility

Synthesizability
 assessing the effect of past actions
 immediate vs. eventual honesty
Familiarity
 how prior knowledge applies to new system
 guessability; affordance

Generalizability
 extending specific interaction knowledge to new
situations

Consistency
 likeness in input/output behaviour arising from similar
situations or task objectives
Dialogue initiative
 freedom from system imposed constraints on input
dialogue
 system vs. user pre-emptiveness

Multithreading
 ability of system to support user interaction for more
than one task at a time
 concurrent vs. interleaving; multimodality

Task migratability
 passing responsibility for task execution between user
and system
Substitutivity
 allowing equivalent values of input and output to
be substituted for each other
 representation multiplicity; equal opportunity

Customizability
 modifiability of the user interface by user
(adaptability) or system (adaptivity)
Observability
 ability of user to evaluate the internal state of the
system from its perceivable representation
 browsability; defaults; reachability; persistence;
operation visibility

Recoverability
 ability of user to take corrective action once an error
has been recognized
 reachability; forward/backward recovery;
commensurate effort
Responsiveness
 how the user perceives the rate of
communication with the system
 Stability

Task conformance
 degree to which system services support all of
the user's tasks
 task completeness; task adequacy
 increasing generality
Guidelines

increasing generality
Design rules
 suggest how to increase usability
Standards
 differ in generality and authority

increasing authority
increasing authority
 set by national or international bodies to ensure
compliance by a large community of designers
standards require sound underlying theory and
slowly changing technology

 hardware standards more common than software

high authority and low level of detail

 ISO 9241 defines usability as effectiveness,

efficiency and satisfaction with which users
accomplish tasks
 more suggestive and general
 many textbooks and reports full of guidelines
 abstract guidelines (principles) applicable during
early life cycle activities
 detailed guidelines (style guides) applicable
during later life cycle activities
 understanding justification for guidelines aids in
resolving conflicts
 “Broad brush” design rules
 Useful check list for good design
 Better design using these than using nothing!
 Different collections e.g.
 Nielsen’s 10 Heuristics (see Chapter 9)
 Shneiderman’s 8 Golden Rules
 Norman’s 7 Principles
1. Strive for consistency
2. Enable frequent users to use shortcuts
3. Offer informative feedback
4. Design dialogs to yield closure
5. Offer error prevention and simple error
handling
6. Permit easy reversal of actions
7. Support internal locus of control
8. Reduce short-term memory load
1. Use both knowledge in the world and
knowledge in the head.
2. Simplify the structure of tasks.
3. Make things visible: bridge the gulfs of
Execution and Evaluation.
4. Get the mappings right.
5. Exploit the power of constraints, both natural
and artificial.
6. Design for error.
7. When all else fails, standardize.
 An approach to reusing knowledge about
successful design solutions
 Originated in architecture: Alexander
 A pattern is an invariant solution to a recurrent
problem within a specific context.
 Examples
 Light on Two Sides of Every Room (architecture)
 Go back to a safe place (HCI)

 Patterns do not exist in isolation but are linked

to other patterns in languages which enable
complete designs to be generated
 Characteristics of patterns
 capture design practice not theory
 capture the essential common properties of good examples of
design
 represent design knowledge at varying levels: social, organisational,
conceptual, detailed
 embody values and can express what is humane in interface design
 are intuitive and readable and can therefore be used for
communication between all stakeholders
 a pattern language should be generative and assist in the
development of complete designs.
Principles for usability
 repeatable design for usability relies on maximizing
benefit of one good design by abstracting out the
general properties which can direct purposeful design
 The success of designing for usability requires both
creative insight (new paradigms) and purposeful
principled practice

Using design rules

 standards and guidelines to direct design activity
 Alan Dix- Janet Finlay Gregory D. Abowd-
Russel Beale- Human – Computer Interaction,
Pearson Education- 3 rd Edition- 2004.
 John M.Caroll, Human – Computer
Interaction in the Millennium, Pearson
Education- 3rd Edition- 2000.

School of Computing, Department of IT 8/22/2011 129

1. Define design.
2. What is scenario?
3. Suggest few visual ways to represent
multiple column lists.
4. Define localization.
5. What is usability engineering?
6. List few usability metrics.
7. What are the principles that affect
learnability?

School of Computing, Department of IT 8/22/2011 130

8. What are the principles that affect
flexibility?
9. What are the principles that affect
robustness?
10. Define predictability/ synthesizability
/familiarity / generalizability /consistency
11. What is dialog initiative/ multithreading/
task migratability / substitutivity/
customizability?
12. Define observability / recoverability /
responsiveness / task conformance.
13. Define usability.

School of Computing, Department of IT 8/22/2011 131