Tài liệu Human-Computer Interaction pot

Human-Computer Interaction
506.020 2VO Mensch-Maschine-Kommunikation SS 2002
Graz University of Technology, Austria
Lecture Notes
Draft Version of 25th February 2002
Dr. Keith Andrews
IICM
Graz University of Technology
Inffeldgasse 16c
A-8010 Graz

These lecture notes are available online at
/>Copyright
c
2002 Keith Andrews
Contents
Preface viii
Credits ix
1 Human Computer Interaction 1
2 Would You Use Untested Software? 3
2.1 Zippy: Evaluating a UI Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 MANTEL UI Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 The Psychology of Usable Things 17
3.1 The Psychopathology of Everyday Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 The Psychology of Everyday Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 The Psychopathology of Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Interface Hall of Shame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 User Centered Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4 Usability Engineering 41
4.1 Defining Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Usability Engineering Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3 Planning Usability Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 Goal-Oriented Interaction Design 47
5.1 Interviewing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 Creating Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 Defining Goals for each Persona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4 Defining Scenarios for each Persona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.5 Moving to a Design Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6 Prototyping 60
6.1 Verbal Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Paper Mock-Ups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3 Interactive Sketches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.4 Working Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.5 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7 Usability Inspection Methods 66
7.1 Heuristic Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.2 Prioritising Found Usability Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
7.3 Cognitive Walkthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.4 Action Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
i
8 Usability Testing 78
8.1 Preparing for Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
8.2 Six Stages of Conducting a Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.3 Paper and Pencil Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.4 Thinking Aloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.5 Co-Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.6 Formal Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.7 Query Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
9 Usability in Practice 101
9.1 Comparison of Evaluation Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
9.2 Discount Usability Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

9.3 Case Study: Touchscreen Toggle Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.4 Differences in Evaluation Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
10 Visual Design and Typography 107
10.1 Typography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10.2 Factors Influencing the Legibility of Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
11 Icon Design 114
11.1 Visual Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
11.2 Standard Parts of an Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
11.3 Icon Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
11.4 Cultural and International Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.5 Do Not Always Use Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.6 Iconic Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
11.7 The Icon Design Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.8 Designing Icons for Sun’s Public Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
12 Web Site Usability 130
12.1 Three Fundamental Kinds of Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
12.2 Know Your Web Site Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
12.3 Information Site Design (Information Architecture) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
12.4 Content Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
12.5 Page Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
12.6 Web Site Design Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
13 Web Usability Case Studies 161
13.1 SunWeb: User Interface Design for Sun Microsystem’s Internal Web . . . . . . . . . . . . . . . . . . . 161
13.2 SunWWW: User Interface Design for Sun’s Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
13.3 MSWeb: Microsoft Intranet Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
13.4 Designing Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Bibliography 178
ii
List of Figures
1.1 The nature of Human-Computer Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 The ZIPPY Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 The ZIPPY Exercise Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Suggestion for a revised ZIPPY display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 USPS Zip Code Lookup 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 USPS Zip Code Lookup 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 USPS Zip Code Lookup 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.7 The MANTEL display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 Suggestion for a revised MANTEL display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Video Recorder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Video Recorder Remote Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 The Leitz Pravodit slide projector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 The control panel in lecture theatre HS EDV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Audiovisual trolley with inputs at rear. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Warning label on audiovisual trolley. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7 Where is the toilet paper? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.8 Ah, there it is! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.9 Ambiguous door designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.10 Good use of affordances in door designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.11 Example of ambiguous affordances in door design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.12 Good use of affordances in the same hotel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.13 Arbitrary mapping of controls to hot plates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.14 Paired cooker controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.15 A full, natural mapping of cooker controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.16 Lego Motorbike Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.17 Assembled Lego Motorbike . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.18 Beer Tap Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.19 Fridge freezer controls and instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.20 The apparent conceptual model for the fridge freezer . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.21 The actual conceptual model for the fridge freezer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.22 Projecting a correct conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.23 Scissors project a good conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.24 A digital watch provides no obvious conceptual model . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.25 New keyboard for Windows PCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.26 Internet Explorer 4.0 cache settings panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.27 Internet Explorer 4.0 certificate authority selection panel . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.28 A two-item list box in Visual Basic 5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.29 A two thousand item list box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.30 Multi-row tab controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.31 Deleting files from an almost full hard disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.32 Ejecting a diskette on the Mac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 Usability engineering cartoon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
iii
4.2 Defining usability in the context of system acceptability . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Riding the learning curves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Categories of user experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1 Elastic user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Jumble car . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Cars to match their drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4 The InFlight Seat Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 The InFlight Final Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.6 Parallel and iterative design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.7 Lateral Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1 Paper Prototype of IICM on Air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.2 Working Prototype of IICM on Air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.3 Paper Prototype 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.4 Paper Prototype 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.5 Paper Prototype 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.6 An interactive sketch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.7 Dimensions of prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.1 Aggregated evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.2 Sample Banking System dialogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.3 Aggregated evaluations by evaluator experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.1 Simple usability test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.2 Single room, single camera test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.3 Example single room, single camera test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.4 Alternative single room setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8.5 Observation room with electronic monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.6 Classical usability lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8.7 Example task list for usabilty test of Harmony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.8 Orientation script for Harmony usability test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.9 Background questionnaire for Harmony usability test . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.10 Combined nondisclosure and consent form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.11 A generic data collection form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.12 Example test checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
8.13 Completed data collection form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
9.1 Hotmail password hint question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
9.2 Hotmail redesigned secret question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
9.3 Hotmail compose new message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
10.1 Serif and sans serif fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10.2 Proportional versus fixed width fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
10.3 Font size changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
10.4 All upper case slows reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
10.5 Lower and mixed case words have distinctive shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
10.6 En and em word spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.7 Line spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.8 About 60 characters per line in books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.9 About 30 characters per line in newspaper columns . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
10.10 Flush and justified text styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
10.11 Using a layout grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
10.12 Text right up to margins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

10.13 Text with ample margins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
iv
11.1 The standard parts of an icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
11.2 Visually imbalanced icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
11.3 Mixed levels of realism in icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
11.4 Symbols for men and women at different levels of abstraction . . . . . . . . . . . . . . . . . . . . . . 118
11.5 Typical viewing distances to icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.6 Symbol silhouette conveys most information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
11.7 Garish multicolour icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.8 Well-balanced, consistent set of icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.9 Evolution of Microsoft Word icon bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.10 Language-dependent text or characters in icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.11 Culturally-dependent mailbox icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.12 Icons for food an drink areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.13 Words for food an drink areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
11.14 The icon design lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
11.15 Test setup for icon intuitiveness test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
11.16 An icon intuitiveness test in progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
11.17 Room Setup for the icon test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
11.18 Icon Iterations for “Products and Solutions” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.19 Icon Iterations for “Sun on the Net” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
12.1 Three kinds of web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
12.2 Mixing purposes within a site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
12.3 The restaurant metaphor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
12.4 Concept cards scattered on a table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
12.5 Test facilitator explains unclear concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
12.6 Grouping Cards into Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
12.7 Categories labelled with Post-it notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
12.8 An unplanned labeling system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
12.9 A planned labeling system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

12.10 Navigational bar at top of each page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
12.11 Use of the META tag at Virtual Vineyards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
12.12 Link overload on PICS pages at W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
12.13 The Virtual Vineyards site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
12.14 The Virtual Vineyards site, with table borders turned on . . . . . . . . . . . . . . . . . . . . . . . . . 148
12.15 Original look of Keith’s home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
12.16 Keith’s redesigned home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
12.17 Behind the scenes at Keith’s redesigned home page . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
12.18 GIF interlacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
12.19 Progressive JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
12.20 Using transparency for non-rectangular images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
12.21 Anti-aliasing a black line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
12.22 Antialiasing a red circle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
12.23 An antialiased circle against a different background . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
12.24 Greeking test, template 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
12.25 Greeking test, template 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
12.26 Greeking test, template 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
12.27 Greeking test, template 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
12.28 Greeking test, template 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
12.29 Average percentage of correctly identified page elements . . . . . . . . . . . . . . . . . . . . . . . . 159
12.30 Preferred page templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
13.1 SunWeb: Card Distribution to Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
13.2 SunWeb: Main and Second Level Mastheads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
13.3 SunWeb: Final Home Page Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
v
13.4 Usability lab setup at Sun. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
13.5 SunWWW Button Bar Redesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
13.6 SunWWW Card Sorting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
13.7 SunWWW Paper Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
13.8 SunWWW Working Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

13.9 SunWWW Design 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
13.10 SunWWW Design 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
13.11 SunWWW Design 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
13.12 SunWWW Design 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
13.13 SunWWW Design 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
13.14 SunWWW Design 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
13.15 SunWWW Design 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
13.16 SunWWW Design 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
13.17 SunWWW Design 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
13.18 SunWWW All Nine Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
vi
List of Tables
2.1 Summary of problems found in MANTEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Setting a usability target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2 Survey of usability budgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1 Differences Between Computers and Humans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2 Programmers Think and Behave Differently . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Personal and Corporate Goals are Different . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4 Four Main Passenger Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 Five Main Employee Personas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.1 Proportion of evaluators by experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.2 Average times for typical keystroke-level actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.1 User profile for users of Harmony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
8.2 Simple coding scheme for event logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
11.1 Iconic language for Windows NT 4.0 documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
11.2 Iconic language for document and link icons in Harmony . . . . . . . . . . . . . . . . . . . . . . . . 123
11.3 First Round of Icon Designs for “Technology and Developers” . . . . . . . . . . . . . . . . . . . . . 128
11.4 Second Round of Icon Designs for “Technology and Developers” . . . . . . . . . . . . . . . . . . . . 128
11.5 Third Round of Icon Designs for “Technology and Developers” . . . . . . . . . . . . . . . . . . . . . 128
12.1 Typical cost of building a web site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

12.2 Connection Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
12.3 How Long Will Users Wait? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
12.4 Reasons for Return Visits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
12.5 SOWS Linkrot Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
12.6 Maximum acceptable page sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
12.7 HTML source code for Keith’s new home page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
13.1 SunWeb: Results of Icon Intuitiveness Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
13.2 SunWeb: Five Iterations of Specialised Tools Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
13.3 User Comments on Design 5 Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
vii
Preface
These lecture notes have evolved over many years of teaching HCI at Graz University of Technology and teaching User
Interface Design at Technikum K
¨
arnten. I would like to thank my students past and present for their many suggestions
and corrections which have helped to massage these notes into their current form.
References in Association with Amazon
References with an ISBN number are linked to amazon.com (or amazon.co.uk or amazon.de) for quick, discounted
purchasing. Amazon pay a small referral fee to the referrer (me) for each item you purchase after following such a link
– the item itself does not cost you any more. If you find these notes useful and would like to contribute towards their
maintenance, please purchase any book you might want after following a specific ISBN link from here. For example:
amazon.com USA />amazon.co.uk UK />amazon.de Germany />for a book with ISBN 1558605339. Note that amazon.de deliver to Germany, Austria, and Switzerland free of shipping!
Alternatively, you can also follow one of the following links to your nearest Amazon home page:
amazon.com USA />amazon.co.uk UK />amazon.de Germany />and any item you buy in that session will count.
Thanks and happy reading,
Keith
viii
Credits
• The paper prototype images of the Northumberland Bank interface in Section 4.2 are used with kind permission
from Cliff Brown, University of Northumbria at Newcastle.

• The material in Section 9.4 on Comparative Usability Evaluation is used with kind permission from Rolf Molich,
DialogDesign, Denmark.
• The material in Sections 11.8, 13.1, and 13.2 on Sun’s public and intranet web sites is used with kind permission
from Jakob Nielsen.
• The figures in Section 12.5 on greeking tests are used with kind permission from Tom Tullis, Fidelity Investments.
ix
1 Human Computer Interaction
“Human-computer interaction is a discipline concerned with the design, evaluation and implementation of
interactive computing systems for human use and with the study of major phenomena surrounding them.”
[ACM SIGCHI Curricula for Human-Computer Interaction]
A
Human
Computer
Use and Context
Development Process
Human Social
Organisation
Application Areas
and Tasks
Human-Machine Fit
Human
Information
Processing
Language,
Communication
Interface
Metaphors
Dialogue
Techniques
Ergonomics

I/O Devices
Graphic
Design
Evaluation
Techniques
Prototypes
Design
Approaches
Implementation Techniques
and Tools
Figure 1.1: The nature of Human-Computer Interaction. Adapted from Figure 1 of the ACM
SIGCHI Curricula for Human-Computer Interaction.
1
1. HUMAN COMPUTER INTERACTION 2
References
• Ben Shneiderman; Designing the User Interface, 3rd Ed.; Addison-Wesley, 1997. ISBN 0201694972 (de, uk)
• Jenny Preece et al; Human-Computer Interaction; Addison-Wesley, 1994. ISBN 0201627698 (de, uk)
• Alan Cooper; The Inmates are Running the Asylum; SAMS, April 1999. ISBN 0672316498 (de, uk)
• Alan Cooper; About Face: The Essentials of User Interface Design; IDG Books, 1995. ISBN 1568843224 (de, uk)
• Jef Raskin; The Humane Interface: New Directions for Designing Interactive Systems; Addison-Wesley, March 2000. ISBN
0201379376 (de, uk)
• Helander, Landauer, Prabhu (Eds.); Handbook of Human-Computer Interaction; 2nd. Ed., Elsevier, 1997. 1600 pages. ISBN
0444818626 (de, uk)
• Bruce Tognazzini; TOG on Interface; Addison-Wesley, 1992. ISBN 0201608421 (de, uk)
• Bruce Tognazzini; Tog on Software Design; Addison-Wesley, 1995. ISBN 0201489171 (de, uk)
• Baecker et al; Human-Computer Interaction: Toward the Year 2000; Morgan Kaufmann, 1995. ISBN 1558602461 (de, uk)
• Baecker and Buxton; Readings in Human-Computer Interaction; Morgan Kaufmann, 1987. ISBN 0934613249 (de, uk)
• ACM Interactions, TOCHI, CHI Conference Proceedings.
• ISO 9241 Ergonomics requirements for office work with visual display terminals (VDTs).
• ISO DIS 13407 Human-centred design processes for interactive systems, 1997.

Online Resources
• ACM SIGCHI
/>• Usability Professionals’ Association
/>• Human-Computer Interaction Resources Network (HCI RN)
/>• HCI Bibliography
/>• Newsgroup news:comp.human-factors
• ACM Digital Library
/>[For students $ 38.00 per year />• IEEE Computer Society Digital Library
/>[For students $ 80.00 per year. />The Front Desk
• The Front Desk
Bruce Tognazzini and the BBC [BBC, 1995], 30 minute videotape.
2 Would You Use Untested Software?
Would you knowingly use untested software?
• How many of you have written programs that are used by other people?
• How many of you have watched/observed users using your software?
• How many of you actually evaluated the interface with test users?
• In practice, most software developers do not actually conduct any kind of usability evaluation [due to perceived
expense, lack of time, expertise, inclination, or tradition].
• For example, one study (Milsted et al 1989) found only 6% of Danish software companies doing any kind of
usability evaluation.
2.1 Zippy: Evaluating a UI Specification
Imagine that you are given a draft specification for “ZIPPY: THE FAST ZIP CODE WEBSEARCH” a web-based zip
code lookup service. See the screen design in Figure 2.1 and the exercise sheet in Figure 2.2.
Your Task
• Wanted: list of usability problems in the ZIPPY draft specification.
• Hint: the authors of the exercise found a two-digit number of problems in the spec.
• To get you started, here is one of the usability problems found:
1. The error messages use upper case letters only, although mixed-case text is more readable.
2.
3.

• It is important to work individually!
3
2. WOULD YOU USE UNTESTED SOFTWARE? 4
Figure 2.1: The ZIPPY mock-up screen from the ZIPPY draft specification.
2. WOULD YOU USE UNTESTED SOFTWARE? 5
ZIPPY: An Exercise in Interface Evaluation v1.0
Keith Andrews and Patrick Hackl
YOUR TASK
Your task is to advise a document delivery company, Utah
Package Shipment, about the quality of the human-computer
interface of ZIPPY, a web application currently under design.
Company management would like to ensure that novice users
will be able to obtain results quickly and easily when using
the application. With this in mind, you should point out as
many different usability problems in the interface specification
as possible.
The basic functionality of the application is fixed. The pur-
pose of the exercise is to criticise the interface of the applica-
tion and not its functionality. New features might enhance the
usability of the application, but suggestions for new or changed
features are not part of this exercise. Your solution should con-
sist of a list of all the usability problems you can find in the
interface specification. You may also wish to include sugges-
tions for how to improve the interface in order to avoid usabil-
ity problems, and you may consider specifying an improved
interface. Your primary aim should be to articulate the usabil-
ity problems you have identified, instead of merely indicating
them implicitly through subtle changes in an alternate design.
We (the authors) have identified a number of usability
problems in this interface. The exact number will not be dis-

closed here except to say that it is a two-digit number. To help
you get started and to indicate the type of answers desired, here
is one of the usability problems as well as a suggestion for how
to improve the interface:
1. The error messages use upper case letters only, although
mixed-case text is more readable.
ZIPPY: THE FAST ZIP CODE WEBSEARCH
The ZIPPY application is part of Utah Package Shipment’s
web site. Customers must enter the correct zip code corre-
sponding to the destination address of the package. To help
them find the correct zip code, THE FAST ZIP CODE WEB-
SEARCH application opens up in a separate pop-up window,
as shown in the screen mock-up below.
ZIP codes consist of exactly 5 numeric digits. Users can
enter either a city and state combination to return all associ-
ated zipcodes, or can enter a zipcode to return all associated
cities. Clicking on the SUBMIT button starts the query. After
a query has been submitted, a result page of either associated
ZIP Codes or associated cities is displayed:
Associated ZIP Codes Associated Cities
10020 New York
10021

If the server is busy, it may take upto 30 seconds to retrieve
a result page. If the city or state is not found, is empty, or
does not have the correct syntax, the application displays the
message:
CITY AND STATE NOT FOUND OR EMPTY.
PLEASE TRY AGAIN.
If the ZIP Code is not found, is empty, or does not have the

correct syntax, the application displays the message:
ILLEGAL ZIP CODE. PLEASE ENTER
A VALID 5 DIGIT ZIP CODE.
Figure 2.2: The ZIPPY Exercise Sheet.
2. WOULD YOU USE UNTESTED SOFTWARE? 6
How Many Potential Problems are there in ZIPPY ?
The interface specification for this simple system actually contains at least 70(!) usability problems.
The problems are categorised according to Nielsen’s revised set of usability heuristics [Nielsen, 1994a].
Visibility of System Status
1. A response time of 30 seconds is unacceptable. The system should provide some appropriate feedback (progress
bar) when the server is busy.
2. There is no indication that the user’s input is reflected on the result page. The result page should indicate the query
the user entered.
3. There is no window title. It is not clear that we are in the ZIPPY application.
4. There is no reference to Utah Package Shipment in the popup.
5. There is no indication when the site was last updated. How recent is the data in the database?
Match Between System and the Real World
6. Novice users may find “Submit Query” confusing. Perhaps “Search” would be better.
7. What is an “add-on code”, there is no explanation.
8. mailto: should be hidden from the user.
9. The line “server fzipcs03 version 2.1” is too system-oriented and could well confuse novice users.
User Control and Freedom
10. There is no clearly marked way to leave the application popup (apart from through the window manager).
11. There is no indication of a way back from the result page.
12. If the error messages are displayed on a new page, there is no indication of a way back.
Consistency and Standards
13. Several variants for the same thing: ZIP code, zip code, zipcode, .
14. Two different names for button: Submit Query and SUBMIT.
15. “New York and NY” is not an example of a Zip Code.
16. “94116” is not an example of a city.

17. “If you have any comments or suggestions ” is arbitrarily in a different font.
18. There is no indication of where error messages should be (consistently) displayed.
19. Support the convention of using the Return key to start a search.
Error Prevention
20. There is no indication of what the Reset button does.
21. Resetting field values is probably unnecessary here and users might unwittingly lose their input. Remove the
button.
22. The underlining of City and State might be misinterpreted as a link.
23. The underlining of ZIP Code might be misinterpreted as a link.
24. The input field labels are bold upper case. Users might think this means that all three are required fields.
2. WOULD YOU USE UNTESTED SOFTWARE? 7
25. If the state input is a two-letter abbreviation, the field should be exactly two characters wide.
26. The ZIP code is exactly five digits. Make the input field exactly five characters wide.
27. If an add-on code is entered, display a warning message, but process the query anyway ignoring the add-on code.
28. Split City and State from the Zip Code. The City and State pair of input fields should have their own associated
submit button (“Find Zip”), as should the Zip Code input field (“Find City”).
29. If all three input fields city, state, and zip code are entered, display a warning message, but also display both sets
of output.
30. Use Javascript to check field values locally before submission to the server.
31. There is no indication that ZIPPY is only appropriate for packages with a destination in the USA.
32. If there are other cities of the same name, but in a different state, perhaps indicate this to the user.
33. If a city or state does not match exactly, perhaps use a fuzzy search to suggest possible matches.
34. Disable the submit button until at least one field has values entered.
Recognition rather than Recall
35. It is not clear if input to the state field is a 2-letter abbreviation or the full state name.
36. Provide a drop-down of states to choose from.
37. Display explanations directly beside the input fields.
Flexibility and Efficiency of Use
38. Allow just a city to be entered. If it is ambiguous, then display a pulldown of possible states.
39. Allow common abbreviations for a city (e.g. SF, LA) to be entered in the city field.

40. Is “St.” an acceptable abbreviation for “Saint”, for example St. Louis?
Aesthetic and Minimalist Design
41. The error messages use upper case letters only, although mixed-case text is more readable.
42. The line “GO HERE FOR ABBREV. LIST” should be in mixed case.
43. Avoid abbreviations if possible, “abbreviation” is better than “ABBREV.”
44. Spelling mistake “asociated” should be “associated”. Spelling errors distract users and give impression of poor
quality.
45. English grammar “web search” is better than “websearch”.
46. Remove the asterisks *** in the title, they simply distract.
47. “THE FAST ZIP CODE WEBSEARCH” rings of marketing hype. It is clearly a web app and should obviously
be fast.
48. Use the application name ZIPPY. There is no mention of the application name on the popup.
49. The footnotes for * and ** are very small and hard to read for some users.
50. Align the input fields one under the other.
51. Vertical scrolling: what is beneath the fold?
52. Horizontal scrolling: what is over to the right?
53. The domain name in the email address is too long (fastzipcodewebsearch.com).
54. The domain name in the email address has nothing to do with UPS.
55. The background image is an irrelevant distraction.
2. WOULD YOU USE UNTESTED SOFTWARE? 8
56. The line “Click on the SUBMIT button to start your query” could be dispensed with, if the button label were
clearer.
57. The purpose of the email icons is unclear. Are they clickable or just decoration?
58. The two bulleted items are too close to one another and hard to distinguish, add some vertical spacing.
59. “City & State not required when a ZIP is given.” “not required” does not mean the same as “not allowed”. The
wording suggests it is OK to enter something in these fields, but not necessary.
60. “ZIP is an acronym for Zone Improvement Plan.” Exact acronym is probably irrelevant, at least relegate it to a
secondary page.
61. “GO HERE FOR A STATE ABBREV. LIST.” The wording “go here” is confusing to some users (especially sight-
impaired users using screen reader software). It would be better to use the phrase “state abbreviation list” as the

link source text.
62. The popup window is apparently not resizable. This might be a problem for users with large default font settings.
63. Consider not using a popup window at all, but simply moving forward to a new web page. The browser back
button would then return the user to the UPS page.
64. On the results page, the state is not displayed with each city.
65. On the results page, display both zip codes and their associated cities/states (one output format, regardless of input
format).
66. There is no indication how to print the result list.
67. The colour combination of green text on a green-blue background is difficult to read.
Help Users Recognize, Diagnose, and Recover from Errors
68. Do not use words like “illegal” in error messages. They intimidate the user.
69. If a required field is empty (state without city, city without state) indicate the precise condition in the error message.
70. If all three input fields are non-empty, there should be an appropriate error message.
71. If the user enters an invalid syntax, the error message should indicate what input was received and make a con-
structive suggestion.
72. If the system discovers that a (syntactically valid) ZIP code does not exist, precisely this should be indicated.
73. If a state does not exist, precisely this should be indicated.
74. If a city does not exist in a state (New York, Florida), a list of states where it does exist should be output.
75. “Please try again” is meaningless.
Help and Documentation
76. Provide links to further more detailed help.
77. Explain somewhere that large cities have multiple ZIP codes and that a single ZIP code sometimes covers several
neighbouring districts or towns.
78. Explain somewhere the valid syntax and formats for ZIP code, city, and state.
Conclusions from the ZIPPY Exercise
• Many designers and programmers have considerable difficulty in recognising serious interface problems in simple
but realistic dialogues.
• A revised ZIPPY display (see Figure 2.3) and a revised specification is needed.
• There are real web sites which do almost as bad a job as ZIPPY! See Figures 2.4, 2.5, and 2.6.
2. WOULD YOU USE UNTESTED SOFTWARE? 9

Figure 2.3: A suggestion for a revised ZIPPY display.
Figure 2.4: USPS Zip Code Lookup 1
2. WOULD YOU USE UNTESTED SOFTWARE? 10
Figure 2.5: USPS Zip Code Lookup 2
Figure 2.6: USPS Zip Code Lookup 3
2. WOULD YOU USE UNTESTED SOFTWARE? 11
2.2 MANTEL UI Exercise
• Exercise published as informal competition in Danish Computerworld, May 1988 by Rolf Molich and Jakob
Nielsen. [Prizes $700 software]
• Imagine that you are given a draft specification for MANTEL, the “Manhattan Telephone” enquiry system.
Your Task
• Wanted: list of usability problems MANTEL in UI draft specification.
• Hint: the authors of the study found a two-digit number of problems in the spec.
• To get you started, here is one of the usability problems found:
1. Spec. uses upper-case only, mixed case more readable.
2.
3.
• It is important to work individually!
How Many Potential Problems are there in MANTEL?
The interface specification for this simple system actually contains at least 29 (31 in Danish version) usability problems!
The problems are categorised according to Nielsen’s original set of usability heuristics [
Nielsen and Molich, 1990].
Those problems marked (Serious) may prevent some users from using the system in a meaningful way.
Simple and Natural Dialogue
1. Use of upper case letters only – mixed case is much more readable. Use upper case only for emphasis.
2. Avoid abbreviations if possible, “October” is preferable to “OCT”.
3. Spelling error: “SUBSCRIPER” should be “subscriber”. Spelling errors distract users and give impression of poor
quality.
4. The username is unnecessary info (date and time also).
5. The ‘>’ characters are mysterious. Maybe show field labels instead.

6. The blank lines in the middle of the information reduce readability. Suppress such blank lines.
7. The first name should be written before the last name, and in a single line (this is the natural ordering). User is not
interested in internal structure of database.
8. The function keys should be listed in a more logical order, e.g. numerically.
Speak the User’s Language
9. (Danish) Avoid use of English terms if proper Danish term exists.
10. (Danish) Use Danish national characters ‘æ’ and ‘ø’ instead of ‘
¨
a’ and ‘
¨
o’.
11. From USER=JOHNSMIT, system apparently truncates the user’s name to 8 chars. Unnatural abbreviation.
12. The info PORT073 and MANTEL INFO RELEASE 4.2 may be difficult to understand. Delete them or put them
in separate display and explain in more depth.
13. The notation PF1=HELP etc. may not be clear to novice users (though concise for experienced users) and there is
space enough for a more detailed notation.
14. Express questions from the user’s point of view. The initial question should not be “Enter desired telephone
number ” since user wants the name and address and not the telephone number. Better would be “Enter telephone
number for which you want name and address.”
2. WOULD YOU USE UNTESTED SOFTWARE? 12

PORT073 MANTEL INFO RELEASE 4.2 USER=JOHNSMIT 17-OCT-88 11:27:23
* * * * * * * * * * * * * * * * * * * * * * * *
C O M P U T E R T E L E P H O N E I N D E X
* * * * * * * * * * * * * * * * * * * * * * * *
THE SUBSCRIPER IS
>
>JONES
>JIM E.
>

>17 PINE STREET
>
>NEW YORK
>
>NY 10012
PF1=HELP PF2=DIRECTORY INFORMATION PF5=OTHER SERVICES
PF4=VIDEOTEX

Figure 2.7: The MANTEL display from the MANTEL UI draft specification.
Minimise the User’s Memory Load
15. (Serious) The telephone number entered by the user should be displayed with the subscriber info, in a format
well-known by the user and accepted as input.
Be Consistent
16. Several different terms are used for the same thing: NUMBER, TELEPHONE NO., and TELEPHONE NUMBER.
17. The specification does not state where error messages should be placed on the display. The location should be
fixed and consistent with the larger information system.
Provide Feedback
18. (Serious) A response time of 30 seconds is unacceptable. Tell the user what is going on: “Telephone number (203)
456-7890 is outside the 212 area code so it may take up to 30 seconds to retrieve the information”. Show that the
system is still working on the command every 5 seconds or so.
19. (Serious) The screen contains no information about what users should do once they have read the information and
want to continue.
Provide Clearly Marked Exits
20. (Serious) There is no indication of how users may exit from the system without answering the initial prompt to
enter a telephone number.
21. When users request info about a telephone number outside the 212 area code, the system may take up to 30 secs.
to retrieve the info. A facility should be provided for aborting the retrieval.
22. (Serious) The specification does not indicate whether the user can edit a partially entered telephone number. At
least Backspace should be supported.
2. WOULD YOU USE UNTESTED SOFTWARE? 13

Provide Shortcuts
• In the English version, it would be reasonable to accept input of 7 digits and assume an area code of 212 as default.
Provide Good Error Messages
23. Do not use words like “ILLEGAL” in error messages. They intimidate the user.
24. (Serious) The error message are too vague. The system should inform the user as exactly as possible about the
problem, e.g. if the area code is missing.
25. The system should report back how it has interpreted erroneous input. For example “The system cannot understand
the telephone number W3QV.” This is especially important for a system accessed via a modem and possibly noisy
telephone lines.
26. (Serious) The error messages are not constructive since they do not tell the user how to correct the error.
27. It is meaningless to ask the user to “Try Again!”. Drop this message altogether (or at least improve it).
Prevent Errors
28. Some users may be totally new to computers and unaware of the distinction between l and 1 or O and 0. If the
system encounters one of these letters where it expects a digit, it should provide a helpful message or simply
replace the letter by the corresponding digit.
29. (Serious) Instead of rejecting input containing parentheses around the area code or extra spaces, the system should
accept these common formats for telephone numbers.
30. Experience shows some novice users take the prompt “Enter number and RETURN” quite literally and type R-E-
T-U-R-N. It is better to write “ and press the RETURN key”.
31. Supplement theoretical terms with concrete examples. In the prompt “Enter telephone number and press the
RETURN key:”, an example telephone number would considerably increase the user’s understanding. Of course,
the example number should not be in use, or should be the Manhattan Telephone Operator.
Other Suggestions By Past Students of this Course
32. Remove the word “Computer” from the title, “Telephone Index” suffices, “Telephone Number Index” is perhaps
even better.
33. It would be helpful feedback to show an area name after the user has entered an area code.
34. The subscriber information should be centered on the screen for better readability.
35. Why is PF3 apparently not assigned? Should perhaps use PF1, PF2, PF3, and PF4.
36. Input fields and output areas could be designed to fit within one screen.
37. Since exactly 10 digits are allowed, it is not strictly necessary for the user to have to press the Return key. However,

it is probably a good idea, since it allows for a visual check before confirming the input and allows the omission
of the local area code.
38. Enter area code and number separately. Area code defaults to local area.
39. The two phrases “illegal number” and “unknown telephone number” are too similar to distinguish two different
error conditions.
40. There is no indication of what status the system is in, for example waiting for user input. A status indicator or
status bar could be used.
41. Put the PF key assignments at the top of the screen, since they are also at the top of the keyboard.
42. Provide a way for users to enter a further number. Or edit and resubmit the previous number.
43. The error message should indicate whether the area code is unknown (or wrong format) or the number.
2. WOULD YOU USE UNTESTED SOFTWARE? 14
44. Display Mr. or Ms. with the name to indicate gender, useful for non-native speakers of English who might not
recognise first names.
45. Be able to get a list of area names with their area codes, in case a user knows the area name but not the code.
46. Remove the asterisks from the title (decoration).
47. Information about purpose of system on initial screen: “This system allows you to enter a telephone number and
look up the associated subscriber.”
48. Perhaps indicate the kind of phone connection as well as the subscriber (standard, mobile, fax, isdn).
Results of the Published MANTEL Exercise
Results published in Comm. of the ACM, March 1990 [Molich and Nielsen, 1990].
• 77 designers and programmers from industry and academia participated (many entries were very professional in
appearance).
[These are the kind of people who are designing and writing the software we all use.]
• Several noted they had found the exercise worthwhile and rewarding in itself.
• The results are summarised in Table 2.1.
• The average number of problems mentioned was only 11.2 out of 30 (37%), even though grading was very liberal.
[not counting problem number 1]
• The winner mentioned 18 of 30 problems (60%).
• I found 12 problems, when I first did the exercise.
2. WOULD YOU USE UNTESTED SOFTWARE? 15

Problems Found in the MANTEL Exercise
Found
by %
Problem
Number
Description
95 15 Serious Redisplay input telephone number with subscriber information.
92 9 Avoid the use of English terms if Danish terms exist.
92 10 Use Danish national characters wherever possible.
77 4 Remove unnecessary information.
74 18 Serious Inform the user if it may take more than 30 secs. for a reply.
73 5 Avoid mysterious characters (¿), consider using field labels.
64 8 The function keys should be listed in a natural order.
64 24 Serious Error messages are too vague.
62 19 Serious The options available to the user should be displayed.
58 3 Avoid spelling errors.
52 7 The first name should be written before the last name.
42 26 Serious The error messages should be more constructive.
38 11 Do not distort information (user name) entered by the user.
32 12 Clarify or remove information that is difficult to understand.
29 23 The word ILLEGAL may intimidate the user.
27 30 “Enter number and RETURN” may be taken literally.
18 31 Show an example of a telephone number in the initial prompt.
17 6 Interspersed blank lines reduce the readability of an address.
16 14 Questions must be expressed from the user’s point of view.
14 25 The system should indicate how it has interpreted the user’s
input.
13 16 Three different terms are used for “Telephone Number”.
12 13 The meaning of the notation PF1=HELP is not clear to novices.
12 17 Coordinate placement of error messages with the rest of the

system.
12 27 The request “Try again” in an error message is meaningless.
9 2 Avoid the use of abbreviations.
9 28 Allow lower case L for 1 and letter O for 0.
8 29 Serious Accept parentheses, spaces, and hyphen in telephone number.
4 20 Serious There may be no exit from the initial prompt.
4 21 Serious There is no abort facility during a long retrieval.
1 22 Serious It may not be possible to edit input in the initial prompt.
Table 2.1: Summary of the 30 usability problems found in the MANTEL specification by 77
contestants.