Five reasons for scenario-based design

Abstract Scenarios of human–computer interaction help us to understand and to create computer systems and applications as artifacts of human activity—as things to learn from, as tools to use in one's work, as media for interacting with other people. Scenario-based design of information technology addresses five technical challenges: scenarios evoke reflection in the content of design work, helping developers coordinate design action and reflection. Scenarios are at once concrete and flexible, helping developers manage the fluidity of design situations. Scenarios afford multiple views of an interaction, diverse kinds and amounts of detailing, helping developers manage the many consequences entailed by any given design move. Scenarios can also be abstracted and categorized, helping designers to recognize, capture and reuse generalizations and to address the challenge that technical knowledge often lags the needs of technical design. Finally, scenarios promote work-oriented communication among stakeholders, helping to make design activities more accessible to the great variety of expertise that can contribute to design, and addressing the challenge that external constraints designers and clients face often distract attention from the needs and concerns of the people who will use the technology.

[1]  Effy Oz,et al.  When professional standards are lax: the CONFIRM failure and its lessons , 1994, CACM.

[2]  Michael J. Muller,et al.  Bifocal tools for scenarios and representations in participatory activities with users , 1995 .

[3]  M. Scriven,et al.  Perspectives of curriculum evaluation , 1968 .

[4]  D. Schoen,et al.  The Reflective Practitioner: How Professionals Think in Action , 1985 .

[5]  C. Hutchins,et al.  The Acoustics of Violin Plates , 1981 .

[6]  D. Schoen.  Educating the reflective practitioner , 1987 .

[7]  Fred P. Brooks,et al.  The Mythical Man-Month , 1975, Reliable Software.

[8]  Frederick P. Brooks,et al.  The Mythical Man-Month: Essays on Softw , 1978 .

[9]  Colin Potts,et al.  Using schematic scenarios to understand user needs , 1995, Symposium on Designing Interactive Systems.

[10]  Mary Beth Rosson,et al.  Making argumentation serve design , 1991 .

[11]  C. Churchman.  Operations Research as a Profession , 1970 .

[12]  M. Scriven.  The methodology of evaluation , 1966 .

[13]  J. Nunamaker,et al.  Proceedings of the 32nd Hawaii International Conference on System Sciences , 1999 .

[14]  Donald A. Sch.  The reflective practitioner: how professionals think in action , 1983 .

[15]  Timothy D. Wilson,et al.  Telling more than we can know: Verbal reports on mental processes. , 1977 .

[16]  Mary Beth Rosson,et al.  Usability Specifications as Tool in Iterative Development. , 1984 .

[17]  Morten Kyng,et al.  Creating contexts for design , 1995 .

[18]  L. Lunsky.  Identity and the Life Cycle. , 1966 .

[19]  L. Festinger,et al.  A Theory of Cognitive Dissonance , 2017 .

[20]  Karen A. Schriver.  Dynamics in document design , 1998 .

[21]  Peter Checkland,et al.  Systems Thinking, Systems Practice , 1981 .

[22]  Rebecca Wirfs-Brock,et al.  Designing objects and their interactions: a brief look at responsibility-driven design , 1995 .

[23]  John M. Carroll,et al.  Making use: a design representation , 1994, CACM.

[24]  S. Duval,et al.  A theory of objective self awareness , 1972 .

[25]  T.M. Duffy,et al.  Scenario-Based Design: Envisioning Work and Technology in System Development [Book Review] , 1996, IEEE Transactions on Professional Communication.

[26]  Ivar Jacobson,et al.  The use-case construct in object-oriented software engineering , 1995 .

[27]  Leslie J. Briggs,et al.  Principles of Instructional Design , 1974 .

[28]  M. Mcluhan.  Understanding Media: The Extensions of Man , 1964 .

[29]  Mary Beth Rosson,et al.  Human-computer interaction scenarios as a design representation , 1990, Twenty-Third Annual Hawaii International Conference on System Sciences.

[30]  Russell L. Ackoff,et al.  Resurrecting the Future of Operational Research , 1979 .

[31]  Roy Rada,et al.  Interacting WITH Computers , 1989, Interact. Comput..

[32]  Mary Beth Rosson,et al.  Getting around the task-artifact cycle: how to make claims and design by scenario , 1992, TOIS.

[33]  John Millar Carroll.  The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill , 1990 .

[34]  John Karat,et al.  Using scenarios in design meetings—a case study example , 1991 .

[35]  L. Festinger,et al.  When Prophecy Fails , 1956 .

[36]  R. Ackoff.  The Future of Operational Research is Past , 1979 .

[37]  Donald A. Schön,et al.  Technology and Change; the New Heraclitus , 1967 .

[38]  Mary Beth Rosson,et al.  Deliberated Evolution: Stalking the View Matcher in Design Space , 1996, Hum. Comput. Interact..

[39]  Mary Beth Rosson,et al.  Participatory analysis: shared development of requirements from scenarios , 1997, CHI.