In [Campbell92], Campbell observes a variety of different usages of the
term "scenario". He identifies four types of usage and coins terms to
disambiguate usage and intent: demonstration examples (description),
evaluation tasks (evaluation), user tasks for design (design), and test
cases (theory testing).
Webster's 7th New Collegiate Dictionary defines "scenario" as "1a: an
outline or synopsis of a play; esp: a plot outline used by actors of
the commedia dell'arte, b: the book of an opera, 2a: SCREENPLAY, b:
SHOOTING SCRIPT". ((1)) This classical, common English usage focuses
on scenario as a list or guideline of events which orders a set of
actions. All of Campbell's usages, save perhaps "test cases", fit this
pattern. I prefer to focus not on script or stage direction, but on
the elements of plot and intent, which are not always made explicit.
In [Reisner86a] I presented two usages of the term "scenario": as a
technique for describing how to accomplish a task or activity using a
given system, similar to Campbell's "demonstration examples", and as a
technique in system design, similar to Campbell's "user tasks for
As "demonstration examples", the intent is to supply the user with an
appropriate model for system usage - how to use the system naturally to
accomplish a task. For Unix, such a "scenario" might develop the ideas
of shell scripts and filters, thru examples of common high-level
As "user tasks for design", I used "scenarios" to describe a user task
domain, attempting to identify approachs the user would naturally
adopt, and then developing a system or set of tools which would be
consonant the user's desires and expectations. For example, one might
describe a user's thought process in the course of developing a
program, and then describe a style of programming environment which
would support that process. ((2))
Both usages focus almost completely on the user's internal model of the
system. Specific command usage and behaviour only shows up
incidentally. The "scenarios" are not substitutes for traditional
tutorials and usage or design documentation. Rather, they provide the
higher-level context in which those other documents become useful and
meaningful. (The utility of this type of "demonstration example"
scenario could be tested fairly easily by the use of different
documentation sets in introducing novice and experienced users to a new
system, as outlined in [Reisner86a].)
With this emphasis, "user paradigms" might be a better term than
"demonstration examples" (if somewhat overused). "User tasks for
design" is somewhat cumbersome, and does seems to focus on very
specific actions rather than on process and motivation; I would be
tempted to retain "scenario", perhaps paired with "problem", "domain",
or "design". "Test cases" does not emphasize the hypothesis and theory
testing nature of the usage - alternatives? "Evaluation tasks" seems
direct and to the point.
Scenarios, in their various usages, clearly provide useful methods for
thinking about and describing systems, theories, and user models. A
taxonomy may be useful in retaining focus and clarifying purpose of
usage in different contexts.
((1)) It would be interesting to compare this to a more recent or
slang dictionary definition.
((2)) [Reisner86b] illustrates this in a rudimentary fashion.
[Reisner86c] describes a somewhat more successful "design by
scenario", though the scenario is not explicitly stated.
[Campbell92] Campbell, R.L. (1992). Will the Real Scenario Please
Stand Up? SIGCHI Bulletin, 24(2), 6-8.
[Reisner86a] Reisner, D.A. (1986a). The Use of Scenarios in
Programming System Documentation and Design. Internal whitepaper,
[Reisner86b] Reisner, D.A. (1986b). Basic Tools for Ada Program
Development. Internal whitepaper, TeleSoft.
[Reisner86c] Reisner, D.A. (1986c). A Graphics Oriented Interface
for Ada Program Development. Unpublished, David Reisner Consulting.
Contact: David Reisner, Synthesis, dar at synthesis.com