AITutor

Computer Science Books/Sem7/Ue

intermediate

Computer Science Books/Sem7/Ue

– 1 of 377 –

Usability Engineering

– 2 of 377 –

This page intentionally left blank

– 3 of 377 –

Usability Engineering JAKOB NIELSEN SunSoft 2550 Garcia Avenue Mountain View, California ~ .O F £ S S \ O ~ AP PROFESSIONAL Boston San Diego New York London Sydney Tokyo Toronto

– 4 of 377 –

This book is printed on acid-free paper. @ Copyright © 1 9 9 3 by A c a d e m i c Press, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording, or any information storage and retrieval system, without permission in writing from the publisher. All brand names and product names mentioned in this book are trademarks or registered trademarks of their respective companies. AP P R O F E S S I O N A L 9 5 5 Massachusetts Avenue, Cambridge, MA 0 2 1 3 9 An Imprint of A C A D E M I C P R E S S , INC. A Division of H A R C O U R T B R A C E & C O M P A N Y United Kingdom Edition published by A C A D E M I C P R E S S L I M I T E D 2 4 - 2 8 Oval Road, London NW1 7 D X I S B N 0 - 1 2 - 5 1 8 4 0 6 - 9 Printed in the United States of A m e r i c a 9 4 9 5 9 6 9 7 B B 9 8 7 6 5 4 3 2 1

– 5 of 377 –

Table of Contents Preface ix Audience ix Teaching Usability Engineering xi Acknowledgments xiii Chapter 1 Executive Summary 1 1.1 Cost Savings 2 1.2 Usability Now! 8 1.3 Usability Slogans 10 1.4 Discount Usability Engineering 17 1.5 Recipe For Action 21 Chapter 2 What Is Usability? 23 2.1 Usability and Other Considerations 24 2.2 Definition of Usability 26 2.3 Example: Measuring the Usability of Icons 37 2.4 Usability Trade-Offs 41 2.5 Categories of Users and Individual User Differences 43 ν

– 6 of 377 –

U s a b i l i t y E n g i n e e r i n g C h a pt e r 3 Generations of User Interfaces 49 3.1 Batch Systems 51 3.2 Line-Oriented Interfaces 52 3.3 Full-Screen Interfaces 54 3.4 Graphical User Interfaces 57 3.5 Next-Generation Interfaces 62 3.6 Long-Term Trends in Usability 67 Chapter 4 The Usability Engineering Lifecycle 71 4.1 Know the User 73 4.2 Competitive Analysis 78 4.3 Goal Setting 79 4.4 Parallel Design 85 4.5 Participatory Design 88 4.6 Coordinating the Total Interface 90 4.7 Guidelines and Heuristic Evaluation 91 4.8 Prototyping 93 4.9 Interface Evaluation 102 4.10 Iterative Design 105 4.11 Follow-Up Studies of Installed Systems 109 4.12 Meta-Methods 111 4.13 Prioritizing Usability Activities 112 4.14 Be Prepared 113 C h a p t e r s Usability Heuristics 115 5.1 Simple and Natural Dialogue 115 5.2 Speak the Users’ Language 123 5.3 Minimize User Memory Load 129 5.4 Consistency 132 5.5 Feedback 134 5.6 Clearly Marked Exits 138 5.7 Shortcuts 139 5.8 Good Error Messages 142 5.9 Prevent Errors 145 5.10 Help and Documentation 148 5.11 Heuristic Evaluation 155 vi

– 7 of 377 –

T a b l e o f C o n t e n t s Chapter 6 Usability Testing 165 6.1 Test Goals and Test Plans 170 6.2 Getting Test Users 175 6.3 Choosing Experimenters 179 6.4 Ethical Aspects of Tests with Human Subjects 181 6.5 Test Tasks 185 6.6 Stages of a Test 187 6.7 Performance Measurement 192 6.8 Thinking Aloud 195 6.9 Usability Laboratories 200 Chapter 7 Usability Assessment Methods beyond Testing 207 7.1 Observation 207 7.2 Questionnaires and Interviews 209 7.3 Focus Groups 214 7.4 Logging Actual Use 217 7.5 User Feedback 221 7.6 Choosing Usability Methods 223 Chapter 8 Interface Standards 227 8.1 National, International and Vendor Standards 231 8.2 Producing Usable In-House Standards 233 Chapter 9 International User Interfaces 237 9.1 International Graphical Interfaces 239 9.2 International Usability Engineering 242 9.3 Guidelines for Internationalization 247 9.4 Resource Separation 251 9.5 Multilocale Interfaces 253 vii

– 8 of 377 –

U s a b i l i t y E n g i n e e r i n g Chapter 10 Future Developments 255 10.1 Theoretical Solutions 256 10.2 Technological Solutions 260 10.3 CAUSE Tools: Computer-Aided Usability Engineering 264 10.4 Technology Transfer 265 A p p e n d i x A A p p e n d i x Β Exercises 269 Bibliography 283 B.l Conference Proceedings 284 B.2 Journals 286 B.3 Introductions and Textbooks 290 B.4 Handbook 291 B.5 Reprint Collections 292 B.6 Important Monographs and Collections of Original Papers 294 B.7 Guidelines 300 B.8 Videotapes 302 B.9 Other Bibliographies 304 B.10 References 306 Author Index 341 Subject Index 351 viii

– 9 of 377 –

Preface Software developed in recent years has been devoting an average of 48% of the code to the user interface [Myers and Rosson 1992]. It would thus seem justified to allocate a reasonable proportion of the effort in software development projects to ensuring the usability of these user interfaces. This book tells you what to do if you decide to improve usability. The main goal of the book is to provide concrete advice and methods that can be systematically employed to ensure a high degree of usability in the final user interface. To arrive at the perfect user interface, one also needs genius, a stroke of inspiration, and plain old luck. Even the most gifted designers, however, would be pressing their luck too far if they were to ignore systematic usability engineering methods. Audience The book has a very wide intended audience. First of all, it is natu- rally intended for the people who actually design and develop computer systems and user interfaces since these individuals have the ultimate power to improve usability. The book is crammed with practical advice for including usability considerations in the ix

– 10 of 377 –

U s a b i l i t y E n g i n e e r i n g software engineering process, and developers and project managers should read through the entire book. The book is also intended for people who design documentation, help systems, and training courses, since these are elements of the “total user inter- face” just as much as the screen designs. This book is not intended to teach technical writing as such, but it can help writers produce support materials that users will find easier to use. Furthermore, large parts of the book should be helpful to the users themselves and to computer support managers who need to deter- mine which computer systems and software to recommend to their users. Even though it is fairly rare for customer organizations to perform their own usability testing, there is no reason why a large organization should not use some of the techniques in Chapter 6, Usability Testing, to compare software packages and whole systems before deciding on what to buy. Smaller organizations and individual users can use the definitions in Chapter 2, What Is Usability?, and the usability principles in Chapter 5, Usability Heuristics, as a checklist to consider whether an interface seems usable before buying it. Multinational corporations and other inter- national organizations should benefit from Chapter 9, International User Interfaces, when planning the requirements for their informa- tion systems. Finally, user organizations that contract out for soft- ware development can use Chapter 4, The Usability Engineering Lifecycle, and Chapter 8, Interface Standards, to help set require- ments that will ensure the usability of the product they will eventu- ally receive from their vendor. The executive summary in Chapter 1 is intended to help those readers who may not have time to read the entire book. It is espe- cially intended for managers who are considering whether their companies are devoting sufficient effort to usability and what concrete steps they can request to ensure improved usability of their systems. It should be read by all readers, however, as it is not just a summary; it also addresses several topics that are not covered in the rest of the book, such as the cost/benefit trade-offs of taking human factors seriously χ

– 11 of 377 –

P r e f a c e Most of the examples in the book come from user interfaces to computer systems. The methods can be used for the development of interfaces to any kind of interactive system, including most consumer electronics products, and they are even useful for the development of certain information-intensive types of noninterac- tive products such as computer printouts, time tables, and driving directions. For example, van Nes and van Itegem [1990] describe the use of a logging method (see also page 216 ff.) in a usability study of an advanced car radio with 37 functions. For half a year, four drivers had every use of practically all of these functions from their new car radio automatically recorded. The results showed that some of the novel features went unused and that others were used differently than the designers had intended. A follow-up user interview revealed that the users still had not understood some features after half a year of use. One user complained that the auto- search tuning mechanism skipped some radio stations, whereas in fact it operated at three successive sensitivity levels and would pick up the missing stations at the second or third scan. Any object, product, system, or service that will be used by humans has the potential for usability problems and should be subjected to some form of usability engineering. Human-computer interaction serves as the main focus of this book because it is the author’s special area of expertise and because the potential for usability problems seems to be especially severe in computers, due to their ability to implement complex features and intricate interac- tions. For other kinds of interfaces, slight modifications may have to be made, but the main principles in this book should still hold. For example, questionnaires and user testing have been applied to improve the usability of railroad cars [McCrobie 1989]. Teaching Usability Engineering Several universities have developed both traditional courses and continuing education efforts in various aspects of human- computer interaction [Baecker 1989; Carey 1989; John et al. 1992; Mantei 1989; Mantei et al 1991; Preece and Keller 1990,1991; Strong xi

– 12 of 377 –

U s a b i l i t y E n g i n e e r i n g 1989; van der Veer and White 1990]. The Association for Computing Machinery’s Special Interest Group on Computer- Human Interaction (ACM SIGCHI) has even developed a recom- mended curriculum for the teaching of human-computer interac- tion [ACM SIGCHI 1992]. Typical topics covered in such courses include theoretical approaches to human-computer interaction, the implementation of user interfaces, and the actual design of user interfaces. The latter is often taught through exercises [Nielsen et al. 1992; Winograd 1990]. In a survey of skills needed by usability practitioners [Dayton et al. 1993], the four skills rated as having an importance of more than 9.0 on a 1-10 scale were oral presentation, dialogue design, task analysis, and usability evaluation. The pres- ence of presentation skills at the top of the list indicates that no usability project is conducted in isolation: to be successful, it needs to impact a larger development team. Usability engineering as such also seems to be taught more these days, either as part of a general HCl (human-computer interaction) course or as a course in its own right [Nielsen and Molich 1989; Perlman 1988, 1990]. This is especially true of courses taught by corporate training departments or offered as continuing education for software engineers. My main advice for the teaching of usability engineering would be to base the course firmly in the laboratory. Even though there is a substantial amount of theory and principles that can be taught in the auditorium, the most important aspects of design and evalua- tion require a hands-on approach. Certainly, a required part of any usability engineering course should be to have the students conduct a user test with a small number of real users. Not only is this a good way to teach proper evaluation methodology, but more important, it is the only way to achieve the required revolutionary change in student attitudes. Most professional programmers and computer science students gain profound insights the first time they actually sit down with test users and observe them struggle with supposedly “easy” software. This is especially true if the soft- ware was designed by the programmers or students themselves! xii

– 13 of 377 –

P r e f a c e Appendix A lists several practical exercises touching upon impor- tant aspects of usability engineering. The way these exercises are described is mostly intended for self-study readers, but they can easily be expanded into more elaborate assignments for class use. Acknowledgments Many colleagues graciously answered questions about specific issues, provided comments on the treatment of their special inter- ests, or even read through the entire manuscript. For this help, I would like to thank Jeff Abbott (Tivoli Systems), David Ackley (Bellcore), Alfred V. Aho (Bellcore), Gregory H. Anderson (Anderson Financial Systems), Mary M. Anthony (Tivoli Systems), Sonia D. Bot (Bell-Northern Research, Canada), Andreas Buja (Bellcore), Mike Coble (TRIPOS Associates), Bill Curtis (Software Engineering Institute), Tom Dayton (Bellcore), Susan T. Dumais (Bellcore), Lawson J. Dumbeck (Western Washington University), Tom Emerson (Symantec Corporation), Peter W. Foltz (University of Colorado), Ellen Francik (Pacific Bell), George Furnas (Bellcore), Marc Fusco (Bellcore), Thorn Gillespie (University of California, Berkeley), Michael Good (Digital Equipment Corporation), Peter Henriksen (Microsoft), Hiroshi Ishii (NTT Human Interface Labo- ratories, Japan), Robert E. Jackson (Space Telescope Science Insti- tute), Janice James (American Airlines), Jeff Johnson (Hewlett- Packard Laboratories), Peter R. Jones (Symantec Corporation), Anker Helms j0rgensen (Copenhagen University, Denmark), Hannah Kain (Citibag), Alistair Kilgour (Heriot-Watt University, U.K.), Thomas K. Landauer (Bellcore), Jonathan Levy (Bellcore), Robert L. Mack (IBM T. J. Watson Research Center), Miles Macleod (Hatfield Polytechnic, U.K.), Deborah J. Mayhew (Deborah J. Mayhew & Associates), Rolf Molich (Baltica Insurance, Denmark), Michael Muller (U S WEST), Robert M. Mulligan (AT&T Bell Labo- ratories), Gerhard Nielsen (Denmark’s Radio), Randy Pausch (University of Virginia), Gary Perlman (Ohio State University), Steven Poltrock (Boeing Computer Services), Dan Rosenberg (Borland International), Kjeld Schmidt (Riso National Laboratory, Denmark), David Schnepper (Borland International), Tom Semple xiii

– 14 of 377 –

U s a b i l i t y E n g i n e e r i n g (Symantec Corporation), Brian Shackel (Loughborough University of Technology, U.K.), Ben Shneiderman (University of Maryland), Scott Stornetta (Bellcore), Kurt Sussman (Symantec Corporation), Désirée Sy (Information Design Solutions), Michael Tauber (University of Paderborn, Germany), Bruce Tognazzini (SunSoft), Hirotada Ueda (Hitachi Central Research Laboratory and FRIEND21 Research Center, Japan), Gerrit van der Veer (Free University of Amsterdam, The Netherlands), Floris L. van Nes (Institute for Perception Research/Philips Research Laboratories, The Netherlands), Robert Virzi (GTE Laboratories), Christopher A. White (GTech Corporation), Richard Wolf (Lotus Development Corporation), and Peter Wright (University of York, U.K.). The resulting book is solely the responsibility of the author, and the people mentioned above should not be held responsible for the way I have interpreted their comments and advice. Most of this book was written while I was on the applied research staff of Bellcore but it should not be taken as necessarily representing any official views or policies of Bellcore. This printing of the book has been updated with a number of liter- ature references and comments on developments since the book was first published. Among other things, I added the new synergy review method, which I invented just a few weeks after sending in the final copy for the first printing. Mostly, the book is unchanged, though, since the basics of usability engineering remain fairly constant and do not vary from year to year. Jakob Nielsen Mountain View, California April 1994 xiv

– 15 of 377 –

Chapter 1 Executive Summary Have you ever seen one of the people who will be users of your current project?1 Have you talked to such a user? Have you visited the users’ work environment and observed what their tasks are, how they approach these tasks, and what pragmatic circumstances they have to cope with? Such simple user-centered activities form the basis of usability engineering. More advanced methods exist and are covered later in this book, but just a simple field trip to observe users in their own environment working on real-world tasks can often provide a wealth of usability insights. In one example, three one-day visits to branch offices of a medium- sized insurance company produced a list of 130 usability problems [Nielsen 1990b]. The system design was sound, and most of the problems were simple enough to fix once they were known (but, of course, they would not have been known if it had not been for the field study). Many of the 130 items were serious problems only for novice users. However, even very experienced users were esti- mated to waste at least 10 minutes every day because of usability

  1. Note that you have to talk to the individuals who will be using the system. Talking to the users’ manager or vice president for data processing does not count since these people are likely to have a completely different under- standing of the job than the actual users. 1

– 16 of 377 –

U s a b i l i t y E n g i n e e r i n g problems, costing the company large amounts of money in both labor costs and lost sales opportunities. The staff was often interrupted by telephone calls or walk-in clients. Unfortunately, several subsystems were not designed for interruptions—users lost all of their work if a transaction was not carried to completion. At one small branch, an agent stated that she never used the damage-claims subsystem during periods where she was the only person in the office and had to answer all calls. In some cases, agents were observed using other agents’ terminals (and “borrowing” their passwords) to deal with interruptions rather than quit one of the unforgiving subsystems in the middle of a transaction. In another case, the system allowed only one line for error messages, so it had to give an obscure, truncated version of a long message. The full message was available by pressing the help key, PF1, an action the developers in the central data-processing office felt was very natural. But users in the branch office had not made the conceptual leap that told them the help key was doubling as an extended-error-message key. Instead, they wasted a lot of time trying to understand the truncated message. A better design would have used the one line on the screen for a brief indication of the error, followed by “PF1 for more information” or a similar instruction. 1.1 Cost Savings There are several well-documented examples of cost savings from the use of usability engineering methods. For example: • When a certain rotary dial telephone was first tested, users were found to dial fairly slowly. A human factors expert spent one 2. There are more examples of cost savings that are less well documented. As noted by Chapanis [1991], most case studies fail to meet the rigorous method- ological requirements that are necessary to be absolutely sure what cost savings can be attributed to user interface improvements since there are often several other changes made simultaneously (e.g., [Thompson et al. 1986]). 2

– 17 of 377 –

E x e c u t i v e S u m m a r y hour to come up with a simple graphical interface element which speeded up users’ dialing behavior by about 0.15 seconds per digit, for a total annual saving of about $1,000,000 in reduced demands on the central switches [Karlin and Klemmer 1989]. • An Australian insurance company had annual savings of A$536,023 from redesigning its application forms to make customer errors less likely [Fisher and Sless 1990]. The cost of the usability project was less than A$100,000. The old forms were so difficult to fill in that they contained an average of 7.8 errors per form, making it necessary for company staff to spend more than one hour per form repairing the errors. • A major computer company saved $41,700 the first day the system was in use by making sign-on attempts faster for a secu- rity application. This increased usability was achieved through iterative design at a cost of only $20,700 [Karat 1990]. • The 25 “human factors success stories” discussed by Harris [1984] include the improvement of the Boeing 757 flight deck interface to allow operation by two instead of three pilots, the 35% increase in alignment speed in a production line for inte- grated circuits, the reduction from 3,000 words to 150 words of instructions needed to operate a paging device, and even an improvement in a drunk-driver detection system that increased the arrest rate per police officer patrol-hour by 12%. Unfortunately, the cost savings from increased usability are not always directly visible to the development organization since they may not show up until after the release of the product. As an extreme example, Fisher and Sless [1990] report that the Australian government can process a tax return for A$2.25 on the average. At the same time, the average Australian resident spends 11 hours filling in the form, and 62% of Australians have to use agents to help do the job. If the complexity of the tax forms were reduced, these “customers” might therefore realize huge savings in time and advisor fees, but the government might only save a few cents in processing costs. In the same way, making a spreadsheet easier to learn might only save the vendor a small amount in reduced hotline staffing levels, even though each customer might save several hours of unnecessary work. 3

– 18 of 377 –

U s a b i l i t y E n g i n e e r i n g Distributed benefits of a few hours per user are hard to measure and do not immediately add up to hard cash [Sassone 1987]. For example, redesigning the interface to an oscilloscope increased user productivity by 77% during the time they were using the scope [Bailey et al 1988], but the productivity impact on the total workday of an engineer was much less dramatic and therefore had less impact. The customers do save with better interfaces, though, and these savings presumably translate into a better reputation for the product and therefore eventually increase sales. Unfortunately, the effect of having increased usability lead to increased sales has mostly been documented only anecdotally.3 In several cases, the relative usability of competing products is well known in the industry, and computer salespersons often recommend certain soft- ware packages on the basis of their usability. Because much of the financial payoff from usability methods shows up after the release of the product, some usability specialists [Grudin et al. 1987] have advocated shifting parts of the responsi- bility for usability engineering toward middle and upper manage- ment levels instead of the development managers. Even the development manager may see some immediate benefits from usability engineering, however, in the frequent case when early usability studies reveal that there is no need for certain contem- plated features. If users’ needs are not known, considerable devel- opment efforts may be wasted on such features in the mistaken belief that some users may want them. Users rarely complain that a system can do too much (they just don’t use the superfluous features), so such over-design normally does not become suffi- ciently visible to make the potential development savings explicitly known. They are there nevertheless. 3. In one of the few documented cases, a usability study of the first version of a fourth-generation database system revealed 75 usability problems. Twenty of the most serious problems were fixed in the second release, which gener- ated 80% higher product revenues than the first release [Wixon and Jones 1994]. This revenue increase was 66% higher than sales projections and so is probably due to the improvements in usability since field test customers were reported to point to the user interface as the most significant improvement in the product. 4

– 19 of 377 –

E x e c u t i v e S u m m a r y Usability studies can often be conducted very quickly and with small budgets. For example, Bailey [1991] gives an example of a study that required no more than five and a half hours to find out that the addition of color did not help users in a certain menu selec- tion task. A development group could easily have spent many more staff hours arguing over this design issue in meetings than it took to resolve it by testing. A study of software engineering cost estimates showed that 63% of large software projects significantly overran their estimates [Lederer and Prasad 1992]. When asked to explain their inaccurate cost estimates, software managers cited 24 different reasons and, interestingly, the four reasons that were rated as having the highest responsibility were all related to usability engineering: frequent requests for changes by users, overlooked tasks, users’ lack of understanding of their own requirements, and insufficient user- analyst communication and understanding. Proper usability engi- neering methodology will prevent most such problems and thus substantially reduce cost overruns in software projects. Even though the use of usability methods definitely involves some benefits, some managers might hesitate to use them because of their perceived high cost and complexity. For example, a paper in the widely read and respected journal Communications of the ACM estimated that the “costs required to add human factors elements to the development of software” was $128,330 [Mantei and Teorey 1988]. This sum is several times the total budget for usability in most smaller companies, and one interface evangelist has actually found it necessary to warn such small companies against believing this estimate [Tognazzini 1990]. Otherwise, the result could easily be that a project manager would discard any attempt at usability engineering in the belief that the project’s budget could not bear the cost. Luckily, usability projects can easily be completed at substantially lower budgets as discussed in the section on Discount Usability Engineering (page 16). This entire book is aimed at presenting usability methods that can be used no matter what budget is available. 5

– 20 of 377 –

U s a b i l i t y E n g i n e e r i n g Bottom Quartile (Qi) Median (Q2) Top Quartile (Q3) Project size in person-year 11 23 58 Actual usability budget relative to total 4 % 6% 15% Ideal usability budget relative to total 6% 10% 2 1 % Actual usability effort in person-years 1.0 1.5 2.0 Ideal usability effort in person-years 1.7 2.3 3.8 Table 1 Results from α survey of the usability budgets of 31 development projects that had usability engineering activities. In January 1993, I surveyed 31 development projects that had usability engineering activities to find how much of their budget was devoted to usability. Respondents were also asked to estimate how large the usability budget ideally should be for their project. The results are shown in Table 1 and indicate that usability accounted for about 6% of the budgets for these projects and that the respondents felt that the ideal usability budget would have been 10%. The ideal desired usability effort in person-years is essentially independent of project size (r = .12) when three very large outlier projects of 250-350 person-years are excluded from the analysis. This result makes some sense in that many usability activities take about the same time to perform, no matter how diffi- cult the program is to implement. Very large systems may have more elements in their user interfaces (screens, dialogue boxes, menus, etc.), meaning that they may need somewhat more time for usability activities, though definitely not proportionally more. The main conclusion to be derived from Table 1 is thus that two person- years of usability engineering is the median effort to aim for in a project and that four person-years would be sufficient for most projects. Of course, the actual amount of usability work needed in a project will depend on the characteristics of the project. In a study of several corporations, Wasserman [1989] found that many leading companies allocated about 4-6% of their research 6

– 21 of 377 –

E x e c u t i v e S u m m a r y and development staff to interface design and usability work. He believes that 2% is the critical lower limit for designing competi- tively effective products but acknowledges that many companies are significantly below that level. There is not necessarily a conflict between Wasserman’s findings and Table 1. First, the survey in Table 1 is more recent, and usability has increased in importance in recent years.4 Second, my survey only involved those projects in the various companies that have active usability engineering efforts, and many companies still have some projects without any usability engineering activities, which would contribute to making their overall usability budgets smaller than the usability budgets for those projects that had usability activities. The final budget recommendation for any given product or company would of course depend on the specific nature of the projects. If a product is aimed at the population at large, then a substantial usability effort is probably necessary to ensure broad acceptance of the product. Similarly, a product that is going to see substantial daily use in a business can also cost-justify a large usability investment from the expected savings. And finally, one would normally recommend a rather limited5 ^ usability effort for systems that are only going to be used by a small number of highly skilled and trained users.6 When considering usability budgets, remember that your system will be tested for usability even if you don’t do so yourself. Your customers will do it for you, as they struggle to use the system. Any usability problems found by users in the field will undermine 4. A 1971 paper estimated that a reasonable level for usability budgets for non-military systems was about 3% [Shackel 1971], providing some additional evidence that usability has increased in budget share over the years. 5. ’’Limited77 does not mean “nonexistent/7 however. There is always a payoff to be gained from applying a few, cheap usability methods. 6. For certain applications such as a tactical support system for a fighter pilot or the control room for an expensive or dangerous plant, small differences in user performance can be a matter of life or death, and major usability efforts may be called for even though the users are few and highly trained. Two thirds of aircraft accidents can be attributed to the cockpit crew rather than to equipment malfunction and thus could potentially have been avoided with better human factors [Nagel 1988]. 7

– 22 of 377 –

U s a b i l i t y E n g i n e e r i n g your reputation for quality products and the resulting change requests will be about 100 times more expensive to implement than changes discovered by yourself in the early phases of the project. 1.2 Usability Now!7 User interfaces are now a much more important part of computers than they used to be. The revolution in personal computers and falling hardware prices are making computers available to ever broader groups of users, and these users are using computers for a larger variety of tasks. When computers were only used by a small number of people who mostly performed very specialized tasks, it made sense to require a high degree of learning and expertise of the users. Also, computers were once so expensive that it was reasonable to let users suffer a little if the computer could be utilized more efficiently. Now it pays to dedicate a large proportion of the computational resources (CPU cycles, memory use, commu- nication bandwidth, screen space, development effort) to “nothing else” than making life easier for the user. Furthermore, video games and some of the better personal computer software have shown users that it is possible to produce pleasant and approachable interfaces, so they are becoming much less willing to suffer from low usability. Business Week had a cover story in 1991 entitled “i Cant Work This ?#!!@ Thingl” [Nussbaum and Neff 1991], reporting on consumer dissatisfaction with over- complex interfaces on video recorders and other gadgets and that several major companies were redesigning their products to make them easier to use. Time itself is on the side of increasing the perceived need for usability since the software market seems to be shifting away from the “features war” of earlier years [Telles 1990]. User interface design and customer service will probably generate more added 7. After writing my first draft of this section, I learned that the U.K. Depart- ment of Trade and Industry (DTI) has a research and development program that also is called Usability Now! [Wiggins 1991]. So much the better. 8

– 23 of 377 –

E x e c u t i v e S u m m a r y value for computer companies than hardware manufacturing [Rappaport and Halevi 1991], and user interfaces are a major way to differentiate products in a market dominated by an otherwise homogenizing trend toward open systems. Now most software products have more features than users will ever need or learn, and Telles [1990] states that the “interface has become an important element in garnering good reviews” of software in the trade press.8 In an unpublished study from 1990, Tim Frank Andersen from the Technical University of Denmark read 70 reviews of software prod- ucts in various personal computer magazines and counted 784 comments on the usability of the reviewed software. This is an average of 11.2 usability comments per software review. Now, many of these comments were fairly superficial, but their sheer number indicates the importance of usability in today’s market- place. If anything, usability has increased in importance in soft- ware reviews since the 1990 study to the extent that some personal computer magazines now have usability laboratories for use in comparative testing of software products and include usability statistics like average task times in their reviews [Reed 1992]. Recently, we have even seen political demands for regulations with respect to usability. Currently, most such political initiatives seem to be directed toward hardware ergonomics, but some also include software usability. As further discussed in Chapter 8, several inter- national user interface standards are currently being developed. These standards may well gain the force of law in certain countries and will certainly have great impact in many other countries [Stewart 1990]. The European Union has passed a directive9 on work with display screens stating that since December 31,1992, 8. The trade magazine InfoWorld assigns explicit weights in its software reviews: Ease of learning is weighed at 4-10%, ease of use at 8-13%, and quality of documentation at 5-8%, with the exact weights determined by the type of application being reviewed. These three review criteria account for between 18% (spreadsheets) and 3 0 % (word processors) of the final review scores. Error handling is assigned a further 5 - 8 % of the review weight as a combined category including both user errors (a usability issue), software bugs, and recovery from hardware crashes. Notice, by the way, how favorably these percentages compare with the allocation of 6 - 1 0 % of a development project’s budget to usability mentioned on page 6; usability is a comparatively cheap way to improve product quality. 9

– 24 of 377 –

U s a b i l i t y E n g i n e e r i n g • Software must be suitable for the task • Software must be easy to use • The principles of software ergonomics must be applied for all display screen workstations (computers and such) put into service in the E.U. Even though the requirements are very general in nature, they still indicate the direction of the political pressure for increased usability. 1.3 Usability Slogans Major parts of the usability approach in this book can be summa- rized in the short slogans given here. You will find that some of the slogans contradict each other. Unfortunately, usability is filled with apparent contradictions that are only resolved after more detailed analysis. Some contradictions and trade-offs will always remain, and it is the job of the usability engineer to arrive at the best solu- tion for the individual project’s needs. There are very few hard and firm rules in usability that do not have some exceptions. For the full story, read on. Your Best Guess Is Not Good Enough A basic reason for the existence of usability engineering is that it is impossible to design an optimal user interface just by giving it your best try. Users have infinite potential for making unexpected misin- terpretations of interface elements and for performing their job in a different way than you imagine. Your design will be much better if you work on the basis of an understanding of the users and their tasks. Then, by all means design the best interface you can, but make sure to validate it with user tests and the other methods recommended in this book. It is no shame to have to revise a user interface design as a result of user 9. Council Directive of May 29, 1990, on the minimum safety and health requirements for work with display screen equipment ( 9 0 / 2 7 0 / E E C ) , Official Journal of the European Communities No. L 1 5 6 , 21.6.1990,14-18. 10

– 25 of 377 –

E x e c u t i v e S u m m a r y testing. This happens to the best of usability experts, and it might indeed be a true measure of usability maturity that one is willing to acknowledge the need to modify initial design choices to accom- modate the users. Julius Caesar is widely acknowledged as one of the greatest generals of antiquity. Even so, his true talent was not perfect campaign planning but his ability to adjust to the situation as it evolved. He often placed his legions in highly problematic situations which they only survived because he changed his plans to accommodate the facts. If Caesar could conquer France by admitting his mistakes [Caesar 51 B.C.], then maybe you can win some market share by admitting yours. The User Is Always Right As mentioned, all experience shows that any initial attempt at a user interface design will include some usability problems. There- fore, the user interface developer needs to acquire a certain design humility and acknowledge the need to modify the original design to accommodate the user’s problems. The designer’s attitude should be that if users have problems with an aspect of the inter- face, then this is not because they are stupid or just should have tried a little harder. Somebody once tested the usability of a user manual and found that users almost always made a mistake in a certain step of a particular procedure. Their solution was to frame the difficult step in a box and add a note saying “Read these instruc- tions carefully!” Of course, the correct conclusion would have been that the description was too difficult and should be rewritten. The User Is Not Always Right Unfortunately, it does not follow that user interface designs can be derived just by asking users what they would like. Users often do not know what is good for them. One example is a study of the weight of telephone handsets conducted in the 1950s when people were used to fairly heavy handsets. The result of asking users whether they would like lighter handsets was no, they were happy with the handsets they had [Karlin and Klemmer 1989]. Even so, a test of handsets that looked identical but had different weights showed that people preferred handsets with about half the then- normal weight. 11

– 26 of 377 –

U s a b i l i t y E n g i n e e r i n g Users have a very hard time predicting how they will interact with potential future systems with which they have no experience. As another example, 73% of the respondents in a survey of 9,652 commuters said that they would not use a proposed information service with continual up-to-the-minute traffic information. But after they were shown sample screens from a prototype of the service, 84% of the respondents said that they would in fact use it [Gray et al 1990]. Furthermore, users will often have divergent opinions when asked about details of user interface design. For example, studies of how people name things [Furnas et al 1987] have shown that the proba- bility of having two people apply the same name to an object is between 7% and 18%, depending on the object, clearly making it infeasible to design command names just by asking some user. Users Are Not Designers The ideal solution to the usability question might be to leave the design of the interface up to the individual users. Just provide sufficient customization flexibility, and all users can have exactly the interface they like. Studies have shown, however, that novice users do not customize their interfaces even when such facilities are available [j0rgensen and Sauer 1990]. One novice user exclaimed, “I didn’t dare touch them [the customization features] in case something went wrong.” Therefore, a good initial interface is needed to support novice users. Expert users (especially programmers) do use customization features, but there are still compelling reasons not to rely on user customization as the main element of user interface design. First, customization is easy only if it builds on a coherent design with good previously designed options from which to choose. Second, the customization feature itself will need a user interface and will thus add to the complexity of the system and to the users’ learning load. Third, too much customization leads each user to have a wildly different interface from the interfaces used by other users. Such interface variety makes it difficult to get help from colleagues, even though that is the help method rated highest by 12

– 27 of 377 –

E x e c u t i v e S u m m a r y both novice and expert users [Mack and Nielsen 1987]. And fourth, users may not always make the most appropriate design decisions. For example, Grudin and Barnard [1985] compared command abbreviations they defined with abbreviations defined by indi- vidual users, and found that users made about twice as many errors when using their own abbreviations. Even when given the chance to redefine their abbreviations after the experiment, six of seven test users kept their poor abbreviation sets virtually intact, typically explaining that while yes, they had some problems with it, it seemed as good as any other set they could think of. Of course, users have other jobs and do not work as user interface profes- sionals. Designers Are Not Users System designers are human and they certainly use computers: both characteristics of users. Therefore, it can be tempting for designers to trust their own intuition about user interface issues, since they do share these two important characteristics of the real users. Unfortunately, system designers are different from users in several respects, including their general computer experience (and enthusiasm) and their knowledge of the conceptual foundation of the design of the system. When you have a deep understanding of the structure of a system, it is normally easy to fit a small extra piece of information into the picture and interpret it correctly. Consequently, a system designer may look at any given screen design or error message and believe that it makes perfect sense, even though the same screen or message would be completely incomprehensible to a user who did not have the same under- standing of the system. Knowing about a system is a one-way street. One cannot go back to knowing nothing. It is almost impossible to disregard the informa- tion one already knows when trying to assess whether another piece of information would be easy to understand for a novice user. Landauer [1988b] uses a hidden animal picture as an analogy for developers’ understanding of their own system. Hidden animal games, as well as popular children’s books of the type, “Where is so- and-so?” show images with various levels of details, among which 13

– 28 of 377 –

U s a b i l i t y E n g i n e e r i n g is the animal or character one is supposed to find. Initially, it is very difficult to pick the animal out of the background, but once you have seen where the animal is, it is very easy to see it again. In fact, it is impossible to ignore one’s knowledge of where the animal is and regain a perspective on the picture where one would have to search to find the animal. A survey of 2,000 adults in Oregon showed that only 18% could use a bus schedule to find the time of departure [Egan 1991]. This finding does not indicate that the remaining 82% of Oregonians are less intelligent and should never be allowed on a bus.1 0 Instead, the likely explanation is that the bus schedule was designed by people with extensive knowledge of buses and local transportation who just knew the meaning of every element on the schedule, and there- fore never considered that parts of it might be difficult to under- stand for people who rarely take a bus. Vice Presidents Are Not Users Many CEOs and other top corporate executives have started to realize that usability is becoming one of their main competitive parameters, as user interfaces account for a steadily higher propor- tion of the value added in their products and services [Sculley 1992]. The downside of this higher visibility for user interfaces is that these executives may start meddling in user interface design. Vice presidents and other corporate executives should realize that they are no more representative of the end users than the devel- opers are. With the possible exception of management information systems and other software intended for vice presidents, corporate executives in a high-tech company are very different from the average user, and their intuitions about what would make a great design may not be accurate. Boies et al. [1985] report that they sometimes had “a powerful person” in their company propose changes to their interface. They avoided making these changes by pointing out that this person 10. The same test showed that 97% of Oregonians could read a newspaper article and that 96% could tabulate two entries on a bank deposit slip. 14

– 29 of 377 –

E x e c u t i v e S u m m a r y probably had very different characteristics than the intended users and that their design had been tested on such real users. Of course, all design suggestions should be welcomed in order to serve as inspiration, but one should never be unduly swayed by a comment from a single person. People get promoted to vice president because of their managerial and decision-making skills, not because of their design skills. Less Is More One tempting solution to the user interface design problem might be to throw in any imaginable option or feature. If everything is there, then everybody should be satisfied, right? Wrong. Every single element in a user interface places some additional burden on the user in terms of having to consider whether to use that element. Having fewer options will often mean better usability because the users can then concentrate on understanding those fewer options [Brooks 1975]. Software reviewers are becoming aware that more features are not always better, and a major popular computer magazine ran a cover story lamenting the tendency of some programs to double in size every two years, coining the term “fatware” to describe bloated software [Perratore et al. 1993]. See also the discussion of the “less-is-more” principle on page 120. Details Matter Unfortunately, usability often depends on minor interface details, which is why systematic usability engineering work is necessary to ferret out those details. For example, Simonelli [1989] reports on the development of instructions for a frozen-dinner microwave indicator that would gradually change from being white to being blue. User testing showed that the phrase “turns blue” was much poorer than “white disappears” for describing this change, even though the two phrases are logically equivalent relative to this process. The blue color was not uniform—it was dark blue in some places and light blue in others— so users were uncertain “how blue is blue?” when the first wording was used. 15

– 30 of 377 –

U s a b i l i t y E n g i n e e r i n g Help Doesn’t Sometimes, online help and documentation doesn’t really help the users [Mack et al. 1983]. That is to say, users often do not find the information they want in the mass of possible help and documen- tation and, even if they do find it, they may misinterpret the help. Also, help adds an extra set of features to a system, thus compli- cating the interface just by virtue of existing. In any case, the possi- bility for providing help should not been seen as an excuse to design a needlessly complex interface. It is always better if users can operate the system without having to refer to a help system. Usability is not a quality that can be spread out to cover a poor design like a thick layer of peanut butter,11 so a user-hostile inter- face does not get user-friendly even by the addition of a brilliant help system. See also the section on Help and Documentation (page 148). Usability Engineering Is Process Most of this book consists of advice for activities to perform as part of the system development process. Readers may sometimes lose patience and wish that I had just told them about the result rather than the process: What makes an interface good? Unfortunately, so many things sometimes make an interface good and sometimes make it bad that any detailed advice regarding the end product has to be embellished with caveats, to an extent that makes it close to useless, not least because there will often be several conflicting guidelines. In contrast, the usability engineering process is well established and applies equally to all user interface designs. Each project is different, and each final user interface will look different, but the activities needed to arrive at a good result are fairly constant. 11. The peanut butter metaphor for misapplied usability engineering has been attributed to Clayton Lewis. 16

– 31 of 377 –

E x e c u t i v e S u m m a r y 1.4 Discount Usability Engineering Usability specialists will often propose using the best possible methodology Indeed, this is what they have been trained to do in most universities. Unfortunately, it seems that “Le mieux est Vennemi du bien” (the best is the enemy of the good) [Voltaire 1764] to the extent that insisting on using only the best methods may result in using no methods at all. Developers and software managers are sometimes intimidated by the strange terminology and elaborate laboratory setups employed by some usability specialists and may choose to abandon usability altogether in the mistaken belief that impenetrable theory is a necessary require- ment for usability engineering [Bellotti 1988]. Therefore, I focus on achieving “the good” with respect to having some usability engi- neering work performed, even though the methods needed to achieve this result may not always be the absolutely “best” method and will not necessarily give perfect results. It will be easy for the knowledgeable reader to dismiss the methods proposed here with various well-known counter-examples showing important usability aspects that will be missed under certain circumstances. Some counter-examples are no doubt true and I do agree that better results can be achieved by applying more careful methodologies. But remember that such more careful methods are also more expensive—often in terms of money and always in terms of required expertise (leading to the intimidation factor discussed above). Therefore, the simpler methods stand a much better chance of actually being used in practical design situa- tions, and they should thus be viewed as a way of serving the user community. The “discount usability engineering” [Nielsen 1989b, 1990b, 1994c] method is based on the use of the following four techniques: • User and task observation • Scenarios • Simplified thinking aloud • Heuristic evaluation 17

– 32 of 377 –

U s a b i l i t y E n g i n e e r i n g First, the basic principle of early focus on users should of course be followed. It can be achieved in various ways, including simple visits to customer locations. The main rules for “discount task anal- ysis” are simply to observe users, keep quiet, and let the users work as they normally would without interference. Scenarios Scenarios are an especially cheap kind of prototype. The entire idea behind prototyping is to cut down on the complexity of implemen- tation by eliminating parts of the full system. Horizontal proto- types reduce the level of functionality and result in a user interface surface layer, while vertical prototypes reduce the number of features and implement the full functionality of those chosen (i.e., we get a part of the system to play with). Scenarios are the ultimate reduction of both the level of function- ality and of the number of features: They can only simulate the user interface as long as a test user follows a previously planned path. See Figure 9 (page 94). Since the scenario is small, we can afford to change it frequently, and if we use cheap, small thinking-aloud studies, we can also afford to test each of the versions. Therefore, scenarios are a way of getting quick and frequent feedback from users. Scenarios can be implemented as paper mock-ups [Nielsen 1990d] or in simple prototyping environments [Nielsen 1989a], which may be easier to learn than more advanced programming environments [Nielsen et al. 1991]. This is an additional savings compared to more complex prototypes requiring the use of advanced software tools. Simplified Thinking Aloud The thinking-aloud method is discussed further in Section 6.8. Basically, it involves having one test user at a time use the system for a given set of tasks while being asked to “think out loud.” By verbalizing their thoughts, users allow an observer to determine not just what they are doing with the interface, but also why they 18

– 33 of 377 –

E x e c u t i v e S u m m a r y are doing it. This additional insight into a user’s thought process can help pinpoint concrete interface elements that cause misunder- standings, so that they can be redesigned. Traditionally, thinking-aloud studies are conducted with psycholo- gists or user interface experts as experimenters who videotape the subjects and perform detailed protocol analysis. This kind of method is certainly intimidating for ordinary developers. Those developers who have used the thinking-aloud method seem [Jorgensen 1989] to be happy with it, however. My studies [Nielsen 1992a] show that computer scientists are indeed able to apply the thinking-aloud method effectively to evaluate user interfaces with a minimum of training and that even methodologically primitive experiments will succeed in finding many usability problems. Another major difference between simplified and traditional thinking aloud is that data analysis can be done on the basis of the notes taken by the experimenter instead of by videotapes. Recording, watching, and analyzing the videotapes is expensive and takes a lot of time that is better spent on running more subjects and on testing more iterations of redesigned user interfaces. Video- taping should only be done in those cases (such as research studies) where absolute certainty is needed. In discount usability engi- neering we don’t aim at perfection; we just want to find most of the usability problems. A survey of 11 software engineers [Perlman 1988] found that they rated simple tests of prototypes as almost twice as useful as video protocols. Heuristic Evaluation Current collections of usability guidelines typically have on the order of a thousand rules to follow and are therefore seen as intim- idating by developers. For the discount method I advocate cutting the complexity by two orders of magnitude, to just 10 rules, relying on a small set of broader heuristics such as the basic usability prin- ciples listed in Table 2 and discussed in Chapter 5, Usability Heuristics. These principles can be used to explain a very large proportion of the problems one observes in user interface designs. Unfortunately, 19

– 34 of 377 –

U s a b i l i t y E n g i n e e r i n g • Simple and natural dialogue: Dialogues should not contain information that is irrelevant or rarely needed. Every extra unit of information in a dialogue com- petes with the relevant units of information and diminishes their relative visibil- ity. All information should appear in a natural and logical order. • Speak the users’languageiThe dialogue should be expressed clearly in words, phrases, and concepts familiar to the user, rather than in system-ori- ented terms. • Minimize the users’ memory load: The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. • Consistency: Users should not have to wonder whether different words, situ- ations, or actions mean the same thing. • Feedback: The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. • Clearly marked exits: Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state with- out having to go through an extended dialogue. • Shortcuts: Accelerators—unseen by the novice user—may often speed up the interaction for the expert user such that the system can cater to both inex- perienced and experienced users. • Good error messages: They should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution. • Prevent errors: Even better than good error messages is a careful design that prevents a problem from occurring in the first place. • Help and documentation: Even though it is better if the system can be used without documentation, it may be necessary to provide help and documenta- tion. Any such information should be easy to search, be focused on the user’s task, list concrete steps to be carried out, and not be too large. Table 2 These usability principles should be followed by all user interface designers. This specific list was developed by the author and Rolf Molich [Molich and Nielsen 1990], but it is similar to other usability guidelines. See [Nielsen 1994d] for several lists of similar heuristics. it does require some experience with the principles to apply them correctly in all cases. On the other hand, even nonexperts can find many usability problems by heuristic evaluation, and many of the remaining problems would be revealed by the simplified thinking- aloud test. It can also be recommended to let several different people perform a heuristic evaluation as different people locate different usability problems. 20 problems.

– 35 of 377 –

E x e c u t i v e S u m m a r y 1.5 Recipe For Action As discussed on page 8, the demand for usability is growing rapidly these years. This book presents many steps that can be taken to increase usability. The most important advice to remember is that usability does not appear just because you wish for it. Get started on a systematic approach to usability—the sooner, the better. From a management perspective, the action items are

  1. Recognize the need for usability in your organization.
  2. Make it clear that usability has management support (this includes promoting a culture where it is seen as positive for developers to change their initial design ideas to accommodate demonstrated user needs).
  3. Devote specific resources to usability engineering (you can start out small, but you need a minimal amount of dedicated resources for usability to make sure that it does not fall victim to deadline pressures).
  4. Integrate systematic usability engineering activities into the various stages of your development lifecycle (see Chapter 4 ) , including the early ones.
  5. Make sure that all user interfaces are subjected to user testing. If you think this 5-step plan is too much, then try this 1-step plan for a start:
  6. Pick one of your existing user interfaces. Subject it to a simple user test by defining some typical test tasks, getting hold of a few potential customers who have not used the system before, and observing them as they try performing the tasks with the system (without any help or interference from you). If no usability problems are found, then be happy that you have been lucky In the more likely case that problems are found, you already have your first usability project defined: get rid of them in the next release by using iterative design. 21

– 36 of 377 –

This page intentionally left blank

– 37 of 377 –

Chapter 2 Wiatls Usability? Back when computer vendors first started viewing users as more than an inconvenience, the term of choice was “user friendly” systems. This term is not really appropriate, however, for several reasons. First, it is unnecessarily anthropomorphic—users don’t need machines to be friendly to them, they just need machines that will not stand in their way when they try to get their work done. And second, it implies that users’ needs can be described along a single dimension by systems that are more or less friendly. In reality, different users have different needs, and a system that is “friendly” to one may feel very tedious to another. Because of these problems with the term “user friendly,” user inter- face professionals have tended to use other terms in recent years. The field itself is known under names like CHI (computer-human interaction), HCl (human-computer interaction, which is preferred by some who like “putting the human first” even if only done symbolically), UCD (user-centered design), MMI (man-machine interface), HMI (human-machine interface), OMI (operator- machine interface), UID (user interface design), HF (human factors), ergonomics,1 etc. I tend to use the term “usability” to denote the considerations that can be addressed by the methods covered in this book. As shown in 23

– 38 of 377 –

U s a b i l i t y E n g i n e e r i n g the following section, there are also broader issues to consider within the overall framework of traditional “user friendliness/’ 2.1 Usability and Other Considerations To some extent, usability is a narrow concern compared to the larger issue of system acceptability, which basically is the question of whether the system is good enough to satisfy all the needs and requirements of the users and other potential stakeholders, such as the users’ clients and managers. The overall acceptability of a computer system is again a combination of its social acceptability and its practical acceptability. As an example of social acceptability, consider a system to investigate whether people applying for unemployment benefits are currently gainfully employed and thus have submitted fraudulent applications. The system might do this by asking applicants a number of questions and searching their answers for inconsistencies or profiles that are often indicative of cheaters. Some people may consider such a fraud-preventing system highly socially desirable, but others may find it offensive to subject applicants to this kind of quizzing and socially undesirable to delay benefits for people fitting certain profiles. Notice that people in the latter category may not find the system acceptable even if it got high scores on practical acceptability in terms of iden- tifying many cheaters and were easy to use for the applicants. Given that a system is socially acceptable, we can further analyze its practical acceptability within various categories, including traditional categories such as cost, support, reliability, compati- bility with existing systems, etc., as well as the category of useful- ness. Usefulness is the issue of whether the system can be used to achieve some desired goal. It can again be broken down into the

  1. Human factors and ergonomics have a broader scope than just h u m a n - computer interaction. In fact, many usability methods apply equally well to the design of other complex systems, and even to simple ones that are not simple enough. 24

– 39 of 377 –

W h a t I s U s a b i l i t y ? Social Easy to learn

– 40 of 377 –

U s a b i l i t y E n g i n e e r i n g mail to my assistant and to the entire membership, respectively). It turned out that several people sent email to the wrong address, not realizing where their mail would go. My mistake was twofold: first in not realizing that even a pair of email addresses constituted a user interface of sorts, and second in breaking the well-known usability principle of avoiding easily confused names. A user who was taking a quick look at the “To:” field of an email message might be excused for thinking that the message was going to one address even though it was in fact going to the other. 2.2 Definition of Usability It is important to realize that usability is not a single, one-dimen- sional property of a user interface. Usability has multiple compo- nents and is traditionally associated with these five usability attributes: • Learnability: The system should be easy to learn so that the user can rapidly start getting some work done with the system. • Efficiency: The system should be efficient to use, so that once the user has learned the system, a high level of productivity is possible. • Memorability: The system should be easy to remember, so that the casual user is able to return to the system after some period of not having used it, without having to learn everything all over again. • Errors: The system should have a low error rate, so that users make few errors during the use of the system, and so that if they do make errors they can easily recover from them. Further, cata- strophic errors must not occur. • Satisfaction: The system should be pleasant to use, so that users are subjectively satisfied when using it; they like it. Each of these usability attributes will be discussed further in the following sections. Only by defining the abstract concept of “usability” in terms of these more precise and measurable compo- nents can we arrive at an engineering discipline where usability is not just argued about but is systematically approached, improved, 26

– 41 of 377 –

W h a t I s U s a b i l i t y ? and evaluated (possibly measured). Even if you do not intend to run formal measurement studies of the usability attributes of your system, it is an illuminating exercise to consider how its usability could be made measurable. Clarifying the measurable aspects of usability is much better than aiming at a warm, fuzzy feeling of “user friendliness” [Shackel 1991]. Usability is typically measured by having a number of test users (selected to be as representative as possible of the intended users) use the system to perform a prespecified set of tasks, though it can also be measured by having real users in the field perform what- ever tasks they are doing anyway In either case, an important point is that usability is measured relative to certain users and certain tasks. It could well be the case that the same system would be measured as having different usability characteristics if used by different users for different tasks. For example, a user wishing to write a letter may prefer a different word processor than a user wishing to maintain several hundred thousands of pages of tech- nical documentation. As further discussed in Section 6.5 (page 185), usability measurement therefore starts with the definition of a representative set of test tasks, relative to which the different usability attributes can be measured. To determine a system’s overall usability on the basis of a set of usability measures/one normally takes the mean value of each of the attributes that have been measured and checks whether these means are better than some previously specified minimum (see the section on Goal Setting on page 80). Since users are known to be very different, it is probably better to consider the entire distribu- tion of usability measures and not just the mean value. For example, a criterion for subjective satisfaction might be that the mean value should be at least 4 on a 1-5 scale; that at least 50% of the users should have given the system the top rating, 5; and that no more than 5% of the users gave the system the bottom rating, 1. Learnability Learnability is in some sense the most fundamental usability attribute, since most systems need to be easy to learn, and since the first experience most people have with a new system is that of 27

– 42 of 377 –

U s a b i l i t y E n g i n e e r i n g Focus on expert user Time Figure 2 Learning curves for a hypothetical system that focuses on the novice user, being easy to learn but less efficient to use, as well as one that is hard to learn but highly efficient for expert users. See also Section 2.4 (page 40) for a discussion of how to ride the best parts of both curves. learning to use it. Certainly, there are some systems for which one can afford to train users extensively to overcome a hard-to-learn interface, but in most cases, systems need to be easy to learn. Ease of learning refers to the novice user’s experience on the initial part of the learning curve, as shown in Figure 2. Highly learnable systems have a steep incline for the first part of the learning curve and allow users to reach a reasonable level of usage proficiency within a short time. Practically all user interfaces have learning curves that start out with the user being able to do nothing (have zero efficiency) at time zero (when they first start using it). Excep- tions include the so-called walk-up-and-use systems such as museum information systems that are only intended to be used once and therefore need to have essentially zero learning time, allowing users to be successful from their very first attempt at using them. The standard learning curve also does not apply to cases where the users are transferring skills from previous systems, such as when they upgrade from a previous release of a word processor to the 28

– 43 of 377 –

W h a t I s U s a b i l i t y ? new release [Telles 1990]. Assuming that the new system is reason- ably consistent with the old, users should be able to start a fair bit up on the learning curve for the new system [Poison et al. 1986]. Initial ease of learning is probably the easiest of the usability attributes to measure, with the possible exception of subjective satisfaction. One simply picks some users who have not used the system before and measures the time it takes them to reach a speci- fied level of proficiency in using it. Of course, the test users should be representative of the intended users of the system, and there might be a need to collect separate measurements from complete novices without any prior computer experience and from users with some typical computer experience. In earlier years, learn- ability studies focused exclusively on users without any computer experience, but since many people now have used computers, it is becoming more and more important to include such users in studies of system learnability. The most common way to express the specified level of proficiency is simply to state that the users have to be able to complete a certain task successfully Alternatively, one can specify that users need to be able to complete a set of tasks in a certain, minimum time before one will consider them as having “learned” the system. Of course, as shown in Figure 2, the learning curve actually represents a continuous series of improved user performance and not a dichoto- mous “learned”/“not learned” distinction. It is still common, however, to define a certain level of performance as indicating that the user has passed the learning stage and is able to use the system, and to measure the time it takes the user to reach that stage. When analyzing learnability, one should keep in mind that users normally do not take the time to learn a complete interface fully before starting to use it. On the contrary, users often start using a system as soon as they have learned a part of the interface. For example, a survey of business professionals who were experienced personal computer users [Nielsen 1989e] found that 4 of the 6 highest-rated usability characteristics (out of 21 characteristics in the survey) related to exploratory learning: easy-to-understand error messages, possible to do useful work with program before 29

– 44 of 377 –

U s a b i l i t y E n g i n e e r i n g having learned all of it, availability of undo, and confirming ques- tions before execution of risky commands. Because of users’ tendency to jump right in and start using a system, one should not just measure how long it takes users to achieve complete mastery of a system but also how long it takes to achieve a sufficient level of proficiency to do useful work. Efficiency of Use Efficiency refers to the expert user’s steady-state level of perfor- mance at the time when the learning curve flattens out (again, see Figure 2). Of course, users may not necessarily reach that final level of performance any time soon. For example, some operating systems are so complex that it takes several years to reach expert- level performance and the ability to use certain composition opera- tors to combine commands [Doane et al. 1990, 1992]. Also, some users will probably continue to learn indefinitely, though most users seem to plateau once they have learned “enough” [Rosson 1984, Carroll and Rosson 1987]. Unfortunately, this steady-state level of performance may not be optimal for the users who, by learning a few additional advanced features, sometimes would save more time over the course of their use of the system than the time it took to learn them. To measure efficiency of use for experienced users, one obviously needs access to experienced users. For systems that have been in use for some time, “experience” is often defined somewhat infor- mally, and users are considered experienced either if they say so themselves or if they have been users for more than a certain amount of time, such as a year. Experience can also be defined more formally in terms of number of hours spent using the system, and that definition is often used in experiments with new systems without an established user base: Test users are brought in and asked to use the system for a certain number of hours, after which their efficiency is measured. Finally, it is possible to define test users as experienced in terms of the learning curve itself: A user’s performance is continuously measured (for example, in terms of number of seconds to do a specific task), and when the perfor- mance has not increased for some time, the user is assumed to have 30

– 45 of 377 –

W h a t I s U s a b i l i t y ? reached the steady-state level of performance for that user [Nielsen and Phillips 1993]. A typical way to measure efficiency of use is thus to decide on some definition of expertise, to get a representative sample of users with that expertise, and to measure the time it takes these users to perform some typical test tasks. Memorability Casual users are the third major category of users besides novice and expert users. Casual users are people who are using a system intermittently rather than having the fairly frequent use assumed for expert users. However, in contrast to novice users, casual users have used a system before, so they do not need to learn it from scratch, they just need to remember how to use it based on their previous learning. Casual use is typically seen for utility programs that are only used under exceptional circumstances, for supple- mentary applications that do not form part of a user’s primary work but are useful every now and then, as well as for programs that are inherently only used at long intervals, such as a program for making a quarterly report. Having an interface that is easy to remember is also important for users who return after having been on vacation or who for some other reason have temporarily stopped using a program. To a great extent, improvements in learnability often also make an interface easy to remember, but in principle, the usability of returning to a system is different from that of facing it for the first time. For example, consider the sign “Kiss and Ride” seen outside some Washington, DC, Metro stations. Initially, the meaning of this sign may not be obvious (it has poor learnability without outside assis- tance), but once you realize that it indicates a drop-off zone for commuters arriving in a car driven by somebody else, the sign becomes sufficiently memorable to allow you to find such zones at other stations (it is easy to remember).2 2. “Kiss and Ride” is an analogy with “Park and Ride” areas where people can leave their cars. The sign refers to commuters who are driven by their spouses and will kiss them before getting out of the car to take the train. 31

– 46 of 377 –

U s a b i l i t y E n g i n e e r i n g Interface memorability is rarely tested as thoroughly as the other usability attributes, but there are in principle two main ways of measuring it. One is to perform a standard user test with casual users who have been away from the system for a specified amount of time, and measure the time they need to perform some typical test tasks. Alternatively, it is possible to conduct a memory test with users after they finish a test session with the system and ask them to explain the effect of various commands or to name the command (or draw the icon) that does a certain thing. The inter- face’s score for memorability is then the number of correct answers given by the users. The performance test with casual users is most representativ

[…content truncated for processing]