Five Reasons for Scenario-Based Design - Testing Education

1 Copyright 1999 IEEE. Reprinted from IEEE Proceedings of the 32nd Hawaii International Conference on System Sciences, Five Reasons for Scenario-Based Design , John M. Carroll. This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any of the Center for Software Testing Education and Research's (CSTER's) products or services. Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by writing to choosing to view this document, you agree to all provisions of the copyright laws protecting it. Five Reasons for Scenario-Based DesignJohn M. CarrollDepartment of Computer Science andCenter for Human-Computer InteractionVirginia TechBlacksburg, VA 24061-0106 Tel: 1-540-231-8453E-mail: of human-computer interaction help us tounderstand and to create computer systems andapplications as artifacts of human activity as things tolearn from, as tools to use in one's work, as media forinteracting with other people.

2 Scenario-Based Design ofinformation technology addresses five technicalchallenges: Scenarios evoke reflection in the content ofdesign work, helping developers coordinate Design actionand reflection. Scenarios are at once concrete and flexible,helping developers manage the fluidy of Design afford multiple views of an interaction, diversekinds and amounts of detailing, helping developersmanage the many consequences entailed by any givendesign move. Scenarios can also be abstracted andcategorized, helping designers to recognize, capture, andreuse generalizations, and to address the challenge thattechnical knowledge often lags the needs of technicaldesign. Finally, scenarios promote work-orientedcommunication among stakeholders, helping to makedesign activities more accessible to the great variety ofexpertise that can contribute to Design , and addressing thechallenge that external constraints designers and clientsoften distract attention from the needs and concerns of thepeople who will use the IntroductionDesigners of information systems and applications facea disturbing reality.

3 While there is plenty of opportunityto do things that make a difference, it is never unequivocaljust what should be done, or even just what the realproblems are. The problems can only be definitivelyanalyzed by being solved; the appropriate solutionmethods must typically be executed in order to beidentified; the solutions must be implemented in order tobe specified. All the while, the designer faces convolutednetworks of tradeoff and interdependency, the potential ofuntoward impacts on people and their social institutions,and the likelihood that changing cultural and technologicalcircumstances will obviate any solution before it can software engineering methods belong to amethodological tradition that seeks to control thecomplexity and fluidity of Design through techniques thatfilter the information considered and decompose theproblems to be solved.

4 A complementary tradition seeksto exploit the complexity and fluidity of Design by tryingto learn more about the structure and dynamics of theproblem domain, by trying to see the situation in manydifferent ways, and by interacting intimately with theconcrete elements of the situation [1,2,11,28]. Scenario-Based Design techniques belong to thiscomplementary approach. In Scenario-Based Design ,descriptions of how people accomplish tasks are a primaryworking Design representation. Software Design isfundamentally about envisioning and facilitating newways of doing things and new things to do. Maintaininga continuous focus on situations of and consequences forhuman work and activity promotes learning about thestructure and dynamics of problem domains, seeing usagesituations from different perspectives, and managingtradeoffs to reach usable and effective Design outcomes[5,6].

5 2. What are scenarios?Computers are more than just functionality. Theyunavoidably restructure human activities, creating newpossibilities as well as new difficulties. Conversely, eachcontext in which humans experience and act providesdetailed constraint for the development and application ofcomputer technologies. In analyzing and designingsystems and software we need better means to talk abouthow they may transform and/or be constrained by thecontexts of user activity: this is the only way we can hopeto attain control over the materials of Design . A directapproach is to explicitly envision and document typicalProceedings of the 32nd Hawaii International Conference on System Sciences - 19990-7695-0001-3/99 $ (c) 1999 IEEEP roceedings of the 32nd Hawaii International Conference on System Sciences - 19991and significant user activities early and continuingly in thedevelopment process. Such descriptions, often called scenarios, support reasoning about situations of use,even before those situations are actually are stories.

6 They are stories about peopleand their activities. For example, an accountant wishes toopen a folder on the system desktop in order to access amemo on budgets. However, the folder is covered up by abudget spreadsheet that the accountant wishes to refer towhile reading the memo. The spreadsheet is so large thatit nearly fills the display. The accountant pauses forseveral seconds, resizes the spreadsheet, moves it partiallyout of the display, opens the folder, opens the memo,resizes and repositions the memo, and continues is about as mundane a work scenario as one couldimagine. Yet even this scenario specifies windowmanagement and application switching functionalityvividly and pointedly: People need to coordinateinformation sources, to compare, copy, and integrate datafrom multiple applications; displays inevitably getcluttered; people need to find and rearrange windows in thedisplay.

7 Scenarios highlight goals suggested by theappearance and behavior of the system, what people try todo with the system, what procedures are adopted, notadopted, carried out successfully or erroneously, and whatinterpretations people make of what happens to them. Ifthe accountant scenario is typical of what people want todo, it substantively constrains Design approaches towindow management and have characteristic elements [26]. Theyinclude or presuppose a setting: The accountant scenarioexplicitly describes a starting state for the describedepisode; the relative positions of the folder andspreadsheet, and the presence of the accountant. Thescenario implies further setting elements by identifyingthe person as an accountant, and the work objects asbudgets and also include agents or actors: The accountantis the only agent in this example, but it is typical ofhuman activities to include several to many agents.

8 Eachagent or actor typically has goals or objectives. These arechanges that the agent wishes to achieve in thecircumstances of the setting. Every scenario involves atleast one agent and at least one goal. When more thanone agent or goal is involved, they may be differentiallyprominent in the scenario. Often one goal is the defininggoal of a scenario, the answer to the question why didthis story happen? Similarly, one agent might be theprincipal actor, the answer to the question who is thisstory about? In the accountant scenario, the defining goal isdisplaying the memo in such a way that both the memoand budget can be examined. A subgoal is opening thefolder in which the memo is located, and a further subgoalis moving the budget to allow the folder to be have a plot; they include sequences of actionsand events, things that actors do, things that happen tothem, changes in the circumstances of the setting, and soforth.

9 Particular actions and events can facilitate,obstruct, or be irrelevant to given goals. Resizing thespreadsheet and moving it out of the display are actionsthat facilitate the goal of opening the folder. Resizing andrepositioning the memo are actions that facilitate the goalof displaying the memo so that it can be examined withthe budget. Pausing is an action that is irrelevant to anygoal, though it suggests that the accountants goal-orientedactions were not completely fluent. Notably, actions andevents can often change the goals even the defininggoal of a the use of a system or application with aset of user interaction scenarios makes that use explicit,and in doing so orients Design and analysis toward abroader view of computers. It can help designers andanalysts to focus attention on the assumptions aboutpeople and their tasks that are implicit in systems andapplications.

10 Scenario representations can be elaborated asprototypes, through the use of storyboard, video, and rapidprototyping tools. They are the minimal contexts fordeveloping user-oriented Design rationale: a given designdecision can be evaluated and documented in terms of itsspecific consequences within particular and the elements of Scenario-Based designrationale can be generalized and abstracted using theoriesof human activity, enabling the cumulation anddevelopment of knowledge attained in the course ofdesign. Thus, scenarios can provide a framework for adesign-based science of human-computer the balance of this chapter, we review five of keychallenges for Design methods and illustrate for each thecorresponding response of Scenario-Based Challenge: Design action competeswith reflectionTechnical professionals are intelligent peopleperforming complex and open-ended tasks.