10.1.1 Usability Specialists in a Development Team

The organizational role of usability engineering in system development is a longstanding issue. In the 1970s, it was common to schedule controlled user tests of nearly final system products. This was not effective. When usability is assessed only toward the end of a development process, the impact of the test results is limited to cosmetic improvements, calls for additional training materials, or requirements for future versions of the product. Through the 1980s, as the computing industry became more competitive and product cycles became shorter, usability issues were raised and addressed at earlier points in development. One response to this was to form and maintain separate usability groups, which acted as a general resource to a number of development teams. Another approach was to integrate usability specialists into the development team.

Figure 10.1 contrasts these two approaches to usability in organizations and summarizes some of the advantages and disadvantages associated with each (Tradeoff 10.1). From a pure design perspective, integration of a usability professional into a project team increases the likelihood that the right use-related questions will be raised and addressed throughout the product development lifecycle. The usability specialist becomes immersed in the problem domain, which helps him or her to produce a design solution that is optimized for the users and tasks of this domain.

Figure 10.1 Alternative organizational structures for integrating usability concerns into product development teams.

However, many organizations cannot (or will not) employ enough usability specialists for every project to have at least one, so assigning a specialist to one project may mean less usability engineering for other projects. There is also a possibility that a usability engineer will become so engaged in project development that he or she begins to think and act more as a designer than as a user advocate. Gathering usability professionals into a separate group that consults with a variety of projects can address these issues, but is likely to lead to a less comprehensive usability engineering process for any one project. The most effective structure for a company depends on many factors: the resources it is willing to spend on usability engineering, the similarities and differences among projects, the experience of its usability professionals, and its own organizational culture.

In the 1990s, usability engineers came to play major roles in both requirements development—a role traditionally assigned to marketing—and design. One trend in this history is that usability has moved steadily “upstream” in the development process, from the evaluation of functional systems, to defining objectives and designing prototypes. A second trend is that usability is beginning to be seen as a critical skill for development teams, rather than as a consulting resource.

A key job requirement for usability specialists is communication. A development team must be able to express a range of technical issues in a common language to understand tradeoffs and resolve conflicts. Because scenarios rely on natural language to describe and elaborate many different kinds of design issues, usability engineers may find them to be very useful for supporting communication among different team members throughout the development process.

One likely trajectory for usability engineering as a profession is further integration into system development. In the past, usability specialists emerged from many different disciplines, including anthropology, computer science, industrial engineering, management science, psychology, and sociology. In contrast, most other members of development teams were trained in computer science. But in the 1990s, human-computer interaction was identified as a core area within computer science and was recommended as a required element in computer science programs (Tucker, et al. 1991). It is likely that in the future usability engineering will become a specialty area of computer science.

10.1.2 Cost-Justifying Usability

If every software developer were trained in the concepts and techniques of usability engineering, we still would not have perfect usability. The reason is that in product development there are inescapable tradeoffs. Some of the tradeoffs are associated with the design issues discussed throughout this book; other tradeoffs arise from finite resources or other management concerns. Producing software that costs more to develop than it can ever return through sales and services does not make sense. The reality of the marketplace not only affects resources for usability engineering, but applies to all costs in system development. Product managers must make tradeoff decisions every day, investing more resources in some aspects and less in others.

Usability engineers must be prepared to argue that any resources invested in usability will provide a profitable return. How can they do this? Cost-justifying usability is a business planning process in which costs and benefits are explicitly planned and quantified (Conklin 1991; Karat 1997). Any planning projection involves assumptions, some of which may later prove to be incorrect. But the point of cost justifying is to be explicit about the assumptions, and to defend them with data, models, and science.

When estimating costs and benefits of usability work, the usability practitioner is faced with a dilemma. To justify resources for analysis, evaluation, and redesign, a clear case for the resulting benefits must be presented. But because these benefits are only predictions, and may often involve intangible consequences such as customer satisfaction, the benefit estimation process must be highly conservative (Tradeoff 10.2). Because benefit predictions are more likely to be wrong, cost predictions are easier to make. Also, contention is more likely on the benefits side, because they are clearly predictions. Unfortunately, the result may be that fewer resources are allotted than necessary to achieve a successful result.

Costs are mainly personnel time and equipment. An estimate can be developed by enumerating specific usability engineering activities that will be carried out. For example, the following list is typical of the usability engineering activities advocated in this book:

• development of requirements scenarios
• validation/refinement of scenarios with users and customers
• development of basic-level task scenarios
• refinement of design scenarios with development team members and customers
• development of information model
• review with team members
• development of paper prototypes
• walk-throughs with users of paper prototypes
• analysis of transcripts/report preparation
• development of interaction model
• review with team members
• development of running prototypes
• formative evaluation
• analysis of transcripts/report preparation
• detailed design and prototype-driven iteration of previous three steps

The costs for each usability engineering activity depend on the scope of the product, the range of functionality, the number of scenarios, the number of users studied, and, of course, the skill and experience of the usability specialists. Each activity can be further detailed and quantified in terms of time and material required. For example, formative evaluation can be decomposed into specific tests, which in turn can be decomposed into the time required to design and set up for each test, the equipment and space required for each, and the time per test session. In addition to the salaries of the usability engineers, reimbursement of the test participants’ time may be an expense.

Usability costs also vary with the facilities available; investment in a permanent usability lab is a large initial expenditure, but significantly decreases the cost of subsequent tests. Organizational factors may aid or impede cooperation with the developers, such as physical co-location with the product development group. Such factors can be quite important, because there is a perception that one major cost of usability engineering is to delay the development process, resulting in lost revenue due to reduced market share. Of course, this concern applies to all product development activities. One remedy is to carry out usability engineering activities in parallel with other development activities, so as not to lengthen total development time.

Benefits are harder to estimate, but there are many positive outcomes that can be attributed to usability engineering:

• fewer downstream design changes
• increased sales (and consequently reduced time to profitability)
• reduced need for user training
• enhanced customer productivity
• reduced resources spent on customer support
• increased loyalty in customer base (repeat and referral sales)

The key to preparing a benefits analysis is to make a set of conservative assumptions about outcomes. For example, one source of benefit is addressing design changes early. Changes made early in the development process cost far less than those made later; for instance, changes made in early prototyping cost about 25% of those made after installation (Mantei & Teorey 1988). Thus, in a benefits projection, it might be assumed that five design changes, each requiring four to eight hours to address, will be identified through formative evaluation and addressed in early stages of development. This could save the development team a week of effort. Although planning for five early design changes of this magnitude is very conservative, it might turn out that three or ten design changes are actually identified, or that they each require two days of redesign work. One way to manage the estimation process is to develop a prediction based on several possible outcomes.

Other benefits of usability work include reduced need for user training and customer support, as well as increased user productivity. Impacts on user productivity can be estimated by projecting average user performance for a set of typical design scenarios, and then calculating the benefits of reducing these performance times by small amounts. For a core scenario—one that users in the workplace would perform at least 20 to 30 times per day—reducing performance time by even half a minute could provide an enormous cost savings for customers. Every user would save 10 to 15 minutes a day, every day for the life of the product. A similar line of argument can be used for designing error-recovery mechanisms, by estimating the time it takes to correct errors. The benefit in these cases is the total time saved multiplied by the salaries of the users.

One major question concerns how to estimate benefit parameters. How can the degree of performance streamlining or error elimination be projected before the project is carried out? This is a reasonable question, but one that applies to all other benefit projections in product development. For example, new product functions must also be justified in terms of their development costs and market value, but it is difficult to do this before the function even exists.

Many of these concerns can be addressed by prior experience. For example, an organization may have a history of developing self-study tutorials or training courses. Cost reductions in these areas are part of the expected benefit of usability engineering and can be explicitly planned. Indeed, the organization’s own track record with respect to sales, new customers, customer support, design changes, and user training is a useful baseline for planning benefits. Another way to add substance to benefit estimations is to review published case studies. Unfortunately, product development case studies are usually not published in enough detail to make the necessary estimates.

Table 10.1 summarizes a retrospective cost-benefit analysis cited in Karat (1997, 774). The project is described as an “internal product built to replace a manual process,” so the value of a successful product should be quite high. However, the cost-benefit analysis of the usability engineering process is limited to the improvement that can be attributed to iterative testing and refinement of the software, not the general move from manual to computer-based support. The projected savings is a function of the task-time reduction, the number of times a task will be repeated in a year, and the costs of personnel who carry out the task.

Table 10.1 Example usability cost-benefit analysis (Karat 1997, 774).

The corresponding costs of the project are based on the actual usability engineering activities carried out in support of the project. These costs included a field test, development of a high-fidelity prototype, and three iterations of usability evaluation and iterative design. The activities took place over a period of 21 months. The final ratio is very high, and though it may not be typical, it could be used as part of a general argument to set aside resources for usability engineering activities.

Some benefits of usability engineering are indirect and cannot be quantified, but are nonetheless useful to consider when cost justifying the usability process. One of these benefits is a better understanding of customer attitudes and workplace practices; this knowledge may be very useful in future development projects. Moreover, because the general public now regards attention to usability as a positive thing, simply being careful to practice usability engineering may have value in terms of customer relations.

10.2.1 User Interface Standards

Standardization sometimes has a bad connotation to designers; it may imply constraints on creativity, raising concerns that good ideas may be blocked by standards that lead to mediocre results. This is certainly a possible negative effect of standardization, but there are strong advantages as well (Tradeoff 10.3). Standards for memory chips, operating systems, network protocols, programming languages, image formats, and, of course, for applications and user interfaces make modern computing possible. Standards have transformed the world, connecting people and information resources inexpensively, reliably, and transparently.

learning for users, BUT at the cost of restricting the design space and making design results less innovative.

There are many standardization efforts. The most visible is the International Organization for Standardization (ISO; http://www.iso.ch/). This standardization effort started in the 1970s and has produced an important document: Ergonomic Requirements for Office Work with Visual Display Terminals (ISO 9241). Many individual countries also have their own standards organizations. Corporate standards document specific user-interface design techniques—Apple Computer’s Macintosh Human Interface Guidelines (1992) was an early example, along with the OSF/Motif Style Guide and the Windows interface design guide (Microsoft 1992).

From a development perspective, the rationale for standards is to avoid reinventing the wheel, to more easily and reliably incorporate best practices into future design work. When standards become established, they can be used to certify products. For example, a customer might require compliance to one or more standards in software contracting. The U.S. government regularly does this. Products that fail to meet government standards can be refused access to the government market, a potentially devastating penalty.

From a user experience perspective, standards are intended to facilitate transfer of learning from one system to another. The pervasive WIMP user interface has become so familiar to many users that they do not even bother to read help or user documentation, preferring instead to explore the user interface controls of a new application until they find what they want. And, of course, if a standard captures best practices as intended, it should increase the usability of user interfaces that conform to it.

Most user interface standards describe specific features such as color assignments, keyboard shortcuts, and so forth. Some are grounded in properties of human psychology and physiology. However, it is difficult to keep the standards current. For example, much of the rationale behind the ISO standard for menu design is based on the systems used in the mid-1980s, but the standard was not ready for publication until 1997.

Recently, the process of usability engineering itself has become a topic of standardization. Standards organizations have recognized that many user interface design issues depend on the context of use. Checklists of features will not ensure usability and may distract attention away from more important issues. ISO 9241-11 requires that the context of use be analyzed during product development. Dzida and Freitag (1998) suggest that one method for implementing such analysis is to develop scenarios in cooperation with domain experts.

10.2.2 Localization

Standardization is a tool for addressing internationalization concerns, but also a challenge for the same concerns. The Internet has created a global computing community. However, the world is not a homogeneous community with a single culture. Indeed, people throughout the world are concerned that regional variation is being threatened by a global computing paradigm. It is easy to see how this could happen. In the limiting case, software costs will be minimized by providing one spreadsheet package for every user in the world: one set of commands and icons, one color palette and color assignment, one keyboard mapping, and, of course, one language—English.

This has already happened to some extent, but there are reasons to rethink this trend. First, the world will become less interesting if regional variations disappear. Second, designing user interfaces that respect cultural knowledge and practices is analogous to designing systems that are appropriate for specific workplace contexts, a widely accepted principle in user interface design.

Some user interfaces employ terms, images, and other elements that would be unacceptable in some cultures. A classic example is the kill command—and various iconic representations of such concepts. In the American computing culture, this concept is fun and vivid, and has become quite standard. However, it may be perceived as violent and disturbing by people from other cultures. A less extreme case would be a dog image in an icon or logo. Some Islamic cultures view dogs as unclean, which would make such imagery unappealing. These examples are relatively easy to address; the offensive command names or images can be changed to a more universally acceptable variant with little or no cost to overall user interaction.

Other examples are more difficult to resolve, because there is no single user interface design that will be effective for all users. A typical example is mailboxes, which are differently shaped and colored in various countries. Even simple attributes such as color may have cultural implications: Black signifies death in Western countries, but rebirth in Egypt; and white signifies purity and life in the West, but death and mourning in China. Date formats vary, as do assumptions about currency, weights, and measures. And, of course, there are many natural languages, including those that are read left to right instead of right to left; and different alphabets, grammatical conventions, and keyboard layouts.

Choong and Salvendy (1999) describe more complex variations among cultures. They have demonstrated that Americans tend to classify things by functions, focus on components, and look for common features. In contrast, Chinese tend to classify things by relationships within wholes, and they rely on subjective experiences. These researchers suggest that such differences are caused in part by family culture: Chinese see themselves as integral parts of their families, whereas Americans are more independent.

Localization refers to a design strategy in which the global computing community is supported with systematic variation among regions and cultures. For example, interfaces for China might emphasize concrete metaphors that rely on the user’s subjective experience; they might also avoid using the color white for meaningful distinctions. Interfaces for North America might do the reverse. Of course, the effectiveness of these particular contrasts is a question for scientific analysis. Localization simply says that the differences should be identified and addressed in design (Fernandes 1995).

A challenge for localization arises from the cost and ambiguity in identifying and characterizing cultural boundaries (Tradeoff 10.4). China is a different culture than North America, but is it a single culture? For that matter, is North America a single culture? There may also be transient differences among cultures; it may be important to track cultural trends. For example, the culture of Coke versus Pepsi has become very salient in contemporary India, but only since 1998. Nevertheless, the slogans and iconography of this marketing battle are pervasive and might provide great leverage to user interface designers pursuing the Indian market.

10.3.1 Changing Scope of Computing

Computing is no longer about computers; it pervades our lives. Computing is embedded in our cars and homes, and in classrooms and libraries; we are using computers in some way almost all of the time. Data and programs are not matrices, storage media, and instructions. They are now our personal safety, the security of our savings, and our very identities. This joining of computing with the world is exciting, but not always comfortable. There are many implications for public safety, education, and access—and for the concept of usability.

Safety is a good example. Concerns about software safety have increased recently, motivated by several horrendous accidents (see “The Therac-25” sidebar). People seem to expect software systems to be safer than mechanical systems. In part, this may be because mechanical failures such as the Tacoma Narrows Bridge incident are easier to see and understand. It may also be due to the cultural myth that software is built from infallible logic, and because it is held in digital storage, it cannot degrade. But, in fact, software systems are more dangerous than mechanical systems because their behavior is more complex, less observable, and more difficult to diagnose. The potential for unanticipated interactions in software is enormous.

Safety has remained a side issue in usability engineering, perhaps because the origins of usability engineering were largely in studies of programming, data processing, and office automation. However, designing for safety and for ease of use are similar in many respects. The challenge in both cases is anticipating combinations of circumstances that may lead to problems. Indeed, safety-oriented requirements have long been a driving force in studies of the human factors of human-machine interfaces. Examples include simple and appropriate underlying conceptual models; clear warnings and prompts; prevention of errors whenever possible; rapid feedback, especially when error is likely; availability of diagnostic information; and support for error recovery.

Unfortunately, designing for safety is much more complex than detecting and correcting user interface problems (Tradeoff 10.5). Like ease of use or satisfaction, safety must be achieved through a comprehensive process in which risks are documented and actively and persistently monitored throughout design, development, and deployment (Leveson 1995). The Therac-25 incident resulted from a combination of failures in software engineering, usability engineering, and project management. Again, as with usability, an effective approach to safety concerns is the collection and analysis of “critical incidents” (in this case, safety-related episodes) during software development. Such reports make the factors that affect safety more concrete. This approach in turn helps team members to recognize other situations that may raise safety concerns, as well as helping to reinforce an organizational culture of safety.

Incident reports can be represented as scenarios, and as such can incorporate many of the usability engineering techniques discussed throughout this book. Scenarios help to project and analyze future possibilities. For example, what sorts of failures are possible, how can they be recognized and diagnosed, and how can a failure be contained? These questions can be addressed in “what-if” variants of incident reports, where the engineers consider the safety consequences of a particular component failure. Indeed, such consequences might be represented as claims, perhaps enabling safety risks to be integrated with other usability risks.

10.3.2 The Digital Divide

A generation ago, computing belonged to computer professionals and a small population of hobbyists. Computing is no longer remote from the culture at large. The use of computing is now required for full participation in society. In industrialized societies, computing skills such as word processing, spreadsheets, and Web browsing are increasingly seen as basic literacy. People must use computing to have access to banking, shopping, communication systems, and even government services.

This has made computing very important socially and economically, but has also made computing mandatory. People who want to have good job opportunities and economic security are not able to choose to use computers any more than they can choose to read and write. People who do not use computers can only be marginal members of society. And yet meaningful access to computing is not available to all (Tradeoff 10.6).

A new phrase has been coined to refer to the disparity in access to computers and networking: the digital divide. For example, 80% of Internet users live in the 15 countries with highest per capita incomes. Asian Americans have the highest level of home Internet access in the United States at 57%; African Americans are at the other end of the spectrum with 23%. People with disabilities are half as likely to have access to the Internet as those without disabilities (National Telecommunications and Information Administration 2000).

In education, computing and networks are the newest panacea. There is a massive initiative in the United States to wire all classrooms, accompanied with exciting visions of lifelong learning supported by the Internet. But it is far from clear just how technology will transform education. Most of the research involves small-scale twiddling with curriculum and delivery, whereas the problems of education are large-scale and systemic. A U.S. Department of Education survey indicates that 45 million Americans—a quarter of the population—are functionally illiterate (National Center for Education Statistics 1999). Most of the early and encouraging results of educational technology may be due to simply providing students and teachers with new and exciting experiences. Whether this novelty will mature into new educational practices and opportunities is a serious question.

Whatever benefits technology may bring to education, it is clear they are now concentrated in wealthy, suburban school districts. Rural and inner-city schools have much less access to computing and network technologies. The U.S. Commerce Department has estimated that a child’s chance of being excluded from information technology is 20 times greater if the child is poor and lives in a rural area (National Telecommunications and Information Administration 2000).

There are many initiatives underway to address the digital divide. Some of these provide public access to the Internet, for example, in public libraries. Many local initiatives can be grouped under the concept of community networks. Indeed, the virtual science fair example used in this book is a community network application.

10.3.3 Meeting the Needs of Special Populations

People are not all the same. Individuals vary in many ways, and these differences can have implications for their technology needs. Large or small people may need special keyboards; one size does not always fit all. It is important to keep special needs in mind when designing and evaluating user interfaces and applications, seeking to provide new opportunities and minimizing the challenges faced by these populations. Addressing the needs of special populations may also help in developing generally useful innovations.

An important category of special needs is users with disabilities. Of course, computers already provide significant new opportunities for some types of disabilities (Edwards 1995). For example, people with hearing impairments suffer greatly from social isolation. But they can now participate much more fully in the social world through email and other computer-based communication tools. User interfaces can be modified to convert tones into visual display elements, providing access to most of the information typically conveyed in user interfaces.

In many cases, accommodations for disabled users are applicable to other user interface situations. For example, head-mounted pointing devices are often designed for people with limited mobility, and speech recognition and speech synthesis are provided for visually impaired people. The development of these input and output technologies was driven to a considerable extent by special needs. But the resulting techniques are also useful to anyone with a hands-free requirement (e.g., industrial and military applications). Dynamic enlargement of display elements is effective for users with vision impairments, but also serves a general need of elderly users, many of whom experience gradual but progressive visual impairment. A user interface for a hearing-impaired person may also be useful in noisy environments such as factories or airport runways.

Elderly users are often discussed as a special population, but they are a major demographic segment. Age-related changes in vision begin to appear in the early forties. Thus, for vision-related issues, the elderly constitute 40% of the population in Western countries. In general, aging entails progressive decline in physical strength, speed, flexibility, perceptual acuity and recognition, and some kinds of memory and learning. Despite such impairments, many elderly people are eager and able to carry out complex activities. However, if the needs and preferences of elderly users are not factored into the usability engineering process, the resulting user interfaces may be unsuitable or unattractive to them (Tradeoff 10.7). The same is true for any user population with special needs.

Some accommodations are straightforward: larger fonts and greater contrast in display elements, low-pitched voices for speech output (hearing acuity declines more for high-pitched sounds), slower blink rates on cursors and warnings, adjustable parameters for double-clicks and menu manipulation, and larger mouse targets (Hawthorn 2000). Older users are more disrupted by errors and may benefit from a finer level of confirmation dialog. Older users have difficulties with new behaviors that conflict with existing habits; they cannot replace overlearned behaviors as easily as younger people. Thus, the cognitive “cost” of adopting new user interfaces may be higher for an older user.

In many cases, accommodations for the elderly result in general and robust user interface characteristics. Because older users have a reduced capacity for managing complex window layouts, designing simple window management schemes and avoiding purely decorative graphical embellishments are useful strategies. But as discussed in Chapter 4, this is a desirable approach for user interface design in general (Mullet & Sano 1995). Speech recognition for older users must cope with slow and less fluent speech, hesitations, interruptions, and filled pauses. But again, these phenomena are not limited to older users, and addressing such problems will create more robust speech technology.

Elderly users often perform far better than one might expect based on the progressive declines associated with aging. Thus, we need to better understand the compensatory strategies developed by successful elderly users, since these strategies could help other users, including younger users who experience difficulties with various aspects of user interfaces (Czaja 1990).

Computing also offers new possibilities for seniors. It allows many activities to be undertaken at home, without walking or driving to a new location. Computing enables connections with peers through Internet services such as SeniorNet, opportunities to participate in a wide range of online activities, and easy access to the wealth of information available over the Internet. From December 1998 to August 2000, individuals 50 years of age and older—while less likely than younger Americans to use the Internet—experienced a 53% growth rate in Internet usage, compared to a 35% growth rate for individual Internet usage nationwide.

10.3.4 Technology Evolution and Unintended Consequences

There will always be unexpected costs that come along with exciting technology visions and innovations (Tradeoff 10.8). Over the past 40 years computing has dramatically improved reliability and access in record keeping, but at the same time it has raised new challenges of privacy and security for legal, medical, and financial records. The Internet in particular has provoked many tradeoffs. It enables easy access to an unprecedented volume of information. But much of this information is unreliable, some is unwelcome, and people feel the stress of information overload. The Internet has provided many new ways for people to interact and form groups, but people who use the Internet more may have fewer face-to-face meetings with family, friends, and colleagues.

The very term “technology evolution” suggests a somewhat hit-or-miss process of innovation and selection. It uses an analogy to biological evolution, suggesting random mutation and subsequent survival of the fittest. It is indeed possible to look at the history of technology through this analogy. But it is not desirable. Random mutation is a wasteful way of managing innovation. As with biological evolution, it could take millions of trials to achieve good design. And survival of the fittest entails that people will have to try out and finally reject many inappropriate technological innovations in order to find a few that are appropriate. As we look to the future, we should consider how technology development can become more rational, deliberate, and efficient.

One key is to cultivate a system development process that integrates consideration of requirements for new technology with analysis of how people will use and experience the technology. Ultimately, designers enable scenarios. They create tools and environments that enable new ways of carrying out tasks and entirely new possibilities for tasks. If technology is seriously thought about as enabling support for human activities, then technology development can be far more efficient than mere evolution. Designers can find out what people expect, what they value most in what they currently do and know, what their needs and desires are, and so forth.

This is what scenario-based usability engineering is for. No design method can guarantee good solutions, but a design method should at least guarantee good questions. Scenario-based design tries to identify the critical and typical things that people do or want to do and the tradeoffs associated with design features that enable these activities. Many of these tradeoffs are inherent. Increasing the efficiency of user interactions improves ease of use, but conveys to people that their activities are less complex and less valuable. Designers can address such tradeoffs, finding good balance points for particular issues, but design tradeoffs are never just problems that are solved once and for all.

Usability is a broad concept. It will become broader as computer systems continue to pervade and transform human experience and activity. Computers should ease and enrich people’s lives, not through a stumbling evolution that creates and then fixes unintended consequences, but through a thoughtful and systematic engineering process. Designers and users should expect nothing less.

Summary and Review

This chapter has discussed some of the more complex issues surrounding the practice of usability engineering in software development organizations. Earlier chapters have presented a somewhat idealized view of problem analysis, scenario generation and revision, and evaluation, but in practice these activities are carried out in the context of many other impinging concerns. Central points to remember include:

• Usability specialists are becoming increasingly integrated within software development teams, which means that the emphasis on communication skills is greater than ever.
• Usability engineers are often expected to cost justify the usability process they plan to conduct, including the development of quantitative estimates of usability benefits.
• The trend toward greater standardization is opening up possibilities for computing on a global level, but development efforts must at the same time take care to respect the local needs and culture of their target users.
• Beyond the concrete goals of creating fluent and pleasant user interface techniques, usability engineers must consider broader issues such as the safety of computing and access by diverse populations with special needs.
• Attending to the needs of disabled users or other special populations is often an indirect strategy for discovering more robust and generally useful interaction techniques.
• Technology will evolve whether we want it to or not. Scenario-based design techniques force attention to intended and unintended consequences of technology features, which in turn help to guide this evolution in appropriate directions.

Exercises

1. Critique your favorite Web site for use by people with visual impairments. Assess it with respect to:
   • font style and size—small and highly decorative fonts are difficult to perceive,
   • number and intensity of color distinctions—many subtle distinctions are hard to detect,
   • use of white space—crowded displays are hard to decompose and organize, and
   • visual contrast—low-intensity contrasts are more difficult to perceive.

   Respond to your critique with suggestions for redesign. Discuss the extent to which your suggested changes would improve the quality of the information design for users in general (with respect to both performance and satisfaction).

2. Design of the controls on an automobile dashboard clearly has safety implications that must be addressed during development. What additional activities or structures would you include in scenario-based development of such a display? Use as a contrast the process used to develop the virtual science fair.
3. Choose a central screen from your class project (if you did not do a class project, choose some other simple application, such as a Web information system). Invite an international student or other foreign visitor to help you analyze the screen and interaction techniques from the perspective of his or her culture. Is it possible to translate the terms directly? Why or why not? Do the images on the screen have the intended meaning? Are there higher-level characteristics (e.g., ordering or layout of different components) that lead to different interpretations for this person than are intended by the design?

Project Ideas

Develop a cost-benefit analysis for your online shopping project. If you have been able to do at least one design iteration and test, use the costs of the iteration, and the resulting task performance and user satisfaction improvements, as a basis for the analysis. Otherwise, establish a set of assumptions about costs and benefits. Remember to make your benefit predictions conservative, but be as detailed and accurate as possible in your cost estimates. Once the analysis is complete, discuss how you would present it to a project manager. Would he or she be persuaded to give you more resources for this project (or future ones)? Why or why not?

Recommended Readings