Our minds use stored narratives of past events whenever we plan and predict future events. The psychologist Roger Shank (1990, 1977) and others (Johnson-Laird, 1983; Michalski, 1989) have proposed that the core of intelligence is accessing specific, relevant past experiences in order to make sense of new situations. Our minds index millions of remembered episodes which it can then access and apply in an enormous range of new contexts For example, a particular episode in which we make plane reservations over the phone might later be used in a number of different contexts where we need to get information from a person who is in a hurry or where we need to choose among sub-optimal alternatives, etc. The richness of the mental indexing is an important determinant of the effectiveness of later prediction and understanding. Shank has argued that human intelligence uses concrete 'cases' rather than abstract 'rules' to access memory. Concrete cases are richer in information than abstract rules and can be applied to a wider range of new circumstances.

Our minds access and draw on past events without effort; often we are not even aware of what specific experiences we are drawing on when we apply learning from one situation to another. In informal conversation, we do collectively something analogous to what our minds do internally: Someone relates an incident, and we are reminded of another incident that we either experienced or heard about, and we relate that. The conversation goes on from there. In organizations, people swap stories about past events related to current ones, such as other mergers, previous downsizings, previous system upgrades, etc. Discussions are exercises in collective sense-making. Members of an organization use specific events to develop and refine understanding of the organizational environment.

Paradoxically, even though the internal working of our minds (and our informal conversations) make rich use of specific cases, our conscious problem-solving tends to summarize, abstract, and gloss over particulars. Though our minds internally store and access richly encoded memories and then use those to predict and make sense of new situations, our conscious problem-solving is often impoverished in the detail that it utilizes. (It may be the very richness of our memory that makes it difficult to utilize well in problem-solving) In problem solving, humans tend to give relatively little attention to actually identifying and formulating the problem. (Miller & Thomas, 1977; Rips, 1988).

This paradox creates a difficulty in designing technology: In setting goals for new technologies, we tend to leave out parts of the problem we are trying to solve. For example, generating requirements for new technology is a notoriously difficult task, and requirements generated often do not adequately capture the need. Several recent approaches to planning new technologies attempt to get around this difficulty by eliciting rich information about the current problems and needs before attempting to imagine solutions. These approaches include contextual inquiry (Beyer & Holtzblatt, 1998; Holtzblatt & Jones, 1995), development of use cases (Jacobson, 1995), design-by-anecdote (Orr & Crowfoot, 1992), and ethnographic research (Suchman, 1987). All use actual events in the workplace to identify and formulate the problems to be solved by new technologies.

One effective approach for utilizing specific events as input for identifying and framing problems is to observe the actual context of use -- the workplace or other environment where a need occurs (Beyer & Holtzblatt, 1998; Holtzblatt & Jones, 1995; Suchman, 1987). Researches go into the environment and observe and interview people operating in it. A lower cost approach is to collect retrospective accounts of actual events that involved a significant problem, need, or impasse.

Collecting anecdotes about such events is a powerful way to capture significant problems. The rich knowledge provided by reconstructing real events is especially important for defining new kinds of systems rather than simply improving existing systems (Beyer & Holtzblatt, 1998). Reconstructing specific events in detail provides good input for problem formulation. Such reconstructions include several different kinds of information that are essential for problem formulation:

• Goals-- who is trying to what.
• Context -- physical and organizational settings, time constraints, what happened before and after, etc.
• Detail -- much of which might be treated as irrelevant in a more abstract approach to problem solving.

• Recall of the details of actual events can enrich planning discussions about new technologies.
• The anecdotes can be distributed among prospective users of a new technology, to serve as 'seed stories' to spark recollection of other, related events. A collection of anecdotes could be generated in this way, which collectively would capture more dimensions of a need than any single anecdote would.
• The anecdotes can be distributed among researchers working on new technologies to prompt new approaches.

Beyer, H. and Holtzblatt, K., 1998. Contextual Design. Morgan-Kaufman Publishers: San Francisco, CA.

Jacobson, 1995. The use-case construct in object-oriented software engineering. In J. Carroll (Ed.) Scenario-based design: Envisioning work and technology in system development , 309-360.

Johnson-Laird, P., 1983. Mental Models. Harvard University Press: Cambridge.

Michalski, R. S. (1989). Two-tiered concept meaning, inferential matching and conceptual cohesiveness. In S. Vosniadou & A. Ortony, (Eds.), Similarity and analogical reasoning (pp. 122-145). New York: Cambridge University Press.

Orr and Crowfoot, 1992. Design by anecdote--The use of ethnography to guide the application of technology to practice. PDC '92: Proceedings of the Participatory Design Conference, 31-37.

Rips, L., 1988. Deduction, In R. J. Sternberg & E.E. Smith, (Eds.) The psychology of human thought (pp. 116-154). Cambridge University Press: New York.

Schank, R., 1990. Tell Me a Story: Narrative and Intelligence. Northwestern University Press: Evanson, Ill.

Schank, R., 1977. Scripts, Plans, Goals and Understanding. Lawrence Erlbaum & Assoc.: Hillsdale, NJ.

Suchman, L., 1987. Plans and situated actions: The problem of human-machine communication. Cambridge University Press: New York.

We piloted an anecdote collection procedure with the visitors to IBM Research from a large state university. Here are some reflections on the process.

1. The idea of collecting anecdotes about specific events made sense to the customer. As computer scientists and library scientists, they were interested in research in general and also in specific issues related to narrative-based knowledge vs. abstract knowledge. (An analogous issue for them was case-based vs. rule-based reasoning.)
2. The visitors were willing to contribute anecdotes and seemed to enjoy it. That tendency may generalize to other customers, since most of us like for people to be interested in what we know and take it seriously.
3. Even though the visitors seemed to understand the rationale, they were more inclined to produce general, recurring scenarios than specific episodes. Sometimes additional probing elicited specific episodes, but the university researchers seemed somewhat reluctant to supply them. I think there was actually good reason for their reluctance, which is relevant for designing effective anecdote collection. At the time we collected the anecdotes, there had not yet been much discussion between the university and IBM about the problems the university wanted to address. For initial communication about needs, scenarios made more sense in terms of both (a) the dialogue structure of the two-day meeting, and (b) the type of dialogue that is natural between researchers who share a similar expertise.
   1. Scenarios made sense in terms of the dialogue structure of the visit. The university researchers gave talks about their work in the morning and early afternoon of the first day of the meeting. In most cases, the relevant IBM researchers were not yet present. Some IBM researchers came in for some of the customer talks, but they usually arrived after introductions had been made, and there was not much discussion between the university visitors and IBM researchers at that point. IBM researchers then gave their talks, several of which were about hardware, software, and analytic work that was relevant to the university's immediate needs. In most cases, the IBM researcher would leave after their talk. From the IBM talks, the visitors identified various IBM work and/or products that was relevant to their own needs and then proposed to follow up with the relevant IBM researchers. The visitors had the role of identifying what they needed from IBM. Given that situation, it would make dialogic sense for them to state their problem in general terms. The dialogue was not: 'Here's my situation, can you see what's needed?' It was rather: 'I heard what you have, and such-and-such would be relevant to me for such-an-such reasons.' So stating problems as generic scenarios was more in keeping with the overall dialogue of the meeting.
   2. Computer scientists at IBM were a prime audience for the anecdotes, and the computer scientists from the visiting university found it more natural to relate problems to other computer scientists via scenarios than via specific episodes. The visitors had already diagnosed their needs and problems to some level, and it was at that level that they would naturally first communicate to other researchers at IBM. It would seem odd to communicate on the level of 'what happened on day x' before they had had a chance to discuss their needs in more in general terms. It might make sense however to get into specific episodes at a later time, but they felt awkward in doing so at that time.
4. Collection of specific episodes (as opposed to scenarios) in the context of a customer visit may be more advantageous for customers who are less knowledgeable about IBM technologies. For less technical customers, anecdotes about specific episodes could help to clarify their needs.
5. We told each respondent that they would receive a copy of their transcript for their approval and that they would determine who else should see it (the potential audiences being other users/researchers at the university and researchers at IBM.). Most found it important to have control over their transcripts.
6. We collected the anecdotes during times scheduled for informal socializing and demos, allowing about 15-20 minutes per person. Respondents felt some conflict in missing the other activities. Also, the 15-20 minute sessions were somewhat rushed. It took several minutes of warm-up before respondents got into details; 30-40 minutes would have been better. A partial solution might be to conduct two sessions at the same time.