kob Nielsen
`
`I Usability Engineering
`
`
`
`MSFT EX. 1021
`
`Page 1 of 56
`
`MSFT EX. 1021
`Page 1 of 56
`
`

`

`
`
`Usability Engineering
`
`JAKOB NIELSEN
`
`————_________________
`
`SunSofl
`2550 Garcia Avenue
`Mountain View, California
`
`MU
`
`Morgan Kaufmann
`An Imprint of Eisevier
`
`Amsterdam Boston Heidelberg London New York Oxford
`Paris San Diego
`San Francisco Singapore
`Sydney Tokyo
`——_____‘_____________—_
`
`
`
`MSFT EX. 1021
`
`Page 2 of 56
`
`MSFT EX. 1021
`Page 2 of 56
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`This book is printed on acid-free paper.
`
`Copyright © 1993 by Academic Press.
`
`An Imprint of Elsem'er
`
`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.
`
`Permissions may be sought directly from Elsevier‘a Science and Technology Rights Department in
`Oxford. UK. Phone: (44) L865 E43830. Fax: {44} 1365 853333. e-mail: petmissions®elsevier.co.uk.
`You may also complete your request tin-line via the Elsevier homepage: http:/lwww.elsevier.com by
`selecting "Customer Support" and than “Obtaining Permissions".
`
`All brand names and product names are trademarks or registered trademarks of
`their respective companies.
`
`ACADEMIC PRESS
`An Imprint of Elm/{er
`525 B Street, Suite l900. San Diego, CA 92l0l-4495 USA
`http:llwww.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 bound in the United Kingdom
`
`Transferred to Digital Printing. 2010
`
`
`
`MSFT EX. 1021
`
`Page 3 of 56
`
`MSFT EX. 1021
`Page 3 of 56
`
`

`

`
`
`Table ofContents
`
`
`
`Preface
`
`ix
`Audience
`
`ix
`
`Teaching Usability Engineering xi
`Acknowledgments
`xiii
`
`1
`
`2
`
`Executive Summary
`1.1
`Cost Savings
`1.2 Usability Now!
`10
`1.3 Usability Slogans
`1.4 Discount Usability Engineering
`1.5 Recipe For Action
`21
`
`
`
`Chapter 1
`
`Chapter 2
`
`8
`
`17
`
`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
`
`24
`
`2.4
`2.5
`
`41
`Usability Trade-Offs
`Categories of Users and
`Individual User Differences
`
`43
`
`MSFT EX. 1021
`
`Page 4 of 56
`
`MSFT EX. 1021
`Page 4 of 56
`
`

`

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

`

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

`

`
`
`_____—__.__———.-———-——-
`Usability Engineering
`
`.u'
`
`Chapter 10
`
`Future Developments
`10.1
`Theoretical Solutions
`10.2
`10.3
`
`255
`
`256
`
`260
`Technological Solutions
`CAUSE Tools: Computer-Aided Usability
`Engineering 264
`Technology Transfer
`
`265
`
`10.4
`
`Appendix A
`
`Exercises
`
`269
`
`Appendix B
`
`283
`Bibliography
`8.1
`Conference Proceedings
`8.2
`Journals
`286
`8.3
`Introductions and Textbooks
`8.4
`Handbook 291
`
`284
`
`290
`
`B.5\
`8.6
`
`292
`Reprint Collections
`Important Monographs and Collections of
`Original Papers
`294
`Guidelines
`300
`
`8.7
`8.8
`302
`Videotapes
`B.9
`pther Bibliographies
`306
`8.10 References
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Author Index
`
`Subject Index
`
`341
`
`351
`
`
`
`304
`
`MSFT EX. 1021
`
`Page 7 of 56
`
`MSFT EX. 1021
`Page 7 of 56
`
`

`

`115
`
`
`
`
`
`MSFT EX. 1021
`
`Page 8 of 56
`
`Chapter 5
`
`
`
`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 charactervbased 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 chapter with infor-
`mation on how to use usability heuristics as a basis for a systematic
`inspection of a user interfaca to find its usability problems (the
`heuristic evaluation method).
`
`
`
`5-1 Simple and Natural Dialogue
`
`User interfaces should be simplified as much as possible, since
`eVEry additional feature or item of information on a screen is one
`more thing to learn, one more thing to possibly misunderstand,
`and One more thing to search through when looking for the thing
`5’0“ Want. Furthermore, interfaces should match the users“ task in
`as natural 3 way as possible, such that the mapping between
`computel' concepts and user concepts becomes as simple as
`3351131.: and the users’ navigatiOn through the interfaCe is mini-
`lzeci.
`
`
`u-o-u—v-
`
`
`
`.._..i._.v..i._...~..-
`
`MSFT EX. 1021
`Page 8 of 56
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`I:
`u'
`
`
`Usablllty Englneerlng
`
`HmmHHM'mm mm m mmmmr‘riri
`Mm mmmmmm min
`HmrnHl'lH’rnm mmm rn mm Mmm Mm ,Mmm
`Mmmm T-lmmmln mm-mm, mm mm mm mmm
`mmm—mmm mmmm mmmrnm m mm mmmm mmmm
`Mmmm mm mmmm, rnmmmmm mm mmm mmnunmm m
`I mnmmmm mmmmm mmmm m Inmmmm m m mm
`mmmm mmm Mm mmm lrl mmm mmm mmmmm
`mmm mmm mmm mmmmm mt mmm mm m mmmm m
`" mmm "W" m "1m mmm m mmm mm mmmrnm:
`
`-
`
`'
`
`«mmm mmmmm
`Nrnrnm mm mm m m mmm mmm mm mmm
`mmm m mmmm mm mmnun mm mm mrnmm mmmm
`mmmrr-m m m mmmmm mmrnmlnm. Mmrn rn mmm rn
`mmm mm m rnm mmmm in mm mmmm mmm mm mmm
`rn mmm mmm mm mm mm mm mmm, Mm mm mmm
`mm, mmmm mm mmm mmmm mmmm mm mmm mmm
`- mm mm mmm m mmm mmm m mmm mmmrn lnrnmmm‘
`_ M m mm mmm mmm rn mmm mmm mm mmm mm mm
`mmmm mm mmm mm /m mm mm Inm/mm mmmm, mm
`.. mm mmmm (mm mmm mmm) mm mm mm mmm
`
`I
`
`"
`
`E
`
`.
`
`.t
`
`'
`
`”
`“W‘JH‘M”. _- _.i:
`' " a
`w“
`"
`
`mm mm melanin-mm
`
`
`
`
`
`
`
`
`
`
`Figure 11 Mumbie screen layout for a h pertext system. The actual
`system is described in [Nielsen 1990a, I9901‘}?The screen could be made to
`
`
`abstract even further from the information content in the fuii system by
`reptacing the icons with generic shapes.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`The ideal is 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 most effectively and productively
`do things. Sometimes such sequences are enforced by the user
`interface, but it 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 by indicating a suggested or preferred sequence, such
`as the sequence implied by the listing of fields in a dialog box from
`top to bottom.
`
`
`
`
`
`
`
`
`
`MSFT EX. 1021
`
`Page 9 of 56
`
`MSFT EX. 1021
`Page 9 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
`detailefl information content in the system and focus on layout
`issues.
`
`._.-.__——-.-
`
` in._._.__.._..._...._r
`
`Screen layouts should use the gestalt rules 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 would think that the left set of objects contained
`two sets of objects that were even more closely 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
`1t is smaller.
`
`These principles of graphic structure should be used to help the
`user understand the structure of the interface. For example, menus
`can 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 seen in a relevant context.
`EEK——
`1' MUmble text has also been used as a task analysis technique for finding out
`o
`.
`helher users gain information simply from the way information is
`resented
`Hi? iUrn-i Without reading the detailed data [Nygren at at. 1992]. I
`they do,
`"mil one Sh0ulcl design similar capabilities for users in a computerized infor—
`‘ “on environment.
`
`
`
`
`
`117
`
`MSFT EX. 1021
`
`Page 10 of 56
`
`MSFT EX. 1021
`Page 10 of 56
`
`

`

`
`
`i
`
`i
`
`l
`
`
`
`
`
`H_.fi...,___...__._F.—.-.-_i.i._._._.._.
`
`g
`j
`
`I||
`
`Usablllty Englneerlng
`
`OO
`
`000
`
`000
`O
`
`000
`
`0.000
`
`0.
`
`O
`
`0
`
`GOO GOO GOO GOO
`
`O
`
`0 0 O O 0
`O
`
`00000
`
`Figure 12 Example of objects structured according to the gestalt princi-
`
`pies ofcloseness, closure, and similarity.
`
`Similarly, dialog boxes can group related 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:
`
`Elance
`$1,000.00‘
`2,000.00
`
`$
`
`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 as a label for the 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 shown by the 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
`
`usualreadingdirection (that is, at the top and to the left 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
`
`
`118
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`MSFT EX. 1021
`
`Page 11 of 56
`
`MSFT EX. 1021
`Page 11 of 56
`
`

`

`________._._————-———
`
`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.
`
`With respect to the use of color in screen designs [Rice 1991; Travis
`1991], the three most important guidelines are
`
` Usabillty Heuristics
`
`0 Don’t over—do it. An interface should not look like an angry fruit
`salad of wildly contrasting, highly saturated colors. It is better to
`limit the design to a small number of 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.
`Remember that 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 without being 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 be to have a selection
`of colorblind users try out the system, but it would be difficult to
`do so comprehensively as there are many different types of color
`blindness.
`In addition to having at least some colorblind test
`Users, one can also check how the interface looks on a mono—
`chrome screen. In many cases, some users will be limited to
`monochrome displays anyway.
`-.____________‘___‘
`
`2- Being "colorblind" normally does not mean than one cannot distinguish
`"‘5’ colors at all, so the expression is somewhat inaccurate. About 6% of males
`and 0.4% of females are partially red—green colorblind (and so can distinguish
`E‘E'lfzws and blues as well as some shades of green and red}, 2% of males and
`0-031: of females are full
`redwgreen colorblind, and only 0.005% of males and
`T-h 3 In 0f females are ye loweblue or completely colorblind [Silverstein 19871.
`tesfref‘ffie. a test with a single colorblind user (while much better than no such
`be llell not guarantee that all types of users with color-deficient vision will
`a
`15‘ to use the interface without problems.
`
`
`
`119
`
`
`
`MSFT EX. 1021
`
`Page 12 of 56
`
`MSFT EX. 1021
`Page 12 of 56
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`——.—.—-—-o---noun__.._
`
`
`__..7‘.._A.._..—_.___..—n—‘._...h-._.._.-.._.
`
`
`
`
`
`i
`
`l
`1
`
`',
`l
`i
`
`1l
`
`lI | |
`
`._.
`
`Usability Engineering
`
`0 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
`present our help screens in 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 Conn and Queen Thyre.4 Similarly, adding infor-
`mation and data fields to a user interface can distract the user from
`the primary information.
`Based on a proper task analysis, it is often possible to identify the
`information that is truly important to users and which will enable
`them to perform almost all 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 programs follow 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 Ielling rune stone from the first
`half of the tenth century: "King Gorm raised these memorials to his wife Thyre, the
`joy of Denmark.” The runes are fewer, but the message is focused.
`
`
`120
`
`MSFT EX. 1021
`
`Page 13 of 56
`
`MSFT EX. 1021
`Page 13 of 56
`
`

`

` Usability Heuristics
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`_
`I'
`.'l
`=
`-
`
`i
`
`-
`'
`'
`
`.
`
`large amounts of screen space to a display of the name of the
`program, 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 even as white space to make for 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 down their performance by some fraction of a second. It is
`better to provide identifying information as part of 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. 19891 to be shown only in the rare case when
`a user actually needs this system—oriented information.
`.
`.
`.
`.
`.
`Extraneous information not only risks confusing the novice user,
`but also slows down the expert user. 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 was half full of information and
`6-2 seconds when the screen was full of information [Springer
`1937i Saving 0.9 seconds may not seem like 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 is more“ rule does not just apply to the information
`Contents of screens but also 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
`1er'rolfteously) and the manual gets bigger, more intimidating, and
`Bartlet to search. One study found that the users’ planning time for
`orInula 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
`
`

`

`
`
`—.——_—_-—-————————-——'—-.-
`Usablllty Englneerlng
`
`"
`l
`.‘
`
`
`''w—.——«=——_“.m—.....
`.—._..—-.y—.r-..__—_._-
`
`
`
`I
`!
`
`1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`i
`5
`
`I
`1
`
`l
`1
`'
`
`another [Olson and Nilsen 198?—88]. The first spreadsheet was
`faster because it only provided a single method for formula entry
`and therefore did not require users to think about which method to
`use.
`in contrast,
`the second spreadsheet provided multiple
`methods, with the result that the users were slowed down more by
`having to choose betWeen methods than the amount of time they
`sometimes gained from being able to use a "faster" method for
`certain formulas.
`
`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 provided if users can easily recognize the conditions
`under which each one is optimal so that they can consistently
`choose the optimal interaction technique without additiOnal plan-
`ning. For training, users should at first be taught only the single,
`general method that is preferable in most common situations.
`Other methods can be taught later but should not be introduced at
`a stage when they will 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 two levels 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 where they 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 and type a letter in 116 minutes when they
`were faced with the full 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
`
`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
`res faster than users who had been using the
`learned advanced featu
`full system all the time [Catrambone and Carroll 1987].
`
`'
`
`I
`:
`
`:
`
`L
`;
`
`I
`
`I
`
`g2 I 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, even if 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.
`in the users’ native
`5 should be.
`As far as possible, dialogue
`see Chapter 9 for a discus-
`1iirlguage and not in a foreign language (
`Slon of translation and other titer-nationalization issues). Of course,
`Concerns for the users’ "language" should not be limited to the
`words in the interface but should include nonverbal elements like
`100118 (see page 38 for a discussion of how to elicit ideas for intui—
`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
`'
`appens to be the standard use of the word
`"at dictionaries exist to help distin-
`ords from less common meanings.
`gush common meanings of w
`81] lists 44,000 English word
`or ‘3)fample, [Dale and O’Rourke 19
`how many Americans know
`statistics are only valid in the
`mally assume that
`
`:ZCh meaning. Even though such
`“ntry Where they were collected, one can nor
`
` 123
`
`
`
`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
`improve international 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 SPEClalized
`terminology for its domain,
`the interface had better use those
`specialized terms rather than more commonly used, but
`less
`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 command that could be activated whenever the 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 be off, so using this model would conflict with the user~
`oriented perspective, even though it might in fact be a perfect
`reflection of the internal workings of the operating system. Abe tter
`choice would be a reverse model using a dialog box with a
`checkbox for "XYZ—ut ii i ty active: El.” This design also simpli-
`fies the interface since it has no concept of a special override mode.
`
`The system should not force naming conventions or restrictions on
`objeds named by 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
`niunber of characters, it should not just truncate without warning
`the user’s input after that number of characters. Instead, it Should
`offer a constructive error message and allow the user to edit the
`
`
`
`124
`
`_
`.
`f
`'I'
`'r.
`
`.i
`
`.
`
`-
`
`I'
`-
`
`
`
`MSFT EX. 1021
`
`Page 17 of 56
`
`MSFT EX. 1021
`Page 17 of 56
`
`

`

`
`ifUsablllty Heurlstlcs
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`J:-
`
`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 guarantees the 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. Pumas et al. [1987] found that the proba-
`bility that two users would mention the same name was no more
`than 748%, depending on the phenomenon being named. Even if
`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 much better alternative is to let the users vote on the names,
`based on a shortlist of possible names. This list 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 chosen in 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 given a list of several alternative
`terms and asked to vote: component, placeholder, information
`PaCkage, separator, etc.
`
`Not only 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
`SY_Stem with the technical terms, 10.3 errors when using the system
`With the terms suggested by the most users, and only 8.3 errors
`when using the system with the vote-winning terms. For a second
`test, only the technical terms and the vote winners Were compared.
`Users 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_._———._.—_——-————..._l_m'l
`Usablllty Engineering
`
`. ‘5
`
`terms and only 4.6 errors when learning the system with the votes
`winning terms, confirming that the vote—winners made the system
`easier to learn. However, continued testing after the users had
`learned the system found exactly the same error rate (2.0 errors) for
`both sets of names,
`indicating that people can learn basically
`anything eventually. The test users were finally asked to perform a
`new set of tasks with the system without being allowed access to
`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 shows that 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 ways to refer to the same concepts,
`computers should allow for rich use of synonyms in interpreting
`command languages and in documentation indexes. It should also
`be possible for the users to define aliases (user—defined terms that
`are translated by the system). Not only may an alias be easier 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 up a list of aliases over time through
`the use of adaptive indexing [Furnas 1985], where new names for
`objects are added every time a 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 of alt: that of producing a world map [Monmonier 1991].
`
`:
`I
`
`'
`
`1
`'
`I
`
`|
`
`'I
`
`I
`
`I
`
`!
`
`;
`
`'7
`
`5|
`'
`l
`
`;
`
`l
`
`
`
`
`
`MSFT EX. 1021
`
`Page 19 of 56
`
`MSFT EX. 1021
`Page 19 of 56
`
`

`

`
`
`
`.4'._r—._'.—.—-.-__.-Io—.——p--JTM——e..
`
`UsabIIlty Heuristics
`
`
`
`Unfortunately, the world is round, and the map is flat, leading to
`
`all kinds of geographical distortions and the need to select a
`mapping projection suitable for the user’s task.
`
`
`
`MSFT EX. 1021
`
`Page 20 of 56
`
`
`
`___uIn..—"
`
`
`
`-__.,_.._._..—_.-—.._—._.,_.,
`
`To discover such mappings, the first step is to perform a task anal-
`ysis and build up an understanding