Scenario-Based Design

Envisioning Work and Technology in System Development

Book Review by Paul McInerney

Bob, an HCI specialist employed at the Toronto Bank, has been assigned to work on the "S.T.A.R.D.R.E.C.K" project which starts next month. He is finishing a usability evaluation report for another project when Cheryl, the STARDRECK project manager, walks in. She says, "I know you HCI types use scenarios in your usability evaluations. But, I've heard that scenarios can also be used in the requirements analysis and system design phases of a systems development project. I want you to recommend a scenario technique to use on our project, where it should fit in our standard project methodology, and how much resources need to be allocated. Have your recommendations ready in five days so I can finalize my project plan."

The project manager continued, "I have something to get you started, a book entitled Scenario-Based Design. The book cover states: `Growing out of a historic workshop sponsored by IBM...[this book] is the first... devoted entirely to scenarios; it discusses many scenario-based approaches and demonstrates their practical applications... [It] translates the latest findings into techniques that readers can immediately use to enhance the effectiveness of UI design...' "

Once the project manager left, Bob scanned the table of contents. The contributors were diverse in their perspectives on systems development: from participatory design to usability engineering to object oriented (OO) development. The book consisted of 15 chapters, including an overview and two concluding discussion chapters. Bob selected four chapters as "required reading" for practitioners whom, like himself, want to get their hands dirty using scenario-based techniques. The remaining chapters looked interesting, but they did not address practitioners' immediate goals; they were too specialized, not focused on scenarios, or not practical enough.

Chapter 3 proved to be a good place to start for an overview. J.Nielsen presents seven ways scenarios can be used at various points in the development cycle. He covers each usage in a case study (generally avoiding superfluous detail, unlike some other contributors). Tips, trade-offs, and lessons learned pepper each case study. The sample scenarios provide clear examples to work from; however, they tend to disappear as the chapter progressed.

Chapter 10 was a good next step with its more conceptual, but still practitioner-oriented, approach. Points well covered here include: elaborating scenarios over the course of a project, using an analytic approach to discover scenarios, reasoning about scenarios using claims analysis, and updating scenario documentation over the course of a project. However, the middle section of this chapter will appeal to a more narrow audience; it describes the "Scenario Browser" tool and the innovative, though debatable, approach of interleaving object modeling/implementation with scenario analysis.

Feeling that he had the basics covered, Bob turned next to chapter 11 for a bit of an "advanced course." Chapter 11 demonstrates how to exploit an existing set of scenarios for additional information using the "systematic question asking" technique adapted from natural language comprehension research. Bob was surprised to learn how much the interpretation of scenarios depends on the knowledge that designers carry around in their heads. Despite this and other interesting points, Bob concluded that the level of rigor called for seemed cost-justifiable only in limited cases.

Chapter 15 completes the selection of chapters considered "required reading" by casting a critical eye on the techniques presented in the book. This contributor covers the issue of data collection particularly well (i.e., the effort required by various techniques, challenges in collecting a representative set of scenarios) and clarifies what does, and does not, qualify as a "scenario."

The remaining chapters are more suitable for readers who want to dig deeper. Some chapters will suit readers interested in reflections by leading authorities about scenarios (see chapters 1, 2, 14, and the Introduction). Other chapters have their merits but don't give scenarios top billing; they generally serve as a platform for the author's area of research with scenarios sometimes peripherally addressed. These chapters are: chapter 4 (case study on Scandinavian "cooperative design"), chapter 5 (case history of a project on speech recognition), chapter 6 (CARD and PICTIVE techniques in participatory design), chapter 7 (ways to represent past design insights to educate HCI practitioners), chapter 8 (the DSA/QOC approach to design rationale), chapter 9 (the TKS approach and ADEPT tools for a task-based approach to system design), chapter 12 (use cases and interaction diagrams), and chapter 13 ("conversations", CRC cards, object stereotyping).

After finishing the book, Bob was still unsure about how a scenario technique would fit into the object-oriented methodology being used in the STARDRECK project. He knew that scenarios were conceptually related to "use cases" from reading about Jacobsen's OO methodology but he was unclear about the relation. To his dismay, the book was silent on this issue. Jacobsen's chapter (chapter 13) on use cases had this to say, "scenarios normally mean[s] use-case instances" (p. 316). However, Jacobsen did not address the book's other perspectives on scenario techniques; his chapter seemed "cut and pasted" from a standard text on OO design rather than geared to this book. For their part, none of the contributors addressed this marginal role to which Jacobsen relegates scenarios although their contributions illustrate alternative roles of scenarios in systems design.

Cheryl came by and said, "What did you think of the book?" Bob answered, "It provided practical tips and a conceptual foundation for using scenario techniques. However, I had to read selectively to find the so-called "techniques that readers can immediately use" referred to on the book's cover. Even after reading this book, I have a lot of work ahead to flesh out a technique to fit our project's requirements. Can you give me a couple of extra days to work on this?"

Scenario-Based Design: Envisioning Work and Technology in System Development, Ed. John Carroll, John Wiley, 1995, ISBN: 0-471-07659-7

Paul McInerney is a Human Factors Designer at Atomic Energy of Canada in Toronto. He has a graduate degree in human factors and has used scenario-based techniques. Paul can be reached at mcinernp@candu.aecl.ca.

Issue
Article
Vol.28 No.4, October 1996
Article
Issue