sabilityEngineering
`Jakob Nielsen
`
`Page 1 of 56
`
`MSFTEX. 1021
`
`MSFT EX. 1021
`Page 1 of 56
`
`

`

`
`
`Usability Engineering
`
`JAKOB NIELSEN
`
`_eeeeeSsSsaeese
`
`SunSoft
`2550 Garcia Avenue
`Mountain View, California
`
`Mi t<
`Morgan Kaufmann
`An Imprintof Elsevier
`
`Amsterdam Boston Heidelberg London New York Oxford
`Paris San Diego
`San Francisco Singapore
`Sydney Tokyo
`rt
`
`
`
`MSFT EX. 1021
`Page 2 of 56
`
`MSFT EX. 1021
`Page 2 of 56
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`This bookis printed on acid-free paper.
`
`Copyright © 1993 by Academic Press.
`
`An Imprint of Elsevier
`
`All rights reserved.
`No part ofthis 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.
`Permissions may be sought directly from Elsevier's Science and Technology Rights Departmentin
`Oxford, UK. Phone: (44) 186$ 843830, Fax: (44) 1865 853333, e-mail: permissions@elsevier.co.uk.
`You may also complete your request on-line via the Elsevier homepage: http://www.elsevier.com by
`selecting "Customer Support" and then "Obtaining Permissions".
`All brand names and product names are trademarks or registered trademarks of
`their respective companies.
`
`ACADEMIC PRESS
`An Imprint of Elsevier
`525 B Street, Suite 1900, San Diego, CA 92101-4495 USA
`http://www.academicpress.com
`
`Academic Press
`Harcourt Place, 32 Jamestown Road, London, NWI 7BY UK
`
`Morgan Kaufmann
`340 Pine Street, Sixth Floor, San Francisco, CA 94104-3205
`http://www.mkp.com
`
`Library of Congress Catalog Number: 93000488
`ISBN-13: 978-0-12-518406+9
`ISBN-10: 0-12-518406-9
`
`Printed and boundin the United Kingdom
`Transferred to Digital Printing, 2010
`
`
`
`MSFT EX. 1021
`Page 3 of 56
`
`MSFT EX. 1021
`Page 3 of 56
`
`

`

`
`
`23
`What Is Usability?
`2.1
`Usability and Other Considerations
`2.2
`Definition of Usability 26
`2.3
`Example: Measuring the Usability of
`Icons
`37
`41
`Usability Trade-Offs
`Categories of Users and
`Individual User Differences
`
`
`
`Table ofContents
`
`
`
`ix
`Preface
`Audience
`ix
`Teaching Usability Engineering xi
`Acknowledgments
`xiii
`
`8
`
`17
`
`Chapter 1
`
`Chapter 2
`
`1
`
`2
`
`Executive Summary
`11
`Cost Savings
`1.2
`Usability Now!
`13
`10
`Usability Slogans
`1.4
`Discount Usability Engineering
`15
`Recipe For Action
`21
`
`24
`
`2.4
`25
`
`43
`
`
`
`MSFTEX. 1021
`Page 4 of 56
`
`MSFT EX. 1021
`Page 4 of 56
`
`

`

`
`
`Usabliity Engineering
`
`
`49
`
`Generations of User Interfaces
`3.1
`Batch Systems
`51
`3.2
`Line-Oriented Interfaces
`3.3
`Full-Screen Interfaces
`54
`3.4
`57
`Graphical User Interfaces
`3.5
`62
`Next-Generation Interfaces
`3.6
`Long-Term Trends in Usability
`
`52
`
`67
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`115
`Usability Heuristics
`5.1
`115
`Simple and Natural Dialogue
`
`5.2
`
`123
`Speak the Users’ Language
`5.3
`
`Minimize User Memory Load
`129
`5.4
`
`Consistency 132
`5.5
`Feedback
`134
`
`5.6
`
`Clearly Marked Exits
`5.7
`Shortcuts
`139
`
`5.8
`
`Good Error Messages
`5.9
`Prevent Errors
`145
`
`
`5.10 Help and Documentation 148
`5.11
`Heuristic Evaluation 155
`
`
`The Usability Engineering Lifecycle
`4.1
`Know the User
`73
`4,2
`Competitive Analysis
`43
`Goal Setting 79
`Parallel Design 85
`Participatory Design 88
`90
`Coordinating the Total Interface
`Guidelines and Heuristic Evaluation 91
`Prototyping 93
`Interface Evaluation
`Iterative Design
`105
`Follow-Up Studies of Installed Systems
`Meta-Methods
`111
`Prioritizing Usability Activities
`Be Prepared 113
`
`Chapter 3
`
`Chapter 4
`
`Chapter 5
`
`4,11
`4.12
`4.13
`4.14
`
`71
`
`78
`
`102
`
`138
`
`142
`
`112
`
`109
`
`
`
`MSFTEX. 1021
`Page 5 of 56
`
`MSFT EX. 1021
`Page 5 of 56
`
`

`

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

`

`og
`
`i U
`
`sability Engineering
`
`Chapter 10
`
`255
`Future Developments
`256
`10.1 Theoretical Solutions
`10.2 Technological Solutions
`260
`10.3 CAUSE Tools: Computer-Aided Usability
`Engineering 264
`10.4 ‘Technology Transfer
`
`265
`
`Appendix A
`
`Exercises
`
`269
`
`Appendix B
`
`284
`
`290
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`283
`Bibliography
`B.1 Conference Proceedings
`
`B.2
`Journals
`286
`
`
`B.3.
`Introductions and Textbooks
`
`B.4 Handbook 291
`
`292
`B.5, Reprint Collections
`B.6©Important Monographsand Collections of
`
`Original Papers
`294
`
`B.7. Guidelines
`300
`
`
`B.8 Videotapes
`302
`
`B.9 Other Bibliographies
`B.10 References
`306
`
`
`
`
`Subject Index
`351
`
`304
`
`Author Index
`
`341
`
`
`
`MSFTEX. 1021
`Page7 of 56
`
`MSFT EX. 1021
`Page 7 of 56
`
`

`

`V5
`
`5.1. Simple and Natural Dialogue
`
`User interfaces should be simplified as much as possible, since
`every additional feature or item of information ona screen is one
`more thing to learn, one more thing to possibly misunderstand,
`and one more thing to search through whenlooking for the thing
`you want, Furthermore, interfaces should match the users’ task in
`a8 natural a way as possible, such that the mapping between
`Somputer concepts and user concepts becomes as simple as
`Possible and the users’ navigation through the interface is mini-
`
`Chapter 5
`
`Usability Heuristics
`
`
`This chapter presents some basic characteristics of usable inter-
`faces. The principles are fairly broad and apply to practically any
`type of user interface, including both character-based and graph-
`ical interfaces [Nielsen 1990e]. The principles are summarized in
`Table 2 (page 20). After detailed sections for each of the ten basic
`heuristics, Section 5.11 (page 155) concludes the chapterwith infor-
`mation on howto use usability heuristics as a basis for a systematic
`inspection of a user interface to find its usability problems (the
`heuristic evaluation method).
`
`
`
`
`eee
`
`
`ized.
`
`
`
`MSFT EX. 1021
`Page 8 of 56
`
`MSFT EX. 1021
`Page 8 of 56
`
`

`

`
`
`
`
`Usabllity Engineering
`
`
`
`a
`
`7
`A
`
`es
`
`i
`
`Ry
`
`ie
`
`~Mmm mmmmm
`(Minrrn finn meen ne Se Pe ee ear
`Mmmm rh mmm mm mmcnan am mn encanta reeneren
`Mirani A mm mammmin mimcamiam. Mam Mm rrinm rn
`PAM AM MAM MMNINTD PI MAN McATAN MMe MAA ATA
`CA minim meant FAM rom FARM men mm, Pin nya mmm
`TOM, MrAtAT fifa MMM MAMA tarneAre MM Maram Mmmm
`MAN eth Mmm mm fAMn Pamm Mm mmm Minmn InfAmmm,
`py
`PTSD Ar TAMIA MAMrm Mmm menace Anemmm Me AM
`my
`Pain min nimtom Zee mre ram am/mm mramnm , men.
`rainy mmmm (mia menm menmra) ram nits raga mane
`Mmmm mom mmmenmn.
`
`;
`ae
`MmmMHM'mm mmmmmmmmm |
`
`ane
`}
`(4in_moemmenmnenarama
`
`MmmMrin mim mom ro mm|bam Meng, Mmm
`Pirin Pimovnin cam-ram, mown mm mm mem
`
`(Amram mmmmramenm mM carn mmooimmm,
`bein
`{"
`
`himmm ram mmenm, mamramranm mm mam mania oy
`Sy
`SIT no
`PranamMmmmin ree A faminmm mm mn
`Aim mime. Mom mim in rim mmmn meme
`(Ph,
`
`tM Mmm ramen mmaern Mm, MMi Mm om meni mM
`LMenenty0 wma| i Wl
`famant m ram maim Mm ramen fate Mirani;
`1
`wines
`
`
`
`
`
`
`Figure 11 Mumble screen layout for a hypertext system. The actual
`system is described in [Nielsen 1990a, 1990i),The screen could be made to
`abstract even further from the information content in the full system by
`replacing the icons with generic shapes.
`
`
`
`
`
`
`The idealis to present exactly the information the user needs—and
`no more—at exactly the time and place where it is needed. Infor-
`mation that will be used together should be displayed close
`together, and at a minimum on the same screen. Also, both infor-
`mation objects and operations should be accessed in a sequence
`that matches the way users will mosteffectively and productively
`do things. Sometimes such sequences are enforced by the user
`interface, butit is normally better to allow the user to control the
`dialogue as much as possible such that
`the sequence can be
`adjusted by the individual user to suit that user’s task and prefer-
`ences, Even so, the system may ease the user’s understanding of
`the dialogue byindicating a suggested or preferred sequence, such
`as the sequence implied bythelisting offields in a dialog box from
`top to bottom.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`MSFTEX. 1021
`Page 9 of 56
`
`MSFT EX. 1021
`Page 9 of 56
`
`

`

` ee
`
`Screen layouts should use the gestalt rwes for human perception
`[Rock and Palmer 1990] to increase the users’ understanding of
`relationships between the dialogue elements. These rules say that
`things are seen as belonging together, as a group, or as a unit, if
`they are close together, are enclosed by lines or boxes, move or
`change together, or look alike with respect to shape, color, size, or
`typography. For example, in Figure 12, most people will perceive
`two major groups of objects due to the closeness of the objects
`within the groups compared with the distance between the groups.
`Then, most people wouldthink thatthe left set of objects contained
`twosets of objects that were even moreclosely related, due to the
`enclosure of the six objects in the upper right corner and the high-
`lighting of the four objects in the lower left corner. Also, the right
`set of objects will be perceived as containing three groups, and the
`middle one will be seen as standing out from the background since
`it is smaller.
`
`
`
`117
`
`MSFTEX. 1021
`Page 10 of 56
`
`Usability Heuristics
`
`Graphic Design and Color
`
`Good graphic design is an important element in achieving a simple
`and natural dialogue for modern computer systems with graphical
`user interfaces [Marcus 1992]. In addition to getting help from a
`graphics designer, there are several simple considerations that may
`lead to simpler dialogues. By prototyping screen layouts using
`“mumble screens” like that shown in Figure 11 where all text has
`been replaced with the letter “m,” one can abstract away from the
`detailed information content in the system and focus on layout
`issues.
`
`These principles of graphic structure should be used to help the
`User understandthe structure of the interface. For example, menus
`an use a dividing line or color coding [McDonald et al. 1988] to
`Split options into related groups, each of which will be easier to
`understand because each option will be seenin a relevant context.
`Nnas
`whvutnble text has also been used as a task analysis technique for finding out
`on a ee users gain information simply from the way information is
`presented
`me orm without reading the detailed data [Nygren et al. 1992]. If
`they do,
`ati ne should design similar capabilities for users in a computerized infor-
`©n environment.
`
`MSFT EX. 1021
`Page 10 of 56
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`118
`
`MSFTEX. 1021
`Page 11 of 56
`
`Usabllity Engineering
`
`
`
`|A
`
`i
`
`|
`
`i
`
`
`
`Figure 12 Example of objects structured according to the gestalt princi-
`ples ofcloseness, closure, and similarity.
`
`Similarly, dialog boxes can grouprelated features and enclose them
`in boxes or separate them by lines or white space. Also, since users
`will perceive structure based on these principles, care should be
`taken not to separate out unrelated objects in ways that make them
`seem as belonging together. For example, consider a bank state-
`ment with the following layout:
`
`
`2,000.
`
`$
`
`2,000.00
`
`“ame
`
`What is the balance? One or two thousand dollars? The closeness
`rule will make many people perceive the label Balance as being
`matched with the number $2,000, even though it may have been
`intended asa label forthe line containing the number $1, 000.
`
`Principles of graphic design can also help users prioritize their
`attention to a screen by making the most important dialogue
`elements stand out. As shownbythe right part of Figure 12,a small
`delineated area will stand out from the background, and one can
`also make objects stand out by highlighting them in various ways,
`including the use of bolder colors or typefaces, and by making
`them larger. Also, information that is presented “first,” given the
`usual reading direction (that is, at the top and to theleft in many
`cultures) normally gets more attention. It is even possible to attract
`the users’ attention by using blinking objects, but blinking is so
`distracting and annoying that it should only be used in extreme
`
`
`MSFT EX. 1021
`Page 11 of 56
`
`

`

`Usabitity Heuristics
`
`cases. On alphanumeric terminals, UPPERCASE TEXT CAN ALSO
`BE USED TO GET THE USERS’ ATTENTION, but upper case
`should be used sparingly as it is about 10% slower to read than
`mixed-case text.
`
` iEEEEEPTaEErirTTSETseeraera
`
`With respect to the use of color in screen designs [Rice 1991; Travis
`1991], the three most important guidelines are
`° Don’t over-doit. An interface should notlook like an angry fruit
`salad of wildly contrasting, highly saturated colors.It is better to
`limit the design to a small numberof consistently applied colors.
`Color-coding should be limited to no more than 5 to 7 different
`colors since it is difficult to remember and distinguish larger
`numbers, even though highly trained users can cope with about
`11 colors [Durrett and Trezona 1982]. Also,light grays and muted
`pastel colors are often better as background colors
`than
`screaming colors are.
`* Make sure that the interface can be used without the colors.
`Rememberthat many people (about 8%of males) are colorblind,
`so any color-coding of information should be supplemented by
`redundant cues that make it possible to interpret the screens
`even withoutbeing able to differentiate the colors. For example,
`icons that are about to be deleted could be turned red for fast
`identification by users with full color vision and they could also
`be marked with an X. The best test would beto havea selection
`of colorblind userstry out the system, but it would bedifficult to
`do so comprehensively as there are manydifferent types of color
`blindness.?
`In addition to having at least some colorblindtest
`users, one can also check how the interface looks on a mono-
`chrome screen. In many cases, some users will be limited to
`monochromedisplays anyway.
`_—
`2. Being “colorblind” normally does not mean than one cannotdistinguish
`any colors atall, so the expression is somewhat inaccurate. About 6% of males
`and 0.4% of females are partially red-green colorblind (and so can distinguish
`eee and blues as well as some shades of green and red), 2% of males and
`0,00ee females are fully
`red-green colorblind, and only 0.005% of males and
`of females are yellow-biue or completely colorblind [Silverstein 1987].
`tee}oe a test with a single colorblind user (while mich better than no such
`Ss oF not guarantee that all types of users with color-deficient vision will
`‘0 use the interface without problems.
`
`
`
`119
`
`MSFTEX. 1021
`Page 12 of 56
`
`MSFT EX. 1021
`Page 12 of 56
`
`

`

`
`
`:
`
`Usability Engineering
`
`* Try to use color only to categorize, differentiate, and highlight,
`not to give information, especially quantitative information.
`It is true that some colors and color combinations are more visible
`than others [Durrett 1987], and you certainly would not want to
`presentyourhelp screensin light blue text on a bright yellow back-
`ground.’
`If the most obviously horrible color combinations are
`avoided, however, there is normally only a small additional benefit
`to be gained from searching out the absolutely optimal choice of
`colors.
`
`Less Is More
`The great rune stone in Jelling, Denmark (from the last half of the
`tenth century), bears the following inscription: “King Harald ordered
`these memorials raised to Gorm, his father, and Thyre, his mother; that
`Harald who won for himself all Denmark and Norway and made the
`Danes Christian.” The stone does seem to focus excessively on King
`Harald, and the last half of the text distracts from the message
`regarding King Gorm and Queen Thyre.’ Similarly, adding infor-
`mation anddata fields to a user interface can distract the user from
`the primary information.
`Based on a propertask analysis, it is often possible to identify the
`information thatis truly important to users and which will enable
`them to perform almostall of their tasks. It will then normally be
`better to design a single screen with this information and relegate
`less important information to auxiliary screens than to cram all the
`information that might possibly be useful into a set of screens that
`will require the user to switch screens for even the most simple
`tasks.
`Other information may not even be necessary at all. For example,
`many programsfollow the example of King Harald and dedicate
`
`3. Detailed guidelines for choosing screen colors can be found in part 8 of ISO
`9241 (an international standard for user interface issues). The content of this
`standard is discussed further by Smith [1988].
`4. Compare with the inscription on the small Jelling rune stone from thefirst
`half of the tenth century: “Kirrg Gorm raised these memorials to his wife Thyre, the
`joy of Denmark.” The runesare fewer, but the message is focused.
`
`
`120
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`es
`Neea
`
`
`
`MSFTEX. 1021
`Page 13 of 56
`
`MSFT EX. 1021
`Page 13 of 56
`
`

`

` Usability Heuristics
`
`
`
`large amounts of screen space to a display of the name of the
`rogram, the vendor‘s logo, the version number, and other similar
`information. Even though this information is potentially important
`and should be available for users making bug reports, it normally
`only takes up screen space that could have been used for other
`purposes (maybe evenas white space to makefor a better layout).
`‘And of course, any piece of information is something users will
`have to look at when they search the screen, and it will therefore
`slow downtheir performance by some fraction of a second,It is
`better to provide identifying information as partof a startup screen
`that can be extravagantly eye-catching and serve as feedback to the
`user that the appropriate program is being entered. Also, of course,
`identifying information about the program,its version, and its
`status should be accessible through the help system. As another
`example, headers with address and message routing information
`can be eliminated from displays of electronic mail and network
`news [Andersen et al. 1989] to be shown only in the rare case when
`a user actually needsthis system-oriented information.
`Extraneous information notonly risks confusing the novice user,
`but also slows down the expertuser. For example, a study of expe-
`rienced telephone company directory assistance operators showed
`that finding a target that appeared in the top quarter of the screen
`took 5.3 seconds when the screen washalf full of information and
`6.2 seconds when the screen was full of information [Springer
`1987]. Saving 0.9 seconds may not seemlike a lot, but for this
`Specific application, it was estimated to reduce call processing costs
`by more than 40 million dollars per year.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`The “less ig more” rule does not just apply to the information
`contents of screens butalso to the choice of features and interaction
`mechanisms for a program. A common design pitfall is to believe
`that “by providing lots of options and several ways of doing
`things, we can satisfy everybody.” Unfortunately, you do have to
`make the hard choices yourself. Every time you add a feature to a
`System, there is one more thing for users to learn (and possibly use
`haeneously) and the manual gets bigger, more intimidating, and
`oer to search. One study found that the users’ planning time for
`ormula entry was 2.9 seconds in one spreadsheet and 4.6 in
`
`121
`
`
`
`MSFT EX. 1021
`Page 14 of 56
`
`MSFT EX. 1021
`Page 14 of 56
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Usabillty Engineering
`
`another [Olson and Nilsen 1987-88]. The first spreadsheet wag
`faster becauseit only provided a single method for formula ent
`and therefore did not require usersto think about which methodto
`use.
`In contrast,
`the second spreadsheet provided multiple
`methods, with the result that the users were slowed down moreby
`having to choose between methods than the amountof time they
`sometimes gained from being able to use a “faster” method for
`certain formulas.
`
`i
`
`a
`
`
`This does not mean that one should never provide alternative
`interaction techniques. On the contrary, they are often a good idea
`as further discussed in Section 5,7, on Shortcuts, on page 139. Alter-
`natives can be providedif users can easily recognize the conditions
`under which each one is optimal so that they can consistently
`choose the optimalinteraction technique without additional plan-
`ning. For training, users should at first be taught only thesingle,
`general method that is preferable in most common situations.
`Other methods can be taughtlater but should not be introduced at
`a stage whentheywill only confuse the novice user.
`Sometimes, one can design an especially simple interface for
`novice users and shield them from any necessary complexity that
`may be needed by advanced users. Most systems doing this have
`only twolevels of interface complexity: novice mode and expert
`mode, but in principle it might be possible to provide multiple
`nested levels of increased complexity. This nested design strategy
`is sometimes referred to as training wheels [Carroll 1990a],
`
`Since novice users are often observed spending too much time
`recovering from errors, the training wheels approach can give
`them a system wherethey are blocked from even entering potential
`error situations. Of course, this limits the available functionality,
`but novice users probably do not need the advanced features
`anyway. In one experiment, novice users were able to learn basic
`use of a word processor andtypea letter in 116 minutes when they
`were faced with thefull system and in 92 minutes when they were
`given the training wheels system where actions leading to the most
`common errors were not available [Carroll and Carrithers 1984].
`Not only did the training wheels users get started faster, but they
`
`122
`
`i
`)
`|
`i
`
`,
`
`Te
`
`4
`
`|
`
`MSFT EX. 1021
`Page 15 of 56
`
`MSFT EX. 1021
`Page 15 of 56
`
`

`

` Usability Heuristics
`
`
`
`also liked the system better and scored slightly higher on a compre-
`hension exam after the study. Even better, the initial use of the
`training wheels interface did not impair users when they later
`graduated to the full system. On the contrary, users who had
`learned the basics of the system with the training wheels interface
`learned advancedfeatures faster than users who had been using the
`full system all the time [Catramboneand Carroll 1987}.
`
`
`
`5.2 Speak the Users’ Language
`As a partof user-centered design, the terminology in user inter-
`faces should be based on the users’ language and not on system-
`oriented terms. For example, a user interface for foreign currency
`transactions should not require users to specify British pounds
`with a code like 317, evenif it is the one used internally in the
`system. Instead, terms like GBP or simply Pounds should be used,
`depending on whether the system was intended for professional
`currency traders or for the general public.
`As far as possible, dialogues should be in the users’ native
`language and notin a foreign language (see Chapter 9 for a discus-
`sion of translation and other jnternationalization issues). Of course,
`concerns for the users’ “language” should not be limited to the
`wordsin the interface but should include nonverbal elements like
`icons (see page 38 for a discussion of how toelicit ideas for intui-
`
` 123
`
`tive icons).
`
`As part of the general principle of speaking the users’ language,
`one should take care not to use words in nonstandard meanings,
`unless, of course, a word meaning that would be nonstandard in
`the general population happens to be the standarduse of the word
`= the user community. Special dictionaries exist to help distin-
`ae common meanings of words from less common meanings.
`or example, [Dale and O’Rourke 1981]lists 44,000 English word
`eeanings and provides statistics on how many Americans know
`a meaning. Even though such statistics are only valid in the
`ountry where they were collected, one can normally assumethat
`
`
`
`MSFT EX. 1021
`Page 16 of 56
`
`MSFT EX. 1021
`Page 16 of 56
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Usability Engineering
`
`the avoidance of unusual word meanings will also be a way to
`improveinternational understandability of an interface.
`To speak the users’ language does not always imply limiting the
`interface vocabulary to a small set of commonly used words. On
`the contrary, when the user population has its own specialized
`terminology for its domain,
`the interface had better use those
`specialized terms rather than more commonly used, but
`legs
`precise, everyday language [Brooks 1993]. Even for the general
`population, specific, distinguishing words are better than bland
`words.
`
`Speaking the users’ language also involves viewing interactions
`from the users’ perspective. For example, a security transactions
`statement should read, “You have bought 100 shares of XYZ
`corp.” and not, “We have sold you 100 shares of XYZ Corp.”
`As another example, consider a computer utility, such as a virus
`guard,that is continuously active, running in the background, but
`which might periodically need to be deactivated for whatever
`reason. One approach might be to introduce an “override mode”
`with a commandthat could be activated wheneverthe user needed
`to perform a task that conflicted with the background utility.
`Unfortunately, the override would be on when the user wanted the
`utility to beoff, so using this model would conflict with the user-
`oriented perspective, even though it might in fact be a perfect
`reflection of the internal workingsof the operating system. A better
`choice would be a reverse model using a dialog box with a
`checkbox for "XY¥Z-utility active: Q.” This design also simpli-
`fies the interface since it has no conceptof a special override mode.
`
`The system should notforce naming conventionsorrestrictions on
`objects namedby the user. For example, users should be allowed to
`use as long names as they want, even though the system may not
`always be able to show very long names without scrolling. If the
`system for some reason cannot handle names longer than a certain
`numberof characters, it should notjust truncate without warning
`the user’s input after that numberof characters. Instead,it should
`offer a constructive error message and allow the user to edit the
`
`a
`
`|
`
`;
`
`4
`
`oa
`
`
`
`124
`
`
`
`MSFT EX. 1021
`Page 17 of 56
`
`MSFT EX. 1021
`Page 17 of 56
`
`

`

`tityHeurlatlos
`Usabllity Heuristics
`
`
` ————
`
`name to be as meaningful as possible within the limitations
`imposed by the system.
`
`Given the advice to speak the users’ language, an obvious idea is
`
`simply to ask users what words and concepts they would like to
`
`see in the interface. Unfortunately,
`the verbal disagreement
`
`phenomenon guaranteesthe failure of that approach: There are so
`
`many different words in common use for the same things that the
`
`probability is very low that a user will mention the most appro-
`
`priate name when asked. Furnasetal. [1987] found that the proba-
`
`bility that two users would mention the same name was no more
`
`than 7-18%, depending on the phenomenonbeing named. Evenif
`
`one asked several users and then picked the name mentioned by
`
`most of them, one would still only match 15-36% of the users. In
`
`other words, the majority of users will be dissatisfied anyway, even
`
`if words are chosen by asking the users themselves.
`
`
`A muchbetter alternative is to let the users vote on the names,
`based onashortlist of possible names. Thislist can be generated by
`several means, including suggestions from the developers, from
`usability specialists, and from asking a few users. In one experi-
`ment [Bloom 1987-88] names for the features in a mail merge
`facility were chosenin three different ways:
`* Technical terms as suggested by the original developers of the
`system: variable field, token character, record, delimiter, etc.
`* The terms suggested by the most users when they were given a
`short description of the concepts: part, marker, unit, period,etc.
`* The winners when users were givenalist of several alternative
`terms and asked to vote: component, placeholder, information
`package, separator,etc.
`Notonly do the winners of the user vote seem more descriptive,
`they also tested much better in a user test. Test users learning the
`system made 11.1 errors on average when using the original
`System with the technical terms, 10.3 errors when using the system
`with the terms suggested by the most users, and only 8.3 errors
`Whenusing the system with the vote-winning terms. For a second
`test, only the technical terms and the vote winners were compared.
`Sers made 14.7 errors when learning the system with the technical
`
`
`125
`
`
`
`
`
`MSFT EX. 1021
`Page 18 of 56
`
`MSFT EX. 1021
`Page 18 of 56
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`i
`
`:
`|
`
`;
`
`i
`:
`i
`
`.
`
`i
`
`a
`
`|
`3
`
`|
`
`|
`
`3
`
`al
`
`ta
`|
`
`Usablllty Engineering
`
`terms andonly 4.6 errors whenlearning the system with the vote.
`winning terms, confirming that the vote-winners madethe system
`easier to learn. However, continued testing after the users haq
`learned the system foundexactly the sameerrorrate (2.0 errors) for
`both sets of names,
`indicating that people can learn basicall
`anything eventually. The test users were finally asked to perform a
`new set of tasks with the system without being allowed accessto
`the documentation. During this transfer test,
`the users of the
`system with the technical terms made 23.6 errors, whereas the
`users of the system with the vote-winning terms made only 5.8
`errors. This latter result showsthat the vote-winning terms enabled
`the users to understand the system better in that they could gener-
`alize their knowledge to correctly use it in new ways.
`
`Given that there are so many waysto refer to the same concepts,
`computers should allow for rich use of synonymsin interpreting
`command languages and in documentation indexes. It should also
`be possible for the users to define aliases (user-defined termsthat
`are translated by the system). Not only may an alias beeasier to
`remember for the user who defined it, but it can also serve as a
`shortcut for complex sequences such as commands with multiple
`parameters or electronic mail addresses. For some applications,
`such as the searching of online documentation or database queries,
`the system itself may build upa list of aliases over time through
`the use of adaptive indexing [Furnas 1985], where new names for
`objects are added every timea user tries a query term that is not
`known by the system, but where the user eventually succeeds in
`finding the relevant information anyway.
`
`Mappings and Metaphors
`A more general way of approaching the goal of a user-oriented
`dialogue is to aim at good mappings between the computer
`display of information and the user’s conceptual model of the
`information. Such mappings are not always easy to discover, as
`exemplified by the case one would naively imagine to be the
`simplest ofall: that of producing a world map [Monmonier 1991].
`
`
`
`MSFTEX. 1021
`Page 19 of 56
`
`MSFT EX. 1021
`Page 19 of 56
`
`

`

`
`Seelyeeedeepreee
`
`ae
`
`Usabllity Heuristics
`
`
`
`
`MSFT EX. 1021
`Page 20 of 56
`
`
`a=SF
`
`
`Unfortunately, the world is round, and the mapisflat, leading to
`all kinds of geographical distortions and the need to select a
`mapping projection suitable for the user’s task.
`To discover such mappings,thefirst step is to perform a task anal-
`ysis and build up an understanding of the users and their domain.
`In addition to talking with users and observing them, it is also
`possible to use more complex methods to build an understanding
`of the users’ knowledge representation and the way they model
`their domain. Typically, users are asked to list or group concepts in
`the domain, and the orderings or groupings are assumed to corre-
`spond to the users’ model of the domain. Some commonly used
`techniques include ordered recall (users are allowed to freely asso-
`ciate and mention as many concepts as they can think of, with
`concepts that are mentioned close together assumedto be associ-
`ated in the user’s mind), card sorting (each conceptis written on a
`card, and the user sorts the cardsinto piles), and paired similarity
`ratings (users are given a questionnaire listing a