See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/242548532

Error as Opportunity: Learning in a Cooperative Task

Article  in  Human-Computer Interaction · December 1992

DOI: 10.1207/s15327051hci0704_3

CITATIONS READS

86 80

2 authors, including:

Colleen M. Seifert
University of Michigan
130 PUBLICATIONS   4,506 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Tackling the 'right' problem: Investigating cognitive strategies used in understanding engineering problems View project

Evidence-based pedagogy in engineering education: Design Heuristics for concept generation View project

All content following this page was uploaded by Colleen M. Seifert on 16 October 2014.

The user has requested enhancement of the downloaded file.

This article was downloaded by: [University of Michigan]
On: 19 February 2009
Access details: Access Details: [subscription number 907137605]
Publisher Taylor & Francis
Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered office: Mortimer House,
37-41 Mortimer Street, London W1T 3JH, UK

Human-Computer Interaction
Publication details, including instructions for authors and subscription information:
http://www.informaworld.com/smpp/title~content=t775653648

Error as Opportunity: Learning in a Cooperative Task

Colleen M. Seifert a; Edwin L. Hutchins b
a
University of Michigan. b University of California, San Diego.

Online Publication Date: 01 February 1992

To cite this Article Seifert, Colleen M. and Hutchins, Edwin L.(1992)'Error as Opportunity: Learning in a Cooperative Task',Human-
Computer Interaction,7:4,409 — 435
To link to this Article: DOI: 10.1207/s15327051hci0704_3
URL: http://dx.doi.org/10.1207/s15327051hci0704_3

PLEASE SCROLL DOWN FOR ARTICLE

Full terms and conditions of use: http://www.informaworld.com/terms-and-conditions-of-access.pdf

This article may be used for research, teaching and private study purposes. Any substantial or
systematic reproduction, re-distribution, re-selling, loan or sub-licensing, systematic supply or
distribution in any form to anyone is expressly forbidden.

The publisher does not give any warranty express or implied or make any representation that the contents
will be complete or accurate or up to date. The accuracy of any instructions, formulae and drug doses
should be independently verified with primary sources. The publisher shall not be liable for any loss,
actions, claims, proceedings, demand or costs or damages whatsoever or howsoever caused arising directly
or indirectly in connection with or arising out of the use of this material.
 HUMAN-COMPUTER INTERACTION, 1992, Volume 7, pp. 409-435
Copyright 0 1992, Lawrence Erlbaum Associates, Inc.

Error as Opportunity: Learning in a

Cooperative Task
Colleen M. Seifert
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

University of Michifan
Edwin L. Hutchins
University of California, San Diego

ABSTRACT

In this article, we examine learning within a cooperative system. We focus

on the role of learning from errors in a context where regular attrition of
group members occurs. Specifically, the study involved observation of
distributed activity in the team navigation of a large naval vessel. Analyses
revealed frequent individual errors; however, successful detection and cor-
rection of errors also occurred. Thus, the cooperative system simultaneously
allowed high component error and ensured low system output error. This
robustness is an especially valuable feature for distributed systems because it
provides for needed on-the-job learning while maintaining a high level of
overall performance. Errors were observed to function as opportunities for
instruction based on a novice's demonstrated "need to know." The distributed
system was found to contain certain design tradeoffs that are exploited for
their utility in learning (viz., distributing knowledge across the team and
providing multiple perspectives for error detection). The results are applicable
to the design of computer-supported cooperative tasks and provide guidelines
for task organization that facilitates performance while incorporating the
ability to learn from errors.

Authors'present addresses: Colleen M . Seifert, Department of Psychology, University

of Michigan, 330 Packard Road, Ann Arbor, MI 48104; Edwin L. Hutchins,
Department of Cognitive Science, University of California, San Diego, San Diego,
CA 92093.
 410 SEIFERT AND HUTCHINS

CONTENTS
1. INTRODUCTION
2. NAVIGATION DOMAIN
2.1. Task Description
2.2. Physical Setting
2.3. Computational Tasks
2.4. Training and Instruction
3. DATA COLLECTION
4. SITUATED LEARNING
5. LEARNING FBOM ERROR
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

5.1. Error Frequency

5.2. Novice Errors
5.3. Error-Based Instruction
5.4. Error Feedback
6. NATURE OF THE DISTRIBUTED TASK
6.1. Cognitive Task Analysis
6.2. Shared Task Knowledge
6.3. Horizon of Observation
6.4. Multiple Perpctives
6.5. Social and Motivational Factors
7. DESIGNING FOR LEARNING
8. CONCLUSION

1. INTRODUCTION

Learning is a critical issue for systems that support cooperative work. Such
a system must produce the intended output and at the same time reproduce
itself. In particular, change will occur among the human participants in a
distributed system over time, as relatively expert personnel are replaced by
more novice participants. Another constraint on cooperative systems is that
they may require training within the context of the situated activity
(Suchman, 1987). Some of the skills may be learned through instruction;
however, the interactions characteristic of cooperative work can generally
only be learned within the functioning distributed system. Because simulating
an interactive work setting may not be possible or cost effective, there will
always be new participants who are experiencing the demands of the
distributed task setting as novices.
Thus, in cooperative tasks, learning on the job is inevitable, and where
there is learning, there is potential for error. Most studies of error focus on its
reduction or elimination; however, errors will occur in the distributed task
setting due to the need for on-the-job training. Can learning (with its
consequent error) be combined successfully with overall accurate perfor-
mance in cooperative systems of work?
 E R R O R AS OPPORTUNITY 411

In this article, we present a case study of an existing situated task, the team
navigation of a U.S. Navy ship. This distributed task has developed under
several constraints: specifically, maintaining a working system in a state of
readiness, operating in adverse circumstances, and training replacements for
team members. These characteristics are shared by many real-world settings
of cooperative work, where task performance must carry on despite changes
in personnel, function, or technology (Rogoff & Lave, 1984).
In examining this successful task system, we focus on the role of learning
and error. How does the cooperative system foster learning while ensuring
that the overall results of the system are accurate? We begin by providing
information about the navigation domain and the specific tasks it involves,
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

along with the training procedures currently employed. Next, we describe the
observations and protocols collected. We then describe results pertaining to
the role of errors in training and system properties that enable on-the-job
learning. Finally, we propose design principles for robust cooperative systems
and support technology.

2. NAVIGATION DOMAIN

At all times when a naval vessel is underway, a graphical plot of its past and
projected movements is maintained. This information, gathered and pro-
cessed by the navigation team, supports the decisions of the officer who is
responsible for the ship's movements. Day and night, whenever a ship is
neither tied to a pier nor at anchor, navigation computations are performed.
The technologies currently available include instruments for celestial, radar,
satellite, and visual-bearing observation. Most of the time while at sea, the
work of navigation is performed by a single crew member, using a variety of
these methods; however, when a ship leaves or enters port, or operates in any
other environment where maneuverability is potentially restricted, visual-
bearing observation is performed by a team of crew members working
together in a distributed manner. Given extremely tight time constraints,
limited channel size for safe conduct, the large lag in ship response to steering,
and the high cost of accidents, the performance of the entire navigation team
is critical to the safe passage of the ship. In the next sections, we describe the
task requirements and performance characteristics of team navigation.

2.1. Task Description

The team navigation task is cooperative in the sense that the result of the
system performance cannot be attributed to any individual participant. The
navigation activity requires interaction between both human and technolog-
ical components such as task-specific tools and representational devices
 412 SEIFERT AND HUTCHINS

(Hutchins, 1986). The primary goal of accurate performance under adverse

conditions (i.e., battle, bad weather, power failure) contributes to a reluc-
tance to rely on technology. Thus, although the system does involve many
types of tools, the team navigation task is not currently computer supported.
Technological improvements to the current task distribution and computer
support for this task have been proposed (Halff, Hollan, & Hutchins, 1986;
Hutchins, 1989; Schwartz, Kullback, & Shrier, 1986); however, we examine
on-the-job learning within the current successful system.

2.2. Physical Setting

Downloaded By: [University of Michigan] At: 20:09 19 February 2009

The physical surroundings provide major constraints on any potential task

distribution. The ship observed, a Landing Platform Dock class vessel, has a
primary mission of delivering men1 and machines for amphibious landings.
Like most ships, the control and navigation occurs on a bridge platform
located three levels above the deck, with consequent limited visibility.
Figure 1 shows the navigation team members and their physical positioning
on the bridge. The members include the bearing takers, who operate sighting
devices outside the pilot house that measure the direction of landmarks from
the ship; the timer/recor&r, who records these bearings and provides commu-
nication with the takers; the plotter, who charts all information and computes
location; a deck log recorder, who records information about command history
(e.g., course decisions); a fathometer operator, who reports the depth of the water
under the ship for comparison to the navigational chart; and the evaluator, a
navigation offker who reports the results of the team operations to the
commanding officer on the bridge.
Most of the team is located within the pilot house and physically near the
chart table where the main computation takes place. Communication occurs
among these members both orally and through the recording of information
on the chart and in the two log books. However, two members of the team
(the bearing takers) are physically isolated outside of the pilot house, and their
view of each other is also obscured. The takers communicate to the rest of the
team through a telephone connection to the timerirecorder, who passes on
their information to the plotter both orally and by recording it in the
timertrecorder log. An additional party on the telephone line is the fathometer
operator, who reports information collected about water depth to the
timerlrecorder over the same phone circuit. The cooperation of all of these
participants is required for successful completion of the navigation task.

' The vessel observed was a combat ship on which female crew members cannot serve tours of
duty.
 ERROR AS OPPORTUNITY 413

Figure I . Map of the locations of navigation team members inside and outside
of the pilot house on the bridge.

t
EXlT
PILOT HOUSE

F M M CIRCUIT
-
EXlT
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

[ FATHoMETER 1

Observation ~ e c k1 I Observation Deck

2.3. Computational Tasks

There are two major computations involved in navigational theory. First,

to determine the current location of the ship, a procedure calledfixing position
is performed. Second, to determine where the ship will be after a given time
interval, a procedure called dead reckoning is used.
Fixing position involves computing location on a navigational chart by
finding the intersection of lines of position from available landmarks. A
navigational chart (shown in Figure 2) includes depth-of-channel information
indicating a shipping channel where passage of large ships can be accom-
plished safely. The chart provides a spatial analog to the physical world
surrounding the ship, so that the location posited on the chart can be
compared to the location in actual space. By comparing lines of position to
known objects in the physical environment, the location of the intersection of
directional lines is computed graphically on the chart, ''furing'' the current
position of the ship in space.
The sole method used in team navigation for position fixing is visual-
bearing observation. A visual line of sight on a landmark (whose charted
position is known) provides a one-dimensional constraint on the position from
which the landmark was observed. This line of sight, from the ship's
perspective, is the landmark's bearing (described by compass degrees). Given
the location of the landmark and the bearing of the landmark from the ship,
Downloaded By: [University of Michigan] At: 20:09 19 February 2

Figure 2. Navigational chart of a portion of San Diego Harbor. The small triangle drawn onto the chart locates the current
position of the ship within a margin of observation error. The track marked to the upper right is the dead reckoning of
projected position at later times.
 ERROR AS OPPORTUNITY 415

one can constrain the position of the observer to a line extending from the
landmark in the reciprocal direction of the bearing. Given two observations,
one can constrain the location of the ship uniquely by computing where the
two lines of position intersect. Typically, three lines of position are located
and plotted for each fix (determination of position); that way, a small triangle
representing the ship's likely position appears on the chart (see Figure 2). If
the observations are accurate, the size of the triangle, representing error,
should be small.
The second major computation, dead reckoning, involves computing where
the ship will be at a later time if it proceeds at a particular bearing and speed.
This is computed by drawing a tracking line on the chart from the current
known position and extending it in the direction of travel. Then, speed and
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

time interval are utilized to project the distance to be covered. This projection
is marked on the chart (see Figure 2) and compared to the position fix
computed at the next interval.
Thus, a continuous cycle of activity occurs in team navigation. After fixing
current position and dead reckoning for future position, preparations are
made to repeat the sequence. Because the time interval between fixes can be
less than 1 min while underway, performance pressures are considerable.
In discussing learning in this setting, we focus on the performance of the
most novice participants, the bearing takers. Taking bearings is the first job
assigned to novice team members and, therefore, is a likely site of on-the-job
learning. The following sequence describes the steps involved in taking
bearings as part of the repeated cycle of navigation activity.

Plotter chooses three landmarks, assigns them for the next fix.
Timerhecorder communicates landmark assignments to the takers.
Timerhecorder assigns time interval before next bearings needed.
Takers coordinate who will locate which landmarks.
Takers locate the landmarks in their field of view.
Timerhecorder issues a "stand-byn warning to the takers.
Timerhecorder issues a "mark" command to take the bearings.
Takers observe the landmark bearings.
Takers coordinate their series of three separate reports.
Takers report the bearings over phone line to timer/recorder.
Timerhecorder reports bearings verbally and records in log book.
Plotter uses the bearings to fix the position.
Plotter uses position, ship's direction, and speed to dead reckon.
Plotter uses future position to select next set of landmarks.

The bearing takers (located outside on each wing of the ship) listen for the
assignment of particular landmarks to find (after studying maps of landmarks
in target harbors in advance); upon hearing a timing signal from the
 416 SEIFERT AND HUTCHINS

Figure 3. Landmarks are sighted for the purpose of reading bearings for lines of
position. The figure shows the display overlaid on a landmark with the scale
indicating the bearing to be read.
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

timerlrecorder (the mark),they locate the landmark through a telescopic sight

on a gyrocompass repeater (a compass card that maintains true north
orientation in spite of ship movement). A compass card is superimposed on
the scene, from which the taker reads the bearing (called "shooting the
bearing"). Figure 3 shows a drawing of a landmark with the compass card
visible. Both takers are told the names of three landmarks for each fix, and
they each must decide which one or two he is responsible for (i.e., landmarks
in his line of sight). Upon hearing the command to shoot the bearings
("Mark"), they read and then report each bearing. In addition, because both
takers share the phone circuit, the announcement of reports over the phone
line must also be coordinated so that the timerlrecorder can accurately
monitor and record them.

2.4. Training and Instruction

Prior to assignment to a shipboard navigational crew, novice seamen attend

a 1-month basic training school (cf. Naval Technical Training Development
Unit, 1987). Although the fundamentals of navigation are covered (as in
Maloney, 1985), the course has little overlap with later performance aboard
ship. The equipment and procedures used in the school training are different,
and the focus is on required paper work. The school never provides any
practice in taking bearings, even though this is likely to be the first assignment
aboard ship.
There is currently no cost-effective way to simulate the team performance
under the time, space, and personnel conditions they will experience aboard
ship. Therefore, even after classroom training, novices still require much
on-the-job learning. The senior navigator aboard the ship stated that "90 % of
 ERROR AS OPPORTUNI?TY 417

my job is training." He begins the training period for novices by assigning

them as an apprentice in the bearing-taking role, then to taking bearings solo
during team performance. In addition, novice training takes place through
apprenticeship during watches at sea. Rather than formal training, learning
about the task takes place most significantly through learning while doing.
After about 1 year of shipboard training, members who stay on the team
gradually build the experience and expertise to advance to more challenging
positions within the team. Although they may spend several years in a
particular team navigation position, such longevity is unusual due to the
frequency with which crew members are rotated among vessels and complete
tours of duty. The improvement of performance with experience was attested
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

to by the navigation officer, who noted that the plotter had become the most
expert navigator solely through on-the-job training.
Although all team members learn all the jobs, the roles assigned for the
high-pressure team navigation task include a match of individual ability to
role. For example, the timerlrecorder position requires simultaneously writ-
ing, talking, and listening, with selective attention to conversation in the pilot
house and over the phone circuit. Even when novices reach a point of
competency in individual task performance, they may yet fail as a team
member under the demands of the cooperative task.

3. DATA COLLECTION

The main data collection took place aboard a U.S. naval vessel by Colleen
M . Seifert. This involved a total of 48 hr of observation. Most of this time
involved observing solo navigation at sea with a novice apprentice. Under the
team navigation configuration, two separate entrances and exits from the
harbor were observed, with on the order of 40 fix cycles each. Observations
and protocols were collected, along with interviews of each team member
within the cooperative system. The resulting data consisted of structured field
notes detailing example sequences, with special attention to error processes. A
single team of six crew members was observed, with all participants appearing
in the same roles for team navigation (their standard positions). This crew had
been working together for 6 months, and individual tenures ranged from 1
year as bearing taker to a total of 18 years in all roles by the senior navigator.
T o provide some comparison across different teams, these observations were
supplemented by videotapes and transcriptions from two studies by Edwin L.
Hutchins aboard other ships (Hutchins, 1989, in press).

4. SITUATED LEARNING

Novices in this distributed system are task-embedded learners: They learn

about the job they currently do, and about possible future tasks, through
 418 SEIFERT AND HUTCHINS

interaction and observations of others. By participating in the cooperative

task, novices come to understand the task-related needs of others. Through
interaction in the distribution system, they learn, on the job, how to structure
their task activities to coordinate with and assist others. This interaction also
highlights the important features of their job and other tasks they may
themselves perform in the future. Other learners also provide models of the
learning process itself, and this meta-knowledge may be helpful to novices in
forming expectations about their own performance.
Several distinct opportunities for learning were observed in the distributed
system for navigation. Novices learn by observing the practice of other tasks at
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

close range and by participating in reasoning about them. The other

performers in the task environment serve as models for appropriate task
performance, and the learner is in a position to observe how the results of
others' performances relate to the overall functioning of the team. A second
mode of learning is learnzng by doing (Anzai & Simon, 1979), in which situated
actions can be taken and responses determined. Learning by doing means that
the novice can participate in the task before understanding how or why each
part is accomplished, and with only a limited initial understanding of his own
role in the system. Explicit instructton is also utilized with novices in informal
apprenticeships (during solo navigation watch at sea). In this setting, novices
can attempt the full range of tasks under the expert's guidance. Because the
goal of the system is accurate performance rather than deep understanding,
instruction is focused toward ability to do the task, rather than to model or
explain why it is done that way. Advice is always situated in terms of
accomplishing specific tasks.
Finally, a major mode of learning involved committing errors and receiving
feedback. The detection of errors based on the observation by a wide audience
within the team provided a redundancy of expertise that facilitated noticing
errors. Overall, the high rate of errors committed, detected, and diagnosed
appeared to benefit participants by providing multiple opportunities for
learning about the distributed task environment.

5 . LEARNING FROM ERROR

One function that the distributed system appears to serve is the detection,
diagnosis, and correction of errors during task performance. This robustness
feature is quite adaptive for the system, given that it must function with
novice participants who may be more prone to error. In the next sections, we
examine evidence of errors and discuss how the design of the distributed task
system offers the potential to learn from error while producing accurate
results in the final stages of team performance.
 ERROR AS OPPORTUNITY

5.1. Error Frequency

Close examination of the navigation team operations revealed a surpris-

ingly high frequency of error. Observing only the final output of the
team, few problems were encountered; in our study, no serious errors were
ever found in the later stages of the team performance (on the final posi-
tion charted), where they might have affected command decisions. Indeed,
the senior navigator could name only two navigation-related accidents on
any active naval ship in a 20-year period. So, although many errors
were committed during the process, virtually all of them were detected
and corrected within the navigation team itself, before its output was
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

reported.
The number of errors produced, and caught, is much larger than might be
expected given the low overall rate of navigational accidents. Although
complete counts are not available for the main dataset, coverage of error types
was recorded. For example, in one exit from harbor, every team member
committed at least one error that was detected and corrected by another team
member. Two of these four error types, jinding landmarks and reading
compasses, are exactly the type of individual task performance errors one
would expect from novices in an on-the-job training context. A third type of
error, monitoring errors, are individual errors that humans are particularly
prone to due to limitations of attention and vigilance. Finally, coordination errors
are a direct result of the need to cooperate with other team members; for
example, bearing takers make decisions on the fly about turn taking in
reporting, based on not only their own task information but also on
knowledge of the other's current task constraints (who has the beam bearing,
who has two locations to shoot).
Although not all observed recoveries from error were instructional in intent
or consequence, some error recovery strategies involved the detection of
error, diagnosis of the source of the error, and perhaps explicit demonstration
of the correct solution in order to benefit the learner. Thus, errors may serve
to focus attention on whichever parts of the task are misunderstood by the
novice. In the next sections, we present specific examples of error detection,
diagnosis, and correction, and we also explore the distributed system
properties that they illuminate.

5.2. Novice Errors

The most novice members of the navigation crew are first assigned to the
task of taking bearings. Thus, our analysis focused on errors made by the
bearing takers. The results showed that almost every step of the bearing-
 420 SEIFERT AND HUTCHINS

taking task included some observed error. The observations provide evidence
of four main error types arising from subtasks in taking bearings. Examples
of each of these error types follow (BT = bearing taker, T / R = timer/
recorder, P = plotter).

Find: Difficulty locating or centering sight on a landmark.

Example:
BT1: (Is it) The one on the left or the one on the right?
TIR: The one on the left, okay?
BT1: Yeah, I got it.
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

Monitor: Failing to attend to instructions.

Example:
T/R: Pick up Light 2.
TIR: Mark.
BT1: (Silence)
P: (Grabs phone to bearing takers) What is the problem with Light
21 You're late. We missed the beam bearing.

Read: Incorrect measurement from the compass card

Example:
BT2: Alpha is 324 . . . 313.5.
TIR: Tighten up on alpha, it's not cutting it!

Coordinate: Difficulty in turn taking on limited channel.

Example:
BT2: Del Coronado is 227.
B T l : Light 3 is 93, Light Victor is 25.
T / R : BT1, would you let BT2 go first? Whoever has two reports
first, doesn't matter who has the beam to shoot.

This last example illustrates a problem due to the coordination of reports -

one bearing from one taker and two from another - given that one taker has
to give two reports depending on the location of the selected landmarks. The
instructions indicate that the taker with two reports should be allowed to
report first, so he can move quickly to perform the second reading (which
should be taken as close together in time as possible). However, another factor
enters into consideration here, namely, that the bearing closest to the beam
(midship) must be taken first, because it changes most quickly with the ship's
forward progress. Therefore, the first bearing observation taken should be the
beam bearing. In this case, it appears the novice takers may have combined
the two principles, resulting in attempting to report, rather than shoot, the
beam bearing first.
 ERROR AS OPPORTUNITY

5.3. Error-Based Instruction

Within the distributed system, errors can be very useful in guiding the
instruction given while learning on the job. Rather than trying to inform
about all possible knowledge needed, novices can be encouraged to attempt
tasks and be given instruction only on the aspects of the task that result in
error. In this way, errors can serve to guide instruction in the learning
process, indicating in very specific ways exactly what information or skill is
missing in the current knowledge state of the novice. Consider this example
of a senior navigator interacting with a novice plotter.
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

A novice navigator was asked, "How far west shall we go to get back to
harbor at 1600?" The ship was directly west of the harbor entrance (time
= 1200). He paused, then measured the distance the ship could go in an
hour and marked it with a divider; he then marked four hour-lengths
from the harbor entrance on the chart. This position lay far west of the
ship's current position. A more experienced crewmember was moni-
toring and said, "If he wants to be back by 1600, he's not going to go
west from now until he hits this point!"

One solution procedure for the problem would be to measure the current
distance to the harbor, compute its travel time, and then subtract that time
from the total 4 hr. Any time remaining could then be divided by two, such
that equal remaining time is spent continuing on and returning to the current
position. The novice appears to begin part of this solution procedure (marking
the distance traveled with a length-preserving tool, a divider). However,
instead of determining the distance to shore, the novice computed the ability
of the ship to travel a particular distance within the time interval. It appears
the novice did not know how to adapt the more familiar procedure for finding
travel distances to the course recommendation question.
Responding to error appropriately depends on understanding how the error
may have been generated, perhaps through modeling the reasoning processes
of the person who committed the error. Through such understanding, the
expert can gear the presentation of a solution in a way that is appropriate to
the novice's current knowledge state. The instructor may also benefit, as
diagnosing the cause of an error may produce a new insight about the task
processes. This is true whether the error was committed by the learner or
observed in someone else. Novices in particular benefit from the opportunity
to observe the diagnosis of other's errors and the explication of the error
maker's missing knowledge. Every witnessed instance of error provides an
opportunity for learning or the confirmation of knowledge, potentially saving
the system from future errors.
 422 SEIFERT AND HUTCHINS

5.4. Error Feedback

Feedback on how to correct error is extremely important to the learning

process. Without correction, further errorful performance has been found to
increase familiarity with the error path, thereby increasing the tendency
toward error (Anderson, Boyd, Farrell, & Reiser, 1984). If competing
solutions are presented as feedback, however, the error may serve to correct
information that has been demonstrated as faulty in the novice's knowledge
base. Feedback can contribute to understanding task requirements that may
not be apparent under error-free performance. Thus, on-the-job learning
may actually be facilitated by error and its consequent opportunity for
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

instruction.
This is especially important with concepts that must be inferred from
examples rather than explicitly stated. Because relevant information for a
decision may not be directly observable or explicable by an expert, novices
may have to infer information from experience in a variety of situations,
guided by error correction on specific failures. Where there is a solution space
to be explored, feedback can guide the discovery of the concepts underlying
solutions. Consequently, a novice who makes few errors may actually learn
less about the task through training than one who, as a result of making
errors, has explored more information within the domain. The implicit nature
of domain knowledge in the navigation task requires learning directed by
error. Novices are allowed to do their best and are provided with correction
and instruction on the particular errors they make. This provides a more
efficient system for training, because costly explicit instruction is minimized.
Interestingly, the content of feedback while under team configuration was
extremely sparse. The observed feedback was frequently stated in very
general terms, such as "tighten up out there." Such limited feedback is not as
helpful as a more complete demonstration or instruction; for example, a
bearing taker will not know whether his reading is off because he selected the
wrong landmark, the wrong portion of the landmark, read the scale incor-
rectly, or reported it incorrectly. At least, however, this general feedback
serves to focus novices' attention to the errors they make, presumably
motivating attempts toward improvement. Such limited feedback may be the
only response the error detector can provide during the ongoing task. Because
errors are corrected during performance of the on-line task, and the detector
is also involved in his own subtask, there may be insufficient time, processing
resources, or communication channels for the composition and delivery of
appropriate instruction. Yet novices appeared to benefit even from this
limited feedback, without the added cost of unnecessary duplication of team
members in the role of "trainers."
Additional learning opportunities are provided in the distributed system
through the errors that others make. When an error is detected and corrected
 ERROR AS OPPORTUNITY 423

in the context of collaborative work, many participants may witness and

benefit from the response to error. The novice has the opportunity to observe
others' errors, witness their correction, and participate in detecting the errors
of others. Thus, the socially distributed task gives a participatory role (Lave
& Wenger, 1991) to the novice in all areas of task performance, including
error correction, that he is able to witness. Observing correction may also be
of value to those who are already competent in the task. Content-based
feedback may help in acquiring meta-level strategies about how to monitor
and detect errors. Novices can also learn how to provide useful feedback by
watching the corrections of others. Thus, the value of a response to error for
future performance may extend to other team members who simply witness
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

the error-and-correction process.

6. NATURE OF THE DISTRIBUTED TASK

Successful learning from error requires cognitive resources that could

otherwise be directed toward the task. T o minimize this cost, three elements
are incorporated that facilitate error detection: shared task knowledge, which
enables the monitoring of ongoing activity by other knowledgeable partici-
pants; horizon of observation, which allows team members to witness others'
performances; and multiple perspectives, so that activities can be observed from
different points of view. First we examine the task distribution in the existing
system to determine how cognitive functions are instantiated within the team.
Then, after presenting the three error detection capabilities of this system,
social and motivational factors are discussed.

6.1. Analysis of Task Knowledge

A task analysis was performed of the cycle of team activity in computing

the location fix. The analysis focused on the cognitive functions necessary to
complete the overall task but without regard for how these tasks are actually
organized in the current cooperative setting. The logical components of task
performance were identified in terms of the information that must be
collected and used to complete the task.
The cognitive subtasks identified were:

Align Map tool onto representation (i.e., compass to object).

Compute Perform calculations (i.e., dead reckoning).
Select Choose among options (i.e., pick three lines of position)
Coordinate Share a limited resource with another actor.
Evaluate Compare computed position to actual space.
Find Locate an object in space (i.e., a line of position).
 SEIFERT AND HUTCHINS

Initiate Decide when to begin an activity (i.e., issue command).

Monitor Listen for signal to act (i.e., command to "mark" positions).
Parse Take input information and transform for use in task.
Read Describe output of a measurement/computational device.
Record Enter information onto appropriate recording medium.
Report Output information to appropriate receiver.

Except for one subtask (evaluate, which is performed only in the final step of
the cycle), each cognitive subtask is performed in more than one task and by
more than one team member.
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

In addition, there are interactions with various tools to assist in task

performance. These tools include:

Gyrocompass A device designed to indicate bearing of land-

marks.
Telephone Line connecting the bearing takers to the recorder.
Recorder log Reports of bearings are written down as generated.
Hug Graphing device designing to maintain line angles.
Chart Graphical depiction of navigable areas (see Figure
2).
Compass and divide7 Tools to mark and measure distances on the chart.
Timing clock Clock with minute hand used to time cycle activity.
Deck log Separate record logbook noting all bridge activity.

This task analysis proved useful for detecting commonalities across tasks and
identifying potential alternate configurations for task distribution. Next, the
specific distribution of these cognitive subtasks within the observed naviga-
tion team was determined. Each of the subtasks identified is presented within
the groupings organized within the distributed navigation task in Figure 4.
The task analysis shows that the needed tools (e.g., compasses or charts) are
adequately arranged so that individuals have control of the tool as needed to
perform tasks. In addition, the analysis corresponds well to divisions within
team members, such that similar repeated tasks appear grouped within
individuals rather than distributed across them (the plotter records all three
lines of position on the chart). However, the interactions required by this task
design (shown with arrows) indicate potential difficulty based on the unor-
dered sequence of activity on shared channels (particularly the phone circuit).
Although the tasks themselves have a standardized order (illustrated vertically
on the page), the team interactions are left unscheduled and may be
considered chaotic in comparison. This open-ended communication sequence
requires additional work by the crew members to coordinate their actions.
 ERROR AS OPPORTUNITY 425

Figure 4. An information-processing task analysis reveals the components of

cognitive subtasks, the tools used, and the organization of subtasks within the
group's activities. Communication channels are marked as arrows.

- Bearing Taker 1
PARSE
oOWNATE
Tirner/Recorder
PARSE
em
Plotter
COMWlE

+ MONITOR

-
4 PARSE
MONITOR

-
MONITOR c MONITOR
COORDINATE 4 PARSE
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

MONITOR
PARSE MONITOR
Bearing Taker 2 * PARSE
PARSE m
ALIGN

COORDINATE
m PARSE
EVAL
m REPORT
LlGN

m
LOG BOC)r
I Deck Log
Recorder

6.2. Shared Task Knowledge

The distribution of knowledge (Hutchins, in press) in the navigation team

ensures that most errors will be detected by members who already have
experience with the operations that cause error. Because team members work
their way up through the positions to plotter, each has already performed the
job of the more novice participants. Past familiarity with the task assists in
modeling others' performances and in determining the source of error. Thus,
in the navigational system, access to error and knowledge of its potential
causes are aligned. In fact, the learning trajectov for individuals (Hutchins, in
press; Lave & Wenger, 1991) follows the path of information through the
system in the team's most basic computation, fixing position. The simplest jobs
involve gathering sensed data (bearing taking), and the more complex jobs
involve processing that data (plotting). As a consequence of this alignment, if
 426 SEIFERT AND HUTCHINS

one has access to an error, one also often has knowledge of the processes that
may have generated it. This is because one has already - at an earlier stage in
learning-performed all those subtasks that one now observes in others'
performances. The overlap of access and knowledge that results from the
alignment of career path and data path is not a necessary feature of this
system, but it does give rise to especially favorable conditions for the detection
of error.
The cooperative task environment results in many errors being detected by
team members who are simply monitoring the actions of those around them.
Because each actor is not constantly occupied, there is ample processing time
available to observe the activities of others on the team. Indeed, the team
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

distribution is set up both physically (spatially and through the phone circuit)
and conceptually so that activities of team members are often conducted
where they can be observed by others. This incidental monitoring is an
important factor in error detection. Consider this example (DL = Deck Log
recorder):

P: One, two, three. Same two. Ballast Point, Bravo. And the next
one . . .
TIR: (On phone to takers) Time 40 should be, Ballast Point. . . .
P: Front Range, Bravo.
TIR: (On phone to takers) And Bravo. . . .
DL: He may not be able to see Front Range from here.
TIR: Yeah.

In this example, the deck log recorder, who is not involved in taking
bearings (he answers questions about past course information and changes),
monitors and notices that one landmark (Front Range) will be difficult for the
taker to see from his current location. This type of monitoring was frequently
observed, especially during periods of low work demand in tasks within the
observation area. Because detection requires attention, however, one of the
costs of increasing current workloads within the team members may be the
reduction of resources available for monitoring and correcting errors.
An additional monitoring source that can assist with errors is the
fathometer operator. This operator is in the position to overhear any
conversations on the phone circuit. Consider this example, where the
relatively inexperienced timerhecorder has selected the last set of landmarks
to be observed (FO = Fathometer Operator):

BT1: Hotel Del 066.

T/R: 066 Hotel Del.
BT2: Point Lorna 275.
 ERROR AS OPPORTUNITY

T/R: 275 Point Loma.

BT1: Light Zulu 049.
TIR: 049 on Light Zulu.
FO: What was Point Loma?
TIR: 275. (Pause)
P: What did you take a bunch of beam bearings for? Look what you
did. You shot three beam bearings. Better tell them to shoot from
up ahead someplace.
TIR: Okay, drop Point Loma and pick up Ballast Point, John.

In this example, the fathometer operator detected the poor pattern of lines
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

of position from the bearings reported by the takers, and, with a question, he
communicated a problem with the three sightings (with three sightings close
to horizontal, the triangle formed by the intersecting lines is harder to chart
and less accurate than three more varied bearings). The fathometer operator's
interaction with the team is normally limited, but in some situations this extra
monitor is in a position to facilitate error detection in the sensing loop of the
navigation team. Thus, shared knowledge distributed over the team, although
irrelevant to one's own task, may assist in monitoring for error as participants
learn by doing.

6.3. Horizon of Observation

The utility of shared knowledge can be enhanced by providing access to

others' performances. This horizon of observation is the functional workspace
that each participant can monitor in addition to his own task. Hutchins (in
press) argued that the size of this observation window can have an impact on
error correction because it allows or limits monitoring by other team
members. The main constraint on observing others is the physical setting (see
Figure 1). In the setting, those members on the bridge are in a position to
observe and interact about each other's performances. The bearing takers,
however, are physically isolated from the team outside of the pilot house. As
a consequence, those within the pilot house are unable to observe the bearing
taking directly, and they must instead rely on reports from the timer1
recorder.
The design of the system makes it extremely difficult for those outside of
the phone circuit (the plotter, evaluator, and deck log recorder) to monitor
activities in the bearing-collection portion of the cycle. Consequently, the
most expert team members do not have direct access to the performance by
the most novice members (the bearing takers). Instead, their observation of
the takers' behavior is mediated by the timer/recorder. This results in a
 428 SEIFERT AND HUTCHINS

Figure 5. Schematic depiction of information flow within the navigation task.

The positioning of the timerhecorder in the communications network results in
a filtering of information from the left half of the network.

BEARING TAKER PLOTTER

Downloaded By: [University of Michigan] At: 20:09 19 February 2009

limited ability to recognize the source of error in the bearing-collection cycle.

Consider this example:

BT2: Ballast Point, 331.

TIR: Ballast Point, 351.
P: (Attempts to mark on chart) What's happening up there?
Tell BT2 to tighten up! That one was off!

The protocol suggests that this error was generated in the verbal report of
information by the tirnerlrecorder, not in the reading process by the bearing
taker. Given the distributed task structure, however, there is no reliable way
for the plotter to distinguish errors that may have been generated by the takers
from those generated by the tirnerlrecorder. Consequently, the diagnosis of
the error source may frequently be impossible or inaccurate. Figure 5 depicts
a schematic flow of information from the takers through the plotter and
evaluator.
As shown in the diagram, the timerlrecorder serves as a filter between the
information-gathering tasks (the bearing takers) and the information compu-
tation tasks (the plotter). This filter point makes the diagnosis of responsibility
for error within the information-gathering loop very difficult from outside the
loop. Most often, errors generated in the information-gathering loop are
simply assumed (often incorrectly) by the plotter to be the consequence of
error by the bearing takers.
This property of the system facilitates observing errors by others; however,
an unlimited horizon of observation might prove too distracting as individuals
perform their own tasks. The particular arrangement within the navigation
system may be the result of the technologically limited means of communi-
cation between the takers and the rest of the team. Thus, one improvement to
the system might include some recording technology that would supplement
the timerlrecorder as the information filter in the bearing-collection task.
Some improvement in the current system may facilitate error correction
across team members by enlarging the horizon of observation.
 ERROR AS OPPORTUNITY

6.4. Multiple Perspectives

The ability to detect errors is also enhanced by differences in perspective

among members of the team. For example, the bearing takers may assume the
perspective of "meter readers" in their task, ignoring the physical location
perspective, which could lead to expectations about the readings. Conse-
quently, they often fail to detect errors that they could have recognized from
a physical direction perspective. Bearing observing requires little thought
about how the information is used and little motivation to think about the
bearing in terms of the coordinate space of the chart. Consequently, error in
bearing readings is propagated through the system past the point where it
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

could potentially have been detected.

This separation of information gathering (taking bearings) from its later
use (direction from landmark) is not essential. Adopting a physical location
perspective would facilitate being able to detect one's own or others' errors.
One method that may encourage bearing takers to adopt a physical world
perspective is to introduce an artifact representing directional coordinate
space into the work environment. For example, the full 360-degree represen-
tation could be given on the gyrocompass instead of the partial display
currently provided. Such a cognitive artifact would serve to remind the takers
of the coordinate space and, therefore, of the plausibility of the reported line
of position.
However, there may be some cost to altering perspective for the bearing
taker; currently, his focus is on accurate sighting and reading through the
telescopic sight. If the locational perspective were provided during the task,
the taker may indeed be more likely to notice his own errors when they do not
correspond to the world; however, this perspective may also introduce a
"top-down" bias. For example, knowing a landmark's location in the world
may affect accuracy when reading the gyrocompass. This bias would make it
harder to notice other sources of error, such as malfunctions in the gyrocom-
pass. In this example, performance of the specific subtask, reading the
compass, may be better when unaltered by the perspective of how that
information is to be used in later stages of computation. Although broadening
perspective may improve an individual's ability to detect his own errors, it
includes the cost of introducing other types of errors based on expectations.
The observed solution within this cooperative system is to locate the error
detection function within other members of the team.
This division of tasks into separate spheres, where the results are monitored
and problems detected by a separate agent with a different perspective, is
clearly demonstrated in the role of evaluator. The evaluator is a qualified
navigation practitioner, usually the navigation officer. He does not engage in
any of the navigational computations but assesses the quality of the output at
the end of each cycle. The evaluator reports the navigation results to the
 SEIFERT AND HUTCHINS

commander and attempts to reconcile the representation of location computed

on the chart with the real world visible outside the pilot house windows. For
example, the evaluator may state, "Current location is 200 yards from
Lighthouse 2, Bearing 090," which is then compared to the visual scene from
the bridge. The evaluator adds onto the system the comparison of how well
the results of the computation fit the physical world it measures.
The important structural property of the evaluator role is that he has access
to all of the information (he is located near the chart) and complete knowledge
of how to perform the task, yet he does not participate in the computation as
it is performed. He serves to monitor rather than perform (Miyake, 1982),
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

and, as such, he serves an important function in providing an unbiased

external evaluation of the process he observes. As with the bearing-taking
examples, the perspective of the evaluator could be blended with the
computation occurring at the chart, and his assistance within the plotting task
may help to catch more errors. Participating in the computation, however,
has the cost of invoking a task perspective, which may make it more difficult
to avoid bias in the later evaluation task. The solution to this tradeoff between
computation and unbiased evaluation is again to institutionalize the alternate
perspective in a separate individual (the evaluator). Because individuals have
difficulty considering alternatives due to factors such as confirmation bias,
the distributed task setting takes advantage of multiple perspectives indepen-
dently maintained within the team.

6.5. Social and Motivational Factors

The social and motivational aspects of cooperative tasks may greatly affect
performance. In this setting, the group identity appeared to provide motiva-
tion for individuals to participate in minimizing error. Each member of the
team is taught to feel responsible not only for his own job but also for all parts
of the process to which he can contribute. Likewise, when an error is made,
the entire team accepts responsibility. For example, one bearing taker said of
another that, "I have to watch out for him, 'cause he goofs it up a lot."
Similarly, the senior navigator assessed the team's strength in terms of the
whole, rather than based on individual competencies: "There are a few that
will need some help, but every one of them looks out for the others and makes
sure the job gets done." Therefore, the social context of the group task
facilitates attention to error as a feature of the distributed task environment.
Distributed tasks also serve needs for individual group members (Hackman
& Morris, 1975), and membership in the navigation team was important to
the crew members. Social motivation among the team was observed in the
form of competitive comments by team members about other crews; for
example, one navigator remarked that his team was "the best crew aboard this
 E R R O R AS OPPORTUNITY 43 1

ship. Ask anyone; they will tell you that the navigation crew never screws up."
This team's reputation for error-free performance testifies to the effectiveness
of the error correction mechanisms within the system. In addition, the
navigation crew tended to spend off-duty hours on the bridge, observing other
team members at work and studying together. These social factors presum-
ably play an important role in motivation, learning, and performance.

7. DESIGNING FOR LEARNING

Norman (1983, 1986, 1988) argued that, because error is inevitable, it is
important to "design for error." Norman suggested that designers should
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

minimize the causes of error, make it possible to "undo" errorful actions, and
make it easier to discover and correct errors. These same goals are appropriate
for designers of cooperative work systems; in addition, our results suggest a
goal to include mechanisms that help participants learn and benefit from the
errors that will inevitably occur. The advantage of designing for error is that
the cooperative system can turn occasions of error into opportunities.
A question remains about whether the function of providing opportunities
for learning was an intended or fortuitous feature of this distributed system
design. Even though learning may be a constant goal for any system, training
and education often take a back seat to an emphasis on production and
performance. That is, the main source of pressure on the team is simply to
produce accurate and timely navigational information; their internal needs
for learning and training are secondary. Second, even if adapting the system
to promote learning were the explicit goal, it is much more difficult to design
for learning than for system performance. With performance, feedback on
success and failure is immediate and clearly defined; for learning, however,
it is difficult to measure whether improvement not directly reflected by
performance measures (such as deeper understanding) occurs. Consequently,
the performance feedback provided may serve to guide novices to learn to
perform their task, rather than learning about navigation more generally.
However, the errors and corrections observed appear to provide both
learning opportunities and improved performance by the distributed task
team. At the same time that the system design facilitated on-the-job
instruction, the built-in functions for correcting errors ensured that final
system output was relatively error free. This coupling of learning through
error with a robust network for catching errors before final output is the
central strength of this task design. The cooperative system in this case study
meets the goals of accurate performance along with tolerance for errors as
novices participate in the task system.
The improvement in error detection, diagnosis, and correction capabilities
within a system may have other consequences for system performance.
Design decisions will involve trading off enhanced capabilities in one area
 432 SEIFERT AND HUTCHINS

against less optimal processing elsewhere in the system. For example, the
multiple perspectives of crew members were observed to affect the ability to
detect errors within the system. This task division separating evaluation from
computation includes sacrificing the advantages of including this participant
within the computational processing. The gain from this separation of
evaluation is that possible bias from having participated in the computation
process is avoided. A multiple-perspective system may avoid the confirmatory
bias prevalent in individual reasoning by supporting multiple solution paths
simultaneously.
Other design tradeoffs include shared knowledge, which improves diagnosis of
error by including expertise in redundant units within the system but
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

increases overall costs due to frequently underutilized expertise and training;

the horizon of observation of other participants, which increases possibility of
error detection but also increases distraction from individual task perfor-
mance; and, more generally, the frequency of errors, which on the positive side
allows opportunities for learning but also creates cost in task performance and
in resources devoted to detection and recovery.
Recognizing the nature of the tradeoffs and identifying the properties of
cooperative systems that affect them is a useful step in identifying design
variables for cooperative systems and the technologies that support them. The
optimal points on these tradeoff continua may be quite subtle, and they may
be defined very differently for different task organizations, computation cost,
and turnover of participants. For example, in other cooperative task situa-
tions, the current set of goals being pursued may change throughout the task,
rather than as a repeated configuration of goals. This aspect of design, the
introduction and modification of new goals, may qualitatively change the
ability of the system to respond optimally to the tradeoffs identified eariier.
Achieving benefit from error is not automatic, but it requires designs that
are likely to facilitate noticing, recovering from, and changing future
performance based on learning from errors. Two major constraints domi-
nated the design features of the distributed system studied here: efficiency of
overall task performance and efficiency of knowledge acquisition. The
robustness of the system serves the function of quality performance despite
high local error rates; if one component fails for lack of knowledge, the whole
system does not also fail, because both knowledge and responsibility are
distributed across members of the team. The second constraint, that of
providing for on-the-job learning, suggests that an optimal task partitioning
should provide good task decomposition, so that novices can practice man-
ageable skills while learning in context. In addition, communication among
team members should be facilitated, so that the functions of error detection,
diagnosis, and correction can be distributed across all available task members.
Lines of communication among these participants have consequences in
defining the portion of task environment available as a learning context
 ERROR AS OPPORTUNITY 433

There is evidence from other cooperative tasks that the design criteria
identified here are potentially very important to distributed systems. For
example, aviation research on the cause of jet transport accidents world-wide
found 60 cases that were due to breakdowns of cooperative crew performance
(Cooper, White, & Lauber, 1979). Foushee and Helmreich (1987) and
Hackman and Morris (1975) found that process loss is inherent in any
cooperative task; however, the redundancy of expertise in such groups did
produce a gain in performance. These studies suggest that increased famil-
iarity with interactions during team performance improves the overall task
performance. In addition, they suggest that training should occur in high-
error-rate scenarios (at least in simulation), where error detection, diagnosis,
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

and recovery skills can be practiced. The commonalities between airline crew
systems of cooperative work and the case study presented here suggest that
other types of distributed systems could benefit by planning and designing for
the features found to be critical to learning and performance in the
navigational task.
In any system where individual performance is mediated by group activity,
learning on the job and consequent errors will occur. Technological innova-
tions suggest possibilities for methods to support learning and correcting
errors. For example, interfaces that support error-prone tasks such as
monitoring and computation could be added into the distributed setting. In
addition, programs that monitor subtask output and detect errors could be
added, which might include a model of the desired relationship between the
task parts. Simple recording devices could improve the ability to detect where
errors are occurring and provide the ability to review performance for
instruction. Finally, computer-supported cooperative systems could be uti-
lized to train and test performance by learners in a simulated task environ-
ment. With a high-quality simulation of the situated task setting, novices
could be provided with relevant experience before having to meet perfor-
mance requirements on the job.

8. CONCLUSION

Errors will occur in any system of human behavior; however, cooperative

systems can be designed so as to benefit from unavoidable errors by turning
them into learning opportunities. The intent of this research was to examine
how learning from errors takes place in a natural setting and, in particular,
how the cooperative task setting may foster on-the-job learning. The con-
straints on this distributed system organization include not only successful
completion with minimal output error but also that the system replicate itself
and train novice team members on the job.
The distributed work setting provides a constrained environment for the
novice learner that makes participation possible well before mastery of the
 S E I F E R T AND H U T C H I N S

tasks. T h e cooperative task design provides a mechanism for errors to indicate

where further instruction is necessary. I n on-the-job settings, t h e ability to
m a k e errors a n d receive appropriate feedback m a y b e quite beneficial t o the
learner. T h u s , the system allows for detection, diagnosis, a n d correction of
e r r o r s while avoiding their propagation into the final decision phase o f the
task. T h i s analysis identified design tradeoffs that affect learning a n d
suggests designs that m a y facilitate learning i n other distributed systems.

Acknowledgments. Preliminary results were published in the Proceedings of the

Eleventh Cognitive Science Conference, 1989 (see Seifert & Hutchins, 1989a), and the
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

Quarterly Newsletter of the Comparative Human Cognition Laboratory, 1989 (see

Seifert & Hutchins, 1989b). Thanks to Don Norman and the Cognitive Science
Laboratory of the University of California, San Diego, for helpful discussions and to
Robert Kraut, Roy Pea, and two anonymous reviewers. This study was conducted
under the auspices of the Naval Personnel Research and Development Center, San
Diego. Special thanks to Joseph MacLachlan and the U.S. Navy officers and crew who
participated in this study
Support. This work was supported by the Naval Personnel Research and Devel-
opment Center in San Diego, California; the Office of Naval Technology and
American Society for Engineering Education Postdoctoral Program; and the Office of
Naval Research under Contract N0014-91-J-1128 to the University of Michigan.

REFERENCES

Anderson, J. R . , Boyd, C. F., Farrell, R . , & Reiser, B. J. (1984). Cognitiveprinciples

in the design of computer tutors (Office of Naval Research Tech. Rep. No. 84-1).
Pittsburgh: Office of Naval Research.
Anzai, Y., & Simon, H . A. (1979). The theory of learning by doing. Psychological
Review, 86(2), 124- 140.
Cooper, G . E., White, M . D., & Lauber, J. K. (Eds.). (1979). Resource management on
thej'ight deck (NASA Technical Memorandum 78482). Moffett Field, CA: NASA-
Ames Research Center.
Foushee, H . C . , & Helmreich, R. L. (1987). Group interaction and flight crew
performance. In E. L. Wiener & D. C. Nagel (Eds.), Humanfactors in modern aviation.
New York: Academic.
Hackman, J . R . , &Morris, C. G . (1975). Group tasks, group interaction process, and
group performance effectiveness: A review and proposed integration. In L.
Berkowitz (Ed.), Advances in experimental social psychology (Vol. 8). New York:
Academic.
Halff, H. M . , Hollan, J . D., & Hutchins, E. L. (1986). Cognitive science and military
training. American Psychologist, 41(10), 1131-1 139.
Hutchins, E. L. (1986). Mediation and automatization. The Quarterly Newsletter of the
Laboratory of Comparative Human Cognition, 8, 47-58.
Hutchins, E. L. (1989). The technology of team navigation. In J. Galegher, B. Kraut.
& C . Egido (Eds.), Intellectual teamwork: Social and technical bases of collaborative work.
Hillsdale, NJ: Lawrence Erlbaum Associates, Inc.
 ERROR AS OPPORTUNITY 435

Hutchins, E. L. (in press). Learning to navigate. In S. Chaiklin & J. Lave (Eds.),

Understanding practice. New York: Cambridge University Press.
Lave, J. R., & Wenger, E. (1991). Situated learning: Legitimate peripheral participntion.
New York: Cambridge University Press.
Maloney, E. S. (1985). Dutton's navigation andpiloting. Annapolis, MD: United States
Naval Institute Press.
Miyake, N. (1982). Constructive interaction (CHIP Tech. Rep. No. 113). La Jolla:
University of California, San Diego, Center for Human Information Processing.
Naval Technical Training Development Unit. (1987). Quartemaster Class A School
A-061-0012 student guidt and instructor guide, Quartermaster 3 rate training manual.
Millington, TN: United States Navy.
Norman, D. A. (1983). Design rules based on analyses of human error. Communications
Downloaded By: [University of Michigan] At: 20:09 19 February 2009

of the ACM, 4, 254-258.

Norman, D. A. (1986). Cognitive engineering. In D. A. Norman & S. W. Draper
(Eds.), User centered system design: New perspectives on human-computer interaction (pp.
3 1-62). Hillsdale, NJ: Lawrence Erlbaum Associates, Inc.
Norman, D. A. (1988). The psychology of everyday things. New York: Basic Books.
Rogoff, B., & Lave, J. (Eds.). (1984). Everyday cognition: Its development in social context.
Cambridge, MA: Harvard University Press.
Schwartz, J. P., Kullback, J. H., & Shrier, S. (1986). A framework for task
cooperation within systems containing intelligent components. ZEEE Transactions on
Systems, Man, and Cybernetics, SMC-16(6), 788-793.
Seifert, C. M., & Hutchins, E. L. (1989a). Learning from error. Proceedings of the
Eleventh Conference of the Cognitive Science Society. Ann Arbor, MI.
Seifert, C. M., & Hutchins, E. L. (1989b). Learning from error within a cooperative
system. Laboratory of Comparative Human Cognition Newsletter, 1I(4), 108- 114.
Suchman, L. A. (1987). Plans and situated actions: The problem of human-machine
communication. Cambridge, England: Cambridge University Press.

HCZ Editorial Record. First manuscript received April 15, 1991. Revision
received May 1, 1992. Accepted by Robert Kraut. Final manuscript received June 12,
1992. -Editor

View publication stats