Usability Engineering

Scenario-Based Development of Human-Computer Interaction

Mary Beth Rosson, John M. Carroll

• Publisher: Morgan Kaufmann
• Year: 2001
• ISBN:
  9780080520308
• Topic: Computer Science
• Subtopic: Human-Computer Interaction
• Index: Computer Science

You don't need to be convinced. You know that usability is key to the success of any interactive system-from commercial software to B2B Web sites to handheld devices. But you need skills to make usability part of your product development equation. How will you assess your users' needs and preferences? How will you design effective solutions that are grounded in users' current practices? How will you evaluate and refine these designs to ensure a quality product? Usability Engineering: Scenario-Based Development of Human-Computer Interaction is a radical departure from traditional books that emphasize theory and address experts. This book focuses on the realities of product development, showing how user interaction scenarios can make usability practices an integral part of interactive system development. As you'll learn, usability engineering is not the application of inflexible rules; it's a process of analysis, prototyping, and problem solving in which you evaluate tradeoffs, make reasoned decisions, and maximize the overall value of your product.

• Written by prominent HCI educators who understand how to teach usability practices to students and professional developers.
• Interleaves HCI theory and concepts with a running case study demonstrating their application.
• Gradually elaborates the case study to introduce increasingly sophisticated usability engineering techniques.
• Analyzes usability issues in realistic scenarios that describe existing or envisioned systems from the perspective of one or more users.
• Emphasizes the real world of usability engineering-a world in which tradeoffs must be weighed and difficult decisions made to achieve desired results.

CHAPTER 1 Scenario-Based Usability Engineering

During the 1990s scenario-based software development techniques became increasingly prominent in software engineering and human-computer interaction. Anecdotal reports suggest that they are pervasive in contemporary software development practice. A study of 15 software companies in northern Europe reported that all were using various scenario-based techniques. Most of the projects used scenarios in the iterative development and analysis of prototypes. Scenarios were found to be especially useful in helping development teams reach sufficient agreement to enable work to proceed, and in ensuring consistency with predecessor systems. Two of the projects turned to scenario-based techniques after the standard software development methods they had been employing became too cumbersome! All of the projects surveyed emphasized the need for more comprehensive scenario-based methods (Weidenhaupt, et al. 1998).

This introductory chapter discusses the problems in software development that motivate the use of scenario-based development methods. It also provides an overview of the scenario-based framework that forms the basis for the rest of the book and the case study that will be used to illustrate the techniques. We start with a brief example of scenario-based design, then shift to a historical survey of issues in software and usability engineering. We conclude with a discussion of the major phases and methods employed in scenario-based development.

1.1 Design by Scenario: Marissa’s Gravity Project

In the mid-1990s, the U.S. government initiated a broad program of research and development in computer networking called the National Information Infrastructure. One target of this program was public education. It was hoped that networking could facilitate collaborative, project-based classroom learning; increase community involvement in public schools; improve access of rural schools to educational opportunities; enhance gender equity in science and mathematics education; and reduce equipment costs and handling.

In response to this national initiative, we created a partnership between Virginia Tech and the local school system to explore the uses of computer networks in science classrooms. Our initial wish list pointed in many directions; we were excited about the potential of computer networks. But many of the people in the new partnership were not software developers. They were not familiar with networking tools and applications. They were teachers, school administrators, parents, and other citizens. We needed to reach a consensus about the problems we would address and the approach we would take. We needed everyone to understand and agree on a plan.

We started by writing a problem scenario. In this context, a scenario is simply a story about people carrying out an activity; a problem scenario is a story about the problem domain as it exists prior to technology introduction. The problem scenario for this project (Figure 1.1) describes a hypothetical end-of-class situation in middle school science: Marissa has a question, but her question is not simple and well formed, and in any case time has run out. Will the question be in her mind tomorrow? Will it matter to her a day later? Has an opportunity to make science real for one child just been lost?

Figure 1.1 A problem scenario describing an episode from a science class.

Scenarios are good at raising questions. Reading the problem scenario makes you wonder about the other students and what they are thinking. It also makes you think about how science classes work. Why is it important that the class period has ended? Why does this mean Marissa loses access to the teacher? Why can’t Marissa work with other students on the problem? It seems a shame to waste Marissa’s curiosity and energy.

In parallel, we wrote a design scenario that conveyed a new vision for science learning (Figure 1.2). This scenario describes a different experience for Marissa, where she continues to pursue her questions after school. She uses an online environment to collaborate with two other students, running simulation experiments, making visualizations of results, and writing a report. Of course, this is just one of many design scenarios that might have been written. We wrote the story to merge the vision of the National Information Infrastructure program with our own starting biases and interests. But any design scenario would have had the same effect—making the new ideas accessible to our partners from the community and the school system.

Figure 1.2 A design scenario describing our initial vision of a virtual school.

The full story of this educational technology project is a long one (Chin, Rosson, & Carroll 1997; Carroll et al. 1998; Carroll, Rosson, Neale, et al. 2000; Isenhour, et al. 2000). We worked for six years developing a suite of collaboration tools called the Virtual School (Figure 1.3). The tools allowed students from different classrooms (and occasionally with help from community mentors) to work together on science projects. Sometimes they worked together in real time; at other times they worked on their own at different times.

Figure 1.3 A screen shot of some of the tools making up the Virtual School.

This system development project led us in many directions. We had to confront problems of running video conferences across school system firewalls, and to create an architecture for collaborative software. We also had to develop and apply participatory design methods that allowed teachers and students to participate in the design of the collaborative software (Carroll, Chin, et al. 2000).

The current Virtual School consists of several integrated tools. The main window in Figure 1.3 (upper left) shows which members of a collaborating group are currently logged on, their shared notebooks, and recent project activity. It also is used to initiate text chat, video conferencing, and email. The central window shows a project notebook shared by all group members; the student is working on the Robot Pictures section. The student is placing an annotation in that section, soliciting comments from other group members. One of the student’s remote collaborators is working on the Introduction (indicated by the lock on the section tab).

This brief history of the Virtual School project makes a critical point: The system we built is not the system envisioned in the design scenario. Of course this is not shocking—the initial design is almost never the one implemented. What is remarkable is that we wasted no resources in this change of direction. We did not have to build and throw away the wrong system, and then start again and build the right one. In fact, we barely noticed that our design changed in fundamental ways. The reason for this is that we used scenarios to raise and evaluate ideas as they came up. Scenarios let everyone contribute to analysis and design, critiquing proposals as they were suggested, comparing them with current classroom practices, mocking them up on paper, and revising them. Scenarios are rich and evocative design representations, but they are also cheap and easy to revise.

1.2 Managing Software Development

Software development is more than writing code. It is the activity of creating software; it is a process guided by systematic methods and techniques. The process is challenging because software is very abstract and very flexible; it is difficult to “see,” but easy to modify. It is easy to introduce changes that address a specific concern but also undermine the overall design.

In the 1960s, the challenges of software development became enormous. Third-generation computer hardware enabled new applications, leading to software systems of much greater scale and complexity. The resulting failures—cost overruns, late delivery, and ineffective and unreliable systems—were labeled the software crisis. This crisis led to the emergence of software engineering as a professional discipline.

The software crisis has not yet been resolved. In the succeeding three decades, hardware costs continued to plummet, even as performance capabilities soared. Software development methods improved and greater attention was paid to software. Nevertheless, software engineering practices still lag behind the increasing scale and complexity of software systems. No single method or technology has yet provided a remedy for the software crisis (see the “No Silver Bullet” sidebar).

1.2.1 Software Engineering

Software engineering is founded on the ideas of structured programming (Mills 1971): Programmers first define the major structures of a software system—the database, the event handler, and the network server, and so on—and then recursively decompose (break down) each structure into substructures. The driving vision is to gain control over design activities by making the software development process explicit and systematic.

An early and influential model for software engineering was the waterfall: software development is organized into a series of modular phases, beginning with the analysis of functional requirements, and continuing through software design, implementation, testing, and maintenance. Each phase produces one or more documents that are handed off as a specification for the work of the next phase. For example, the software design phase produces a design specification that is used by the implementation phase, which in turn produces the program code used in the integration phase. The waterfall is a wonderful management tool, because projects are organized, tracked, and measured in terms of progress through the phases.

No Silver Bullet

Fred Brooks (1987) analyzed the perennial yearning for a software technology “silver bullet”—a single innovation that could make software development costs drop in the way hardware costs have. He argued that the essence of software is the abstract construction of data, relationships, and algorithms. Software is complex because these constructions are highly precise, uniquely detailed, and invariant under many representations. This inherent complexity is exacerbated by the fact that software is flexible: It can conform to its context of application, so it typically does, at the expense of undermining its own conceptual integrity; it can be changed and changed again without end, so it changes constantly.

Brooks discussed many breakthroughs in the history of software: high-level languages, time sharing, programming environments, and more recently, object-oriented programming, expert systems, and program verification. But he argued that these breakthroughs have addressed the management of software representations rather than the essence of software construction. High-level languages reduce complexity by allowing programmers to think in terms of problem constructs, instead of being distracted by machine implementations that are not directly relevant to data relations and algorithms. Time sharing addresses complexity by allowing programmers to continuously interact with problems, instead of being interrupted by batch processes. Programming environments make it easier to simultaneously use different programs, including standard tools. None of these technologies offers direct support for the develo...

Table of contents

• Cover
• Title Page
• Copyright
• Foreword
• Preface
• Table of Contents
• Chapter 1: Scenario-Based Usability Engineering
• Chapter 2: Analyzing Requirements
• Chapter 3: Activity Design
• Chapter 4: Information Design
• Chapter 5: Interaction Design
• Chapter 6: Prototyping
• Chapter 7: Usability Evaluation
• Chapter 8: User Documentation
• Chapter 9: Emerging Paradigms for User Interaction
• Chapter 10: Usability Engineering in Practice
• Inferential Statistics
• Glosarry
• References
• Figure Credits
• Index
• About the Authors
• Instructions for online access