John M. Carroll
MIT Press, September 2000
ISBN 0262032791 (boards)
Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
Jack Carroll (with his partner and co-worker Mary Beth Rosson) is widely respected as a champion of scenarios in all their myriad forms. His book Scenario-Based Design is unfortunately out of print, but Making Use, although ostensibly about HCI is in fact much broader than that: firstly because if you talk about what people can do with and through a user interface, you are implicitly defining the underlying system behaviour -- that's what scenarios do!; and secondly because "scenarios identified or created for one purpose can be recruited to other purposes" (p 289). In other words, scenarios are inherently powerful things and have many uses. They achieve this by being "deliberately incomplete"; hence, they are suggestive, as all stories are (see Roger Schank's Tell Me A Story for a wonderful account of this). Indeed, a formative remark made to Carroll was that good research scientists at IBM had "tolerance for ambiguity" (p 315).
From this very brief introduction, it should at once be clear that Carroll is of the short-and-sweet school of scenario composition. At the other end of the scale are use case gurus like Alistair Cockburn, who advocate a range of use case templates from fairly sketchy through to 'fully-dressed'. Developers interested in Testing such as Naresh Ahlowalia (see Sticky Minds) go even further and argue for a direct mapping from use case scenarios (paths) to test cases: that route would lead to fully analytic use cases as precise (and as subject to error) as code. There is plainly much room for controversy here, but on the whole Carroll chooses to focus on how to exploit quite vague scenarios, supplementing them with details of the claims they make, both positive and negative.
Among the roles of scenarios in system development, Carroll identifies functional and usability specification, design rationale, system vision, documentation help and training, User Interface metaphor, prototyping, object modelling and formative evaluation (towards project goals). Interestingly he doesn't include thinking out exception scenarios, security threats or other negative scenarios or 'misuse cases', even though he does mention the apocalyptic accidental world-war-three scenario discussed by Herman Kahn (Thinking About The Unthinkable, Horizon) in the cold war year of 1962.
Carroll laments that "the world no longer waits for research to lead practice. Some [of] the most important work on scenario-based design can be found in the reflections and suggestions of consultants...", mentioning Jacobson, McGraw & Harbison and Beyer & Holtzblatt among others. He goes on: "These books are strong on suggestions about techniques, but weaker on presenting evidence about how the techniques work. The area is developing so rapidly that these most recent practitioner-oriented discussions appear to have been developed independently of one another and of research-oriented work..."
As you might expect, therefore, Carroll is very careful to document both the evidence for his claims, and the contributions of other practitioners over the past 5 decades. For in a sense, scenarios are not new at all -- story-telling is as old as humanity, as is the discussion of risky scenarios. There has long been a tension between theoreticians like Herbert Simon and Christopher Alexander who have advocated a 'hard' top-down approach, identifying a hierarchy of design elements, and practitioners like Henry Dreyfuss (Designing for People, Simon & Schuster 1955), who have taken care to find out how people actually used things, and designed according to the scenarios they discovered. Interestingly, reports Carroll, both Alexander and Dreyfuss wrote about the design of vacuum cleaners, but whereas Alexander came up with just a few high-level principles like simplicity, easy assembly, high cleaning power and low cost, Dreyfuss discovered real needs for ergonomic handles and controls, a headlight to shine under furniture and a low profile to reach there, a rubber bumper, a kink-resistant cord and numerous other practical features -- as those were what people actually needed in Dreyfuss' case studies. In contrast, "Simon and Alexander wrote as design theorists and referred exclusively to contrived and highly schematic examples." (p 35)
This book is therefore full of details about things that worked and things that went wrong on real projects, and very interesting it is; for an academic monograph it's actually not especially theory-laden (in contrast, say, to Sutcliffe's Domain Theory which also presents research done with Carroll on claims).
A colleague was irritated by the style of the book, which does indeed venture some purple passages: Chapter 1 is entitled 'The Sorcerer's Apprentice' and talks about the black magic of software (though the sorcery metaphor is from Fred Brooks' Mythical Man-Month, a book that Carroll discusses later (p37ff)). Mind you, a chapter that mentions "the cloying helpfulness of Microsoft's Bob" can't be all bad. For my part, I don't really see why thinking out requirements and evaluating scenarios against goals should be called 'scenario-based design' but it is an established if curious usage in some areas.
This book is at once readable and scholarly, reflective and practical, and it is based on unparalleled experience in a lifetime of research. It's well worth dipping into.
(c) Ian Alexander, 2003