Вы находитесь на странице: 1из 139

interaction design

 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
what is task analysis
wanted guidelines
interviews analysis precise
ethnography specification
what is there
vs. dialogue implement
what is wanted notations and deploy
heuristics architectures
 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
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

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

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

info and help management messages


add user remove user

local structure – single screen

global structure – whole site

main remove
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

progress with local knowledge only ...


… but can get to the goal


… 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
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
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
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
use of white space

 what is the user doing?

 what information, comparisons, order

 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!!

 you read from left to right (English and European)
 align left hand side

boring but
Willy Wonka and the Chocolate Factory
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
which is biggest? 256.317
long number = big number
align decimal points 382.583
or right align integers 2502.56
 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


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

1) type of heating
2) temperature

3) time to cook
4) start

 grouping of items
 order of items
 decoration
 different colours
for different functions
different colours for
 lines aroundfunctions
different related
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
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)
natural order for entering information
Name: Alan Dix
Address: Lancaster

 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
 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 12
 scatter graph vs. histogram chap10
chap5 16
chap1 17
chap14 262
 use paper presentation principles! chap13
chap20 27
chap8 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!
 adjust your 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
Paper Prototyping
 you never get it right first time
 if at first you don’t succeed …

design prototype evaluate done!

 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
 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



Coding and
unit testing

and testing

Operation and
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
and constraints The formality gap

designing the product right
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
as in the waterfall model


Coding and
unit testing

lots of feedback! Integration

and testing

Operation and
The ultimate test of usability based on measurement of user

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

 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
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

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

Learnability Percentage of Time to learn Rating scale

functions learned criterion ease of

Error tolerance Percentage of Time spent on Rating scale

errors corrected correcting errors error handling
 Iterative design overcomes inherent problems of incomplete

 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
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

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

 gIBIS is a graphical version

Position Argument
responds to
responds to
objects to
Position Argument

Sub-issue generalizes



 structure-oriented

 QOC – hierarchical structure:

questions (and sub-questions)
– represent major issues of a design
– provide alternative solutions to the question
– the means to assess the options in order to make a choice

 DRL – similar to QOC with a larger language and

more formal semantics

Question Option Criterion

Option Criterion

… Consequent …
 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
 high generality Guidelines

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

the multiplicity of ways the user and system exchange

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

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

 extending specific interaction knowledge to new

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

 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
 allowing equivalent values of input and output to
be substituted for each other
 representation multiplicity; equal opportunity

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

 ability of user to take corrective action once an error
has been recognized
 reachability; forward/backward recovery;
commensurate effort
 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
increasing generality
Design rules
 suggest how to increase usability
 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
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
 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 137

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

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

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

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