- Shopping Bag ( 0 items )
Good user interface design isn’t just about aesthetics or using the latest technology. Designers also need to ensure their product is offering an optimal user experience. This requires user needs analysis, usability testing, persona creation, prototyping, design sketching, and evaluation through-out the design and development process. User Experience Re-Mastered takes tried and tested material from best-selling books in Morgan Kaufmann’s Series in Interactive Technologies and presents it in typical project ...
Good user interface design isn’t just about aesthetics or using the latest technology. Designers also need to ensure their product is offering an optimal user experience. This requires user needs analysis, usability testing, persona creation, prototyping, design sketching, and evaluation through-out the design and development process. User Experience Re-Mastered takes tried and tested material from best-selling books in Morgan Kaufmann’s Series in Interactive Technologies and presents it in typical project framework. Chauncey Wilson guides the reader through each chapter, introducing each stage, explaining its context, and emphasizing its significance in the user experience lifecycle. This gives readers practical and easily applicable direction for creating web sites and web applications that ensure the ultimate experience. A must read for students, those new to the field, and anyone designing interfaces for people!
*A guided, hands-on tour through the process of creating the ultimate user experience – from testing, to prototyping, to design, to evaluation
*Provides tried and tested material from best sellers in Morgan Kaufmann’s Series in Interactive Technologies, including leaders in the field such as Bill Buxton and Jakob Nielsen
*Features never before seen material from Chauncey Wilson’s forthcoming, and highly anticipated Handbook for User Centered Design
Jakob Nielsen has been a leading figure in the usability field since the 1980s and this chapter from his classic book, Usability Engineering (Nielsen, 1993), highlights the multidimensional nature of usability. To be usable, a product or service must consider, at a minimum, these five basic dimensions:
* Error tolerance and prevention
An important point made by Nielsen and other usability experts is that the importance of these dimensions will differ depending on the particular context and target users. For something like a bank automated teller machine (ATM) or information kiosk in a museum, learnability might be the major focus of usability practitioners. For complex systems such as jet planes, railway systems, and nuclear power plants, the critical dimensions might be error tolerance and error prevention, followed by memorability and efficiency. If you can't remember the proper code to use when an alarm goes off in a nuclear power plant, a catastrophic event affecting many people over several generations might occur.
In the years since this chapter was published, the phrase "user experience" has emerged as the successor to "usability." User experience practitioners consider additional dimensions such as aesthetics, pleasure, and consistency with moral values, as important for the success of many products and services. These user experience dimensions, while important, still depend on a solid usability foundation. You can design an attractive product that is consistent with your moral values, but sales of that attractive product may suffer if it is hard to learn, not very efficient, and error prone.
Jakob's chapter describes what is needed to establish a solid foundation for usability – a timeless topic. You can read essays by Jakob on topics related to many aspects of usability and user experience at http://www.useit.com.
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. 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 interface professionals have tended to use other terms in recent years. The field itself is known under names like computer–human interaction (CHI), human–computer interaction (HCI), which is preferred by some who like "putting the human first" even if only done symbolically, user-centered design (UCD), man-machine interface (MMI), human-machine interface (HMI), operatormachine interface (OMI), user interface design (UID), human factors (HF), and ergonomics, 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 the following section, there are also broader issues to consider within the overall framework of traditional "user friendliness."
USABILITY AND OTHER CONSIDERATIONS
To some extent, usability is a narrow concern compared with 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 identifying 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, compatibility with existing systems, as well as the category of usefulness. Usefulness is the issue of whether the system can be used to achieve some desired goal. It can again be broken down into the two categories, utility and usability (Grudin, 1992), where utility is the question of whether the functionality of the system in principle can do what is needed and usability is the question of how well users can use that functionality. Note that the concept of "utility" does not necessarily have to be restricted to the domain of hard work. Educational software (courseware) has high utility if students learn from using it, and an entertainment product has high utility if it is fun to use. Figure 1.1 shows the simple model of system acceptability outlined here. It is clear from the figure that system acceptability has many components and that usability must trade-off against many other considerations in a development project.
Usability applies to all aspects of a system with which a human might interact, including installation and maintenance procedures. It is very rare to find a computer feature that truly has no user interface components. Even a facility to transfer data between two computers will normally include an interface to trouble-shoot the link when something goes wrong (Mulligan, Altom, & Simkin, 1991). As another example, I recently established two electronic mail addresses for a committee I was managing. The two addresses were ic93-papers-administrator and ic93-papers-committee (for e-mail to my assistant and to the entire membership, respectively). It turned out that several people sent e-mail to the wrong address, not realizing where their mail would go. My mistake was twofold: first in not realizing that even a pair of e-mail 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 e-mail message might be excused for thinking that the message was going to one address even though it was in fact going to the other.
DEFINITION OF USABILITY
It is important to realize that usability is not a single, one-dimensional property of a user interface. Usability has multiple components 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, catastrophic 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 components can we arrive at an engineering discipline where usability is not just argued about but is systematically approached, improved, 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 whatever 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 technical documentation. 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. Because users are known to be very different, it is probably better to consider the entire distribution 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 percent of the users should have given the system the top rating, 5; and that no more than five percent of the users gave the system the bottom rating, 1.
Learnability is in some sense the most fundamental usability attribute, because most systems need to be easy to learn and because the first experience most people have with a new system is that of 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 Fig. 1.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). Exceptions 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 new release (Telles, 1990). Assuming that the new system is reasonably consistent with the old, users should be able to start a fair bit up on the learning curve for the new system (Polson, Muncher, & Engelbeck, 1986).
Excerpted from User Experience Re-Mastered Copyright © 2010 by Elsevier Inc.. Excerpted by permission of Morgan Kaufmann. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Part I- Usability Chapter 1: Usability Engineering, by Jakob Nielsen Chapter 2: Usability for the Web, by Tom Brinck Chapter 3: Understanding Your Users, by Cathrine Courage Part II- Generating Ideas Chapter 4: Handbook of UCD Methods, by Chauncey Wilson Chapter 5: Sketching User Experiences, by Bill Buxton Chapter 6: The Persona Lifecycle, by John Pruitt Chapter 7: Effective Prototyping for Software Makers, by Jonathan Arnowitz
Part III- Designing Your Site Chapter 8: User Interface Design and Evaluation, by Debbie Stone
Part IV-Evaluation & Analysis Chapter 9: Evaluating Your Product, by Debbie Stone Chapter 10: Observing the User, by Mike Kuniavsky Chapter 11: User Interface Design and Evaluation, by Debbie Stone Chapter 12: User Interface Design and Evaluation, by Debbie Stone