(Computer Supported Cooperative Work) Andy Crabtree - Designing Collaborative Systems - A Practical Guide To Ethnography (2003, Springer) PDF

Designing Collaborative Systems
Andy Crabtree
Designing Collaborative Systems:
A Practical Guide to Ethnography

(Copyright/Imprint page)
For James & Heather
Preface
This is a book about understanding work for purposes of collaborative systems
design. It is especially concerned with ethnomethodologically-informed
ethnography as a means of analysing work, and to articulate ways in which such
ethnographic studies might be related to design. In a design context,
ethnomethodologically-informed ethnography is often simply referred to as
ethnography, a convenient abbreviation that will be employed here.*
Ethnography is an approach to social research that is of increasing interest to
the designers of collaborative computing systems. Rejecting the use of theoretical
frameworks and insisting instead on a rigorously descriptive mode of research, the
approach is considered to provide a valuable means of analysing the social
circumstances of systems usage, the latter being a factor that an increasing number
of designers identify as crucial to successful systems development. The ‘turn to the
social’ in systems design recognises that computers are employed within situations
of human interaction and collaboration and that the work systems need to support is,
as such, essentially social in character. Placing unique emphasis upon the
observation and description of interaction and collaboration within natural settings,
in contrast to within laboratories, ethnography is an approach that brings a real
world, real time social perspective on work to bear on systems design. The
approach is particularly concerned to identify and convey the ways in which
everyday activities of work (workaday activities) are assembled in the interactions
and collaborations of parties to their accomplishment. The emphasis placed on the
collaborative assembly of work in interaction leads ethnographers to speak of the
‘social organization’ of work or, more simply, of cooperative work – a distinct
focus which underpins ethnography’s appeal to and purchase in interactive systems
design generally.
The purpose of this book is to introduce potential users of ethnography to the
study of cooperative work and, for the more familiar, to articulate practical ways in
which studies of work may be employed in the design process to analyse the social
characteristics of the design space. Accordingly, the book is organized into four
discrete yet interrelated chapters addressing 1) the requirements problem, which
provides the motivation and practical context for the inclusion of ethnography in the
___________
*
It should be said at the outset to avoid confusion that this convenient abbreviation
glosses over a wide variety of different and competing analytic frameworks or
formats, a great many of which provide the analyst with an a priori ensemble of
general theoretical concepts and categories for describing, analysing and
representing work. For sound methodological reasons that will be articulated over
the unfolding course of this text, such ‘generic analytic formats’ are rejected as
inadequate. When and where the notion of ethnography is employed in this text it
should be read then and taken to refer to ethnomethodologically-informed
ethnography and not to the members of that broad family of approaches that employ
generic analytic formats to analyse ethnographic materials, unless it is explicitly
stated to the contrary.
i
Preface
design process; 2) significant ethnographic practices for describing, analysing and

representing cooperative work; 3) the practical relationship between ethnographic
studies and design; and 4) the role of ethnography in the evaluation of systems
supporting cooperative work. While addressing academic problems in each of these
areas, this book is intended to be a pragmatic aid to parties involved in the design of
collaborative systems and so the primary emphasis of the text is methodological in
character. Methodological issues are elaborated through practical examples which
illuminate how cooperative work may be described, analysed, and represented, how
work studies may be structured to inform the formulation of design solutions, and
how ethnography may be employed in the evaluation process. Examples are drawn
from a development case which describes, in turn, the description, analysis and
representation of cooperative work in a library setting, the initial formulation of a
design solution supporting searching’s work, and the elaboration of the initial
design solution through end-user evaluation of the developed system.
At a substantive level, the book addresses the adequacy of Human-Computer
Interaction (HCI) as a primary point of view for describing, analysing and
representing work. It has long been recognised that in concentrating on the
cognitive properties of users, the real world, real time work of competent
practitioners located together in workaday situations is ignored to the detriment of
design. Rather than try to repair the inherent deficiencies of cognitive theory, an
alternative primary point of view for analysis is considered instead. Computer
Supported Cooperative Work (CSCW) places analytic emphasis on the need to
appreciate the collaborative and essentially social character of work in undertaking
interactive systems design. Ethnographic approaches in general are considered to be
a valuable means of describing and analysing cooperative work, though these
approaches are not without their problems. Of particular concern is the ‘problem of
constructive analysis’ that besets a great deal of ethnographic research and sees the
real world, real time social organization of work glossed over and obscured through
the descriptive, analytic and representational use of generic theoretical formats.
Consequently, the development of an informal method of description, analysis and
representation inspired by ethnomethodology is considered as an alternative to
theoretical formats.
Moving to design, the link between studies of cooperative work and design is
explored. Particular emphasis is placed on the role of an adapted patterns language
as a lingua franca supporting communication between ethnographers and designers.
The adapted patterns framework provides a means of structuring ethnographic
studies to support cooperative analysis of the design space and provides concrete
resources informing the co-construction of use scenarios. Use-scenarios articulate
the practical demands that may be placed on systems by users and serve to specify
quality criteria which shape the production of design solutions. Design solutions
may be further elaborated through the construction of prototypes made available to
end-user experimentation. End-user experimentation does not mean that designers
must construct laboratory-based scientific experiments to test the validity of their
systems, but rather that the validity of the system should be assessed in direct
relation to the actual cooperative work of end-users. The final chapter of the book
explores techniques of cooperative design and situated evaluation as a means of
assessing the validity of proposed design solutions and conducting further analysis
ii
of the design space in cooperation with the real experts in work’s accomplishment:
namely, the people who will actually use proposed systems in their cooperative
work.
iii
Acknowledgements
In many and varied ways this book would not have come about were it not for the
encouragement, support and assistance of the following people: John Hughes,
Preben Mogensen, Stella Newton, Tom Rodden, Peter Tolmie, Jon O’Brien, Mark
Rouncefield, Wes Sharrock, Lou Armour, John Mariani, Jonathan Trevor and last,
but by no means least, Suzie Maynard: many, many thanks to you all.
Table of Contents
1. The Requirements Problem 1
The Motivation for Ethnography in Design 1
Analysing the Design Space: The Waterfall Model 2
A Paradigm Change in Design 4
A Primary Analytic Point of View for Design: Enter HCI 8
The User and the Interface in HCI 9
Mapping Mental Models of the Referent System 12
The Referent System in HCI 15
Some Technical Troubles with HCI 15
From Human Factors to Human Actors: Exit HCI 18
Reconceptualising the User 21
Reconceptualising the Interface 24
The Turn to the Social 28
Cooperative Work? 28
Self-organizing Practices of Work 33
2. Making Cooperative Work Visible 37

Ethnography: An Informal Mode of Description and Analysis 39
Investigating Cooperative Work 39
Assembling Data or Instances for Inspection 43
Analysing Cooperative Work 45
The Problem of Constructive Analysis 47
Analysing Cooperative Work: Sacks and Garfinkel 51
Conversation Analysis 52
Ethnomethodological Analysis 56
General Methodology: Thick Description 61
Representing Cooperative Work 65
The Unique Adequacy Requirement 67
The Particular Need to Transcend Generic Analytic Formats 70
3. Work Studies and Design 72

The Role of Ethnomethodological Studies of Work in Design 73
Some Practical Strategies for the Use of Ethnography 74
Using Ethnography to Give Form to Design 79
A Lingua Franca for Design 86
The Adapted Patterns Framework 88
Analysing the Design Space with Patterns
(Formulating Design Solutions 1) 95
Co-Constructing Use Scenarios (Formulating Design Solutions 2) 98
4. Evaluating Systems Support for Cooperative Work 108
Prototyping Methodology 109
Participatory Design 110
Cooperative Design 114
Beyond Political Rhetoric 118
Evaluation of Prototypes 121
The HCI Tradition 121
Alternates to HCI 124
Cooperative Design in Action 126
Situated Evaluation (Formulating Design Solutions 3) 126
Summary 139
References 142
Subject Index 150
3
The ambition of theory-based design in HCI has
been frustrated to a great extent. Through the
1980s, many efforts presumed a simple one-way
relationship between science and technology
(the traditional notion of ‘technology transfer’).
They focused on applying rather thin examples
of information-processing psychology, reducing
the user’s performance and experience to counts
of low-level tokens, ignoring the user’s prior
knowledge, task context, and goals. They also
incorporate rather thin views of technology.
They did not take seriously the fact that design
is a process with a well-established practice that
can only be impacted if it is understood in
intimate detail.
Carroll, Kellogg, and Rosson
1. The Requirements Problem
Efforts to incorporate ethnography into the design process were initially motivated
by the requirements problem. Simply put, the requirements problem is a practical
problem preoccupied by the question: what is to be built? Ethnography was
construed of as method that may help systems developers analyse the work of the
design space and produce an answer to the question by formulating specific design
solutions.1 This chapter explicates the requirements problem, traditional approaches
to its solution, and changes in design practice brought about through the advent of
low-cost computing. These changes saw the emergence of Human-Computer
Interaction (HCI) as a primary point of view for describing, analysing and
representing the design space. The adequacy of HCI approaches to the study of
work is assessed, and found wanting as a result of a cognitive bias which lacks
ecological validity or adequate reference to work as it is carried out by people in the
real world. In concentrating on the cognitive properties of individuals, and through
scientific methods, the real world, real time work of users is ignored in analysis to
the detriment of design. The notion of cooperative work, to which ethnography is
tied in a design context, is articulated as an alternative primary point of view for
analysis.
The Motivation for Ethnography in Design

That the requirements problem may be simply stated does not mean that it is simple
to address. As Brooks (1987) has eloquently described matters here, there is “no
silver bullet” to the problem, no quick and easy fix:
The hardest single part of building a software system is deciding what to build
… No other part of the work so cripples the resulting system if done wrong.
No other part is more difficult to rectify later.
Sommerville and Sawyer (1997) highlight three major points of concern with
respect to the problem. 1) In designing a new system, developers are required to
improve upon the status quo. 2) The parties procuring the system and the parties
who will use the system are rarely the same set of people – there are differing sets
of needs to be considered in design then, such as the administrative and economic
ones of the procurer and the practical ones of the users. And 3) in light of the needs
of a range of stakeholders, including the system procurer and a variety of different
users, some degree of compromise will be essential if common agreement on the
design solution is to be reached.
Sommerville and Sawyer’s remarks indicate that analysis of the design space is
not simply a matter of identifying objective features of the workplace but of
actively formulating solutions that satisfy the practical concerns of a variety of
___________
1
By ‘design space’ is meant the Organization of Work – the institution, company,
factory, department, office, etc., or family of collaborative activities which a system
is being designed for.
1
The Requirements Problem
parties to the work of the domain. It is in this respect that the requirements problem
may be characterised as a ‘wicked’ problem (DeGrace and Stahl 1990). That is, a
problem whose complexity means that it may only be fully appreciated after it has
been solved. There are, then, no a priori solutions to the requirements problem as
each occasion of design is subject to the diverse and wildly contingent needs of a
range of stakeholders. As O’Brien (2000) puts it, the requirements problem is a
wild and wicked problem as
It arises in the social realm and is concerned with trying to improve some
characteristics of how people work together using computer-based support …
[it is not, as such] a neatly formulated, precise [problem], that emerges from a
narrowly-conceived technical agenda. It is instead rooted in the contingencies
of ‘the lived reality of the organizational context -of-use’, and just what that is,
and, furthermore, how we might go about ascertaining that, are not settled
matters.
Only through a course of investigation and analysis does the requirements problem
get settled for practical purposes. The question, of course, is how? In what ways
may the wild and wicked contingencies that characterise the requirements problem
be handled routinely, time after time? Through what methods or working practices
may the analysis of the design space be conducted and design solutions be
formulated and agreed upon by the parties to design time and again, in setting after
setting? Naturally the answer is: in many ways. It is arguably the case, however,
that those ‘many ways’ will be answerable to the established practices that organize
design work at any point in time. Tradition is not easily ignored even in such a
rapidly moving practice as systems design and ways of working have emerged over
time that both shape and drive the collective assessment and adoption of new
approaches and techniques. The following section considers established practice in
design and evolutions in that practice brought about through changing
circumstances of design; changes that have shaped ethnographic involvement in the
design process in contemporary times.
Analysing the Design Space: The Waterfall Model

One answer to the question of systematization (i.e., how may the requirements
problem be handled routinely, time after time?) is provided by the Waterfall Model.
Over the course of the last forty years system design and software development has
evolved from little more than a cottage industry conducted by inspired tinkerers to a
large-scale industrial activity (Buxton 1978; Landes 1972). With industrialization,
the complexity of the design task increased by several orders of magnitude and a
major problem to be contended with was that of organizing and coordinating the
efforts of a large working division of labour in design. One solution to this problem
was to create a fine-grained working division of labour that separated analysis from
programming, for example, and which divided programming into an activity
directed towards the coding of a series of small modules that compose the system as
a whole. Emphasis in such an organization of work was placed on the systematic
development of a product and is represented concretely by the Waterfall Model.
Inspired by general systems theory and developments in planning and logistics, the
2
Waterfall Model provided the first overarching development structure for

organizing large projects with a large staff within the constraints of budget and time
(Agresti 1986). Although the approach to analysis advocated by the Waterfall
Model is hugely problematic today, the model’s impact on design has been
profound, shaping ways of thinking about and doing systems development in
general. The job of analysis as prescribed by the Waterfall Model is briefly outlined
below before moving on to consider the ‘paradigm shift’ that followed in its wake.
At the centre of the analysis phase in the Waterfall Model’s life cycle is the
requirements specification document. Just as the Waterfall Model sets out a series
of predefined steps for systems development as a whole, then so it sets out a series
of predefined steps for analysis which prescribe how to approach the production of
a ‘specifications document’ that articulates a distinct design solution.
q Step one consists of the production of a needs report which specifies general
objectives, requirements, potential costs and the development period of the
potential system.
q Two, a feasibility study which is intended to evaluate whether or not the
identified needs may be satisfied using current technologies and if so, whether
or not the potential system is economically viable within the constraints of
budget and time.
q Three, requirements capture which consists of the detailed specification of
requirements. Requirements capture proceeds through ‘observation’ of the
work-site and its activities, description of existing systems, and discussion
with stakeholders.2
q Four, requirements definition which consists of the construction of a system
model and an abstract description of functionality (i.e., what the system will
do). The functional description generated from the system model is intended to
document requirements from the point of view of users – i.e., from the point of
view of what the system will do in terms of supporting specific work activities.
q Five, requirements specification which consists of a detailed and precise
description of systems functionality. The requirements specification document
often provides for the formulation of a contract between the system developer
and the client for the development of a product version of the system. (COMIC
D2.1)
Steps three to five proceed through iteration and in such a way allow for the
emergence of requirements not specified in the original analysis. Nevertheless,
requirements specification is treated as a vital early stage in the development
process and analysis of the design space is, therefore, confined to the initial stages
of the development effort under the Waterfall Model. That model provides a
methodical way of organizing analysis and developing solutions to the requirements
problem. Through accomplishing the step-wise procedures of analysis, the
requirements specification document comes to spell out in detail what services the
___________
2
‘Observation’ is placed in quotes to indicate that a multiplicity of competing
methods may be used to inspect and analyse work – time and motion studies, task
analysis, business process analysis, various ethnographic approaches, etc.
3
system should deliver and, as such, furnishes an answer to the question: what is to
be built?
A Paradigm Change in Design

Although the Waterfall Model identifies the main logical elements in the design
process – analysis, design (including evaluation), and implementation (including
maintenance) – it was nevertheless subject to critical evaluation from within design.
Dissatisfaction emerged from the changing circumstances of systems development
and usage. The Waterfall Model was considered an effective way of arranging
design work in situations where the computer was at the centre of things, such as
payroll systems, airline reservation systems, or planning systems. As DeGrace and
Stahl (1990) describe matters here,
In these systems, humans serve the machine, providing it with the input it
needs to produce results. But we are now encountering problems of a different
nature where the computer is no longer at the centre of things – the human is –
and the machine is now acting to provide or organize information the humans
need to produce results.
This shift in design, which followed the advent of relatively low-cost yet powerful
third generation computers, saw demand for the widespread deployment of IT in a
diverse array of human situations. Along with that shift came efforts to devise
models of design better suited to identifying the needs of the human being. A host
of new models emerged such as the Spiral Model (Boehm 1988), the Whirlpool
Model (DeGrace and Stahl 1990), and Evolutionary Prototyping (Budde et al.
1992).
The common feature of these models, and others besides, was the effort to
develop systematic ways of identifying human needs in what is essentially a
situation of uncertainty. The essential uncertainty of the matter lies in the fact that
there are no true or false solutions to the wild and wicked problems occasioned by
the needs of human beings, only good or bad ones. In order to devise a good
solution, it was felt that design would have to engage in closer cooperation with
users. Each of these approaches attempts to engage with users and their
circumstances of work to a greater extent in a systematic effort to design systems
that are more responsive to human situations and needs. The problem here,
however, and it is again one recognised from within design, is that analysis of the
design space and user needs was (until the late 80’s at least) underpinned by formal
methods or structured design methodologies which impose certain limitations on
the understanding of human situations and needs. As Mogensen (1994) puts it, for
example,
The analyses of Yourdon, Jackson, Coad and Yourdon [etc.] all focus on
supporting the implementation of the systems in [their] respective
programming languages. They focus less on understanding how work is
actually accomplished. They all take it for granted that the analysis should
support a subsequent design and implementation process. This pre-
understanding leads largely to a view of practice as seen from the computer
4
and its capabilities, and practice is largely understood in a language close to

programming languages.
The problem, then, is that the understandings of work generated through the use of
formal design methods tend to be very abstract, focusing more on what should be
done rather than on what is actually done in a particular work setting.
In order to deal with the problems occasioned by the use of structured or
formal methodologies it was realized that efforts to be more responsive to human
situations and needs would have to be extended beyond the concerns of the
prevailing engineering mentality. Dividing design activities, particularly analysis of
user needs, into increasingly finer elements and components, no matter how
iteratively, would not do insofar as such approaches failed to get to grips with what
is actually done in the first place. New methods of analysis were required; ones,
which were sensitive to human situations and needs, yet complemented formal
methods and enhanced their efficacy. Widespread recognition of this occasioned
what has been called a ‘paradigm change’ in design (Floyd 1987).
Christiane Floyd uses the notion of a paradigm in T.S. Kuhn’s sense as a
specific programme of research that provides
a frame of reference suggesting questions we ask, quality considerations we
aim for, and guidelines for interpreting results in our scientific and technical
work. (Floyd 1987)
Examples of a paradigm are provided by the Ptolemaic world-view, which was
replaced by a new paradigm as a consequence of the Copernican Revolution (Kuhn
1962). Newtonian mechanics provides another example, in contrast to the
contemporary view of physics engendered by Einstein and others. Floyd suggests
that there is an important point to be appreciated in the lessons of paradigm changes
in physics. Whereas some paradigms are completely abandoned in the emergence of
and shift to another (such as the Ptolemaic), others (such as Newtonian mechanics)
are not abandoned – they remain important within their ‘scope of validity’. Floyd’s
notion of a paradigm change in design is one that works at this level. The classical
order of work laid down by the Waterfall Model – the product-oriented perspective
in Floyd’s terminology – remains important within its scope of validity. Structured
methodologies are necessary to design and despite criticism, there was and is no
question of dropping the product-oriented perspective. The issue of a paradigm
change in design is not one of doing away with the product-oriented perspective
then, but one to do with whether or not that paradigm should be the ‘ruling
paradigm’ in design or whether it should be subordinate to an alternate primary
perspective; namely, the process-oriented perspective?
By way of an answer, and elucidation of the paradigm change, Floyd notes
that:
The product-oriented perspective regards software as a product standing on its
own, consisting of a set of programs and related defining texts. In doing so,
the product-oriented perspective abstracts from the characteristics of the given
base machine and considers the usage context of the product to be fixed and
5
well understood, thus allowing software requirements to be determined in

advance.
From the process-oriented perspective, the actual product is perceived as
emerging from the totality of interleaved processes of analysis, design,
implementation, evaluation, and feedback, carried out by different groups of
people involved in systems development in various roles. Both the
functionality of the product and its quality as experienced by the users are held
to be deeply influenced by the way in which these processes are carried out.
The product-oriented perspective ignores, then, or is insensitive to, the interactional
dynamics of analysis and design. That is, to the human processes of learning and
communication through which design solutions are produced in the collaborations
and cooperative work of the parties to systems development. It is this ignorance that
underpinned the call for a paradigm change in design as design solutions are and
have always been formulated in the cooperative work of design participants. The
product-oriented perspective ignores the actual ‘lived work’ of design however, and
with it the needs of real life development. On Floyd’s view then, there was an
identifiable need for a richer, process-oriented perspective as a primary point of
view in design that would provide a new analytic framework in which to embed the
treatment of product aspects. That framework replaces classical concerns with the
computer system as a formal mathematical object with a concern to see, and
understand, the computer as a system-based tool in the working environment or
workaday world.
To use Floyd’s terminology, the workaday world consisting of people at work
together constitutes the ‘referent system’. The set of programs and interfaces
developed to support the work of the referent system constitute the ‘software
system’. The shift in emphasis from the system as a formal mathematical object to
the system as a work tool radically respecifies the notion of, and importance of
understanding, the referent system in design. On a product-oriented view, efforts to
make the software system into a tool more responsive to the work environment
consist of the late addition of ‘syntactic sugar’. This is intended to improve user
interaction with the software system by developing syntactical procedures that
make it easier for the user to express the given functionality. No functionality is
added here, only alternate, more ‘user friendly’ methods of realizing it. This view
contrasts with the process-oriented one where efforts to make the software system
into a tool more responsive to workaday activities consist of developing methods
which promote an awareness of work and promote cooperation with users as part of
a mutual learning process (see Table 1). Analysis of the design space ceases, as
such, to be an up-front documentary activity and becomes part of a dynamic
ongoing process whereby developers come to learn from users of the human
situation they are developing a system for and, at the same time, users come to learn
of and inform the design of the system-of-work being developed.
The shift from formal mathematical object to socio-technical system of work
constitutes the paradigm change in systems design. It is a shift that displaces the
product-oriented view (which reduces the workaday world to a mechanistic
arrangement of information processes), but does not dispense with that view. It does
6
not dispense with that view for as Floyd reminds us it is necessary at some point in
design to take reductionist steps,
in order to specify a microworld suitable for modelling. The chances are,
however, that when focusing on the meaningful use of the software system as
a tool in its usage environment, we may make different choices in selecting
objects, attributes and actions to be included in this microworld, and we may
allow for the combination of individual functions of the software system in a
more flexible manner. Rather than making a given software system more user-
friendly, we will arrive at a software system with different scope, functionality
and possibilities for human intervention.
In subordinating the product-oriented view to the process-oriented view, the abiding
question to be answered was, and is, one concerned with how design might realize
these new possibilities? What systematic - i.e., widely usable and reproducible -
methods of analysing the referent system and cooperating with users may be
developed to support the design of socio -technical systems of work?
Table 1. Product and process views of the referent system (Floyd 1987).
Product-oriented view of the Process-oriented view of the

referent system referent system
1. The referent system is chosen with a 1. The referent system is chosen with a
view towards developing the software view towards designing the work
system. processes to be supported by the
software system.
2. The referent system is described in 2. The referent system is described in
terms of information processing. terms of work and its processes.
3. The referent system is considered to 3. The referent system is considered to
be essentially static, having two states be dynamic and evolving throughout
(before and after the software system is development.
introduced).
4. The software developer becomes a
4. The software developer is outside part of the referent system in the
the referent system; development and process of coming to understand the use
use are considered separately. context (the work environment).
5. The software system is produc- 5. The software system is produc-
tionally closed; it is viewed as coherent tionally open; the software system is a
set of programs based on a complete version subject to revision in coming to
understanding of the referent system. understand the use context.
6. The interaction between software 6. The interaction between software and
and its environment is predefined as its environment is tailored by users to
part of the development. the actual needs arising from their
work.
7
A Primary Analytic Point of View for Design:

Enter HCI
The paradigm change in systems design saw the emergence of Human-Computer
Interaction (HCI) as a primary analytic point of view. While definitions of HCI are
hard to formulate (as there are so many and it is an evolving field), the primary
objective of HCI in its origins at least was to support a better ‘cognitive coupling’
between the human and the computer in the effort to meet user needs (Bannon
1991). Of particular concern was the need to meet the demands of users who had
little or no specialist computer knowledge – the ordinary man or woman in the
street or on the shopfloor as it were. The advent of third generation computers saw
the emergence of the personal computer and a growing number of users who were
interested in using the PC as a tool for conducting their everyday affairs. The
computer had to serve users in completing their primary tasks such as document
production, accounting, auditing, and the like. With this trend came a demand to
design computers that were easy to use, intuitive to understand, and simple to learn.
As a feature of the paradigm change, computer manufacturers saw a market
advantage in meeting user demands and HCI became a primary analytic point of
view which brought a whole new set of ‘human factors’ considerations to systems
design.
The most important of the human factors brought into consideration was that
of communication. HCI practitioners argued that interaction between people and
computers was not of the same order as previous human-machine interaction.
Mechanical devices were characterised by a limited range of tasks to be
accomplished through a limited range of means and the person was, as such,
construed of as an operator of the machine. This was not seen to be the case with
people and computers however, as it was argued that the computer user is not an
operator of the machine but instead, communicates with it in order to get his or her
tasks accomplished (Card et al. 1983). On this reading, the computer heralded an
entirely new domain of human-machine interaction: human-computer
communication. The task of HCI in meeting the needs of ordinary users was, then,
one of developing means of supporting communication between people and the
computer.
The primary means whereby HCI could effect the cognitive coupling of users
and computers was construed of as the ‘interface’:
Interface: a) the place at which independent systems meet and act upon or
communicate with each other, b) the means by which interaction or
communication is effected at an interface. (Grudin 1990a)
HCI instantiated an analytic separation between the interface and the underlying
computer, such that the interface became a separate entity circumscribing HCI’s
distinct focus and domain of research expertise (Pycock 1999). The point and
purpose of this separation was to make the affordances provided by the underlying
computer system plainly visible and available to users, thus supporting human-
computer communication (Preece et al. 1999). By ‘affordances’ is meant the
properties of an object and what sort of operations may be performed through the
8
manipulation of those properties (Norman 1992). The basic idea here is that the
technical workings of the computer should disappear from view – much as the
mechanics of steering are invisible to the driver of a car, for example.
The separation of the interface from the underlying technicalities of the
computer was based on the assumption that users conduct their work through the
use of conceptual models of the referent system, which articulate the goals that they
wish to achieve and the actions they have to undertake in order to achieve them
(Norman 1986). Making the affordances of the underlying computer visible and
available to users thus requires that the interface be designed in such a way that it
bridges the gulf between the user’s conceptual model of the referent system on the
one hand and the designer’s model (i.e., the system model) of the referent system
on the other. Just how to effect a bridge between the user’s model and the
designer’s model was the primary research challenge for HCI. A challenge that
traded on foundational presuppositions regarding both the user and the interface,
each of which shapes analysis of the design space and user needs.
The User and the Interface in HCI

HCI marginally predates the paradigm change in design and as a consequence, one
might argue that a certain degree of baggage was brought to the development
exercise. One of the most important pieces of HCI baggage is cognitive theory.
Cognitive theory offers various foundational models or formats for analysing the
user, which HCI practitioners suggested may be employed to construct a bridge
between the user’s model and the designer’s model. At the time of its emergence in
design, the primary analytic format at work construed of the user as an ‘information
processor’. On this view, everything that a person senses, be it through sight, touch,
smell, etc., is taken to consist of information that the mind processes. The
information-processing model basically proposes that information enters and exits
the mind through a series of well-ordered processing stages (Barber 1988). The
mind on this reading, then, is in effect a unidirectional and sequentially ordered
input-output device. Figure 1 represents the basic arrangement of that device.
Input / Encoding Com- Response Response Output /

stimuli parison selection execution Response
Figure 1. Human information processing stages (Preece et al. 1999).

© 1994 The Open University, reprinted by permission of Pearson Education Limited.
According to this model of the user, information constitutes an input that is

encoded into some form of internal representation. That representation is then
compared with other representations stored in the user’s memory and, given those
memories, an appropriate response to the encoded input is selected. The selected
response is then processed in terms of actions to be taken to execute that response.
As Preece et al. (1999) describe matters,
To illustrate the relationship between the different stages of information-
processing, consider the sequencing involved in sending mail. First, letters are
posted in a mailbox. Next, a postman empties the letters from the mailbox and
9
takes them to the central sorting office. The letters are then sorted according to
area and sent via rail, road, air or ship to their destination. On reaching their
destination, the letters are further sorted into particular areas and then into
street locations and so on. A major aspect of an information-processing
analysis, likewise, is tracing the mental operations and their outcomes for a
particular cognitive task.
Generic cognitive formats occupy a prime position in HCI analysis. Over the
course of research they have, quite naturally, developed and new analytic formats
have evolved. Underlying shifts in the philosophy of mind, which first identified the
mind with the brain (Place 1994) and then eliminated the mind (Churchland and
Sejnowski 1994), have filtered through to applied cognitive theory and resulted in
the emergence of parallel distributed processing (Rumelhart and McClelland 1986).
Parallel distributed processing adopts a brain metaphor where cognition is
represented at the level of neural networks and interconnected nodes. Information
processes are thus construed of as the product of activations of the nodes in the
network and the connections established between the networks, in contrast to being
linear and sequentially organized arrangements (Preece et al. 1999).
Figure 2. Parallel distributed processing: a connectionist network (Churchland & Sejnowski

1994). © 1994 Blackwell Publishers. Reprinted by permission.
Abstract as the above schema is, the reader may be able to appreciate that with such
a model it becomes possible for a multiplicity of information processes to be
running in parallel as a host of different connections are established and different
networks are engaged. On this model, information processing has a very dynamic
structure and the task for HCI became one identifying the mental models that
compose that structure (Preece et al. 1999).
In employing the notion of mental models, HCI assumes that users carry
conceptual models of the referent system, and with it their work, around in their
heads. As Norman puts it, people carry around with them mental models of
“themselves, others, the environment, and the things with which they interact.
10
People form mental models through experience, training and instruction” (Norman
1988). Mental models are construed of as cognitive structures consisting of
analogical and propositional representations of the things that comprise the person’s
workaday life – structures which comprise the nodes and networks that make up the
neural net. The world of things human and physical is mapped onto the neural net
through the production of mental models formed through experience then. In being
structured by the workaday world, mental models serve a pragmatic function, being
drawn upon by the person in order to make sense of the situations and practical
activities they are engaged in and to determine appropriate responses. In their
pragmatic capacity, mental models have ‘task-action functions’ mapped onto them
that represent the task to be done here and now and the actions to be taken in order
to accomplish that task. Take the task of driving a car, for example. In utilising a
mental model of driving, the person draws upon the action functions mapped onto
that particular model – such as turning the ignition key and starting car, pressing the
clutch and putting the car in gear, releasing the hand brake, checking the mirrors
and accelerating, etc. (Preece et al. 1999).
Analytic format in hand, the scene is set for the HCI practitioner to engage in
design. His or her task is to map the mental model of the referent system employed
by the user onto the designer’s model of the referent system through the design of a
unifying conceptual model embodied in the interface. As Norman (1988) puts it,
The problem is to design the system so that, first, it follows a consistent,
coherent conceptualisation – a design model – and, second, so that the user
can develop a mental model of that system – a user model – consistent with
the design model.
The unifying conceptual model maps the user’s model onto the design model
through the design of the interface, purportedly making the computer more
accessible to the user. The interface for HCI is, then, the computer’s interface to the
user and not the user’s interface to the computer (see Figure 3).3 Rhetoric aside, the
user’s mental model of the referent system is subservient to the designer’s model
(i.e., the system model) of the referent system and not vice versa. In this respect,
HCI treats the interface as a technical artefact which mediates between two
different kinds of information process: those in users heads that reference their
work and those designed into the machine - and in that, the appeal of HCI to the
engineering mentality is not at all difficult to appreciate. Seen and treated from a
technical perspective, the interface may be identified as a separate module of
software code within an overall system design architecture. A module dedicated to
managing the ‘software-control dialogue’ between the system and the user. In order
to specify the software-control dialogue and configure the relationship between the
user and the computer, the HCI practitioner has first to map the mental model of the
referent system employed by the user. The question, of course, is how? Or rather,
how are the design space and commensurate user needs to be described and
analysed?
___________
3
The distinction is not merely a semantic one and its importance will be addressed
shortly.
11
A Computer
Other input Keyboard, Visual Other out -

devices mouse display put devices
A
User
Figure 3. The Interface in HCI (Grudin 1990a).

© 1990 ACM, Inc. Reprinted by permission.
Mapping Mental Models of the Referent System

HCI is a project dedicated to developing a ‘science of design’ (Simon 1969).
Working under the auspices of communication, that science is expressly concerned
to configure the inner operations of a computer system with the outer task
environment of the user through the design of the interface (Norman 1986). In order
to effect that match, HCI needs to identify and map the user’s mental model of the
task environment, the referent system, or the workaday world. In order to do this,
HCI invokes scientific methodology on the premiss that such practices of work will
guarantee the validity of HCI findings. That methodology works at two levels: 1)
through the theoretical construction of analytic formats (as above), and 2) through
the application of those formats to particular real world cases through mapping
procedures or methods.
Although there are many different mapping procedures in HCI, task analysis
is the most prominent. The objective of various methods of task analysis is to model
the goals, tasks and how-to-do-it knowledge that comprise discrete information
processes. HCI defines a goal as a state of affairs the user wishes to achieve, such as
sending a message to a colleague. A goal is achieved through the use of some
instrument or tool - with regard to the message, through use of pen and paper, a
typewriter, or email, for example. Once a tool has been selected, the user must
accomplish the tool-specific tasks required to realize the goal through the selected
tool. In electing to send the message via email, for example, the user must start the
application, open a new message, write the message, and forward it to the recipient.
A task, then, is understood as an equipmentally-affiliated structure of activities that
the user must accomplish in order to realize the goal. The structure of the task is
understood as the sequential order of work activities to be accomplished. That
sequential structure may be mapped by further decomposing it into a set of sub-
12
goals and sub-tasks as defined by the individual activities comprising the task
structure – e.g. start the application, open a new message, write the message, and
forward to the recipient. Each sub-goal and sub-task is also decomposed into a set
of distinct operations and methods, or actions performed on objects in order to
accomplish the sub-task and realize the sub-goal.
When starting the email application, for example, the user must move the
cursor by moving the mouse over to the start menu icon, click on the icon, move the
cursor up to the programmes menu icon, click on the icon, browse the menu, move
the mouse to the email programme shortcut, and click on the shortcut; when the
application appears on the desktop, the user must then enter his or password in the
active window (see Figure 4). In this way, task analysis maps the workaday
activities comprising the referent system by decomposing that system and its
activities into a hierarchy of mental models organized in terms of the analytic
format employed. Each mental model is therefore seen to be composed of distinct
information processes each of which may be decomposed into its constituent
elements and each of which combines with other processes to create a coherent
whole, such as sending an email and receiving, replying, or forwarding an email,
for example (Preece et al. 1999).4
Goal: Send message Email: Tasks
Start Open new Forward to

email message recipient
Select tool: letter.

typewriter, email
Start menu Programme Email

menu shortcut
Move cursor Move cursor Browse

on to icon up menu programme
list
Click on icon Click on Click on

Programme email
icon shortcut
Figure 4. Task Analysis (Preece et al. 1999).

___________
4
Just how the relationship between mapping procedures and analytic formats is
configured to produce findings will be addressed in some detail in due course.
Before moving on to this complex matter, the point here is to appreciate basic
practices of description and analysis. That the referent system/design space is often
described in terms of abstract methods and analysed in terms of a priori
theoretically constructed formats.
13
In order to configure the relationship between the referent system and a new
computer system, the HCI practitioner must map the hierarchy of information
processes elaborated by the user’s mental model in a way that affords the
identification of system requirements. Once again, there are many ways in which
representation may be accomplished, however, many HCI methods share the
common feature of being graphical. A primary graphical method of representing
goal-task structures and associated information process hierarchies in HCI is
provided by dataflow mapping, a technique like many others which derives from
structured design methodology (e.g. DeMarco 1979). Dataflow mapping represents
the production and changing state of information processes as such things are
understood by cognitive science. Thus, dataflow models map inputs, processes, data
stores, and outputs. Take, for example, an order processing system. A customer
sends in an order for some product (input). The customer service agent checks the
order system to see if the product is available (process). In checking the system the
agent manipulates a certain set of product data (data store). If the product is
available, the agent issues a delivery note (output). Each part of the overall order
process may be decomposed into fine-grained dataflow maps. So, for example, the
task of sending in an order may be decomposed into a set of inputs, processes, data
stores, and outputs such as address and credit details (input), checking said details
(process) against company records (data store), and credit clearance (output). Thus,
in producing dataflow maps, the HCI practitioner specifies functional requirements
for the system as a whole and the sub-systems composing it. Requirements, for
example, that the order system enable the customer service agent to check the
customer, check the product, and issue the delivery note (Preece et al. 1999).
Customer Order
Credit clearance Product unavailable
Check Check
Stock Dept.
order product
No credit clearance Product unavailable
Issue
Supervisor Deliveries
delivery
note
Requirements on an order system control dialogue
Figure 5. Dataflow: Information Processing in an Order Purchase (Preece et al. 1999).

14
The Referent System in HCI

Despite placing analytic emphasis on sequential orders of equipmentally-affiliated
work activities, HCI evidently fails to come to terms with the referent system.
Instead, and as the descriptive, analytic and representational devices employed by
HCI practitioners make readily apparent, adequate understandings of the workaday
world are subordinate to the engineering mentality. HCI fails to deliver an alternate
and primary point of view for design for the simple and patently evident reason (as
can be clearly seen in Figures 1, 2, 4 and 5) that there are no people at work
together in such formats nor is that phenomenon made available by such methods,
only the firing of synapses, abstract task structures, and information processes are
offered. Rather than make the workaday world available to design reasoning, HCI
has only succeeded in its continued concealment as a result of the inappropriate use
of scientific methods and an inbuilt cognitive bias.
To be fair, Figure 5, which maps the process relations between a number of
people (customer, agent, supervisor, and other personnel), might be seen to
represent an attempt to deal with the referent system under the auspices of
distributed cognition (Hutchins 1994). Distributed cognition respecifies the notion
of cognitive phenomena as individuated phenomena to one that sees cognitive
phenomena as distributed across individuals, thus dissolving the traditional
dichotomy made between the individual and society. Nonetheless, the same analytic
formats maintain and are extended to a multiplicity of actors. Thus, the cognitive
processes said to operate inside the individual’s head, and methods for their
description, analysis and representation, are applied to the interaction that takes
place between human actors that are party to workaday activities. Cognitive theory
is rescued then, in recasting cognitive processes as discrete socially distributed
information processes that make up the workaday world, which it is HCI’s job to
specify. All very appealing to the engineering mentality, and fundamentally flawed
from a practical point of view:
Despite years of research collaboration, HCI’s impact on industrial designers’
practice is at most the occasional reference to guidelines. Task analysis,
organizational modelling and socio-technical methods languish in academic
closets. It is germane to ask why? (Sutcliffe 1992)
Some Technical Troubles with HCI

According to the theory of distributed cognition, cognition consists of socially
distributed information processes which may be mapped and used to inform the
design of socio-technical systems of work (Rogers 1997). The contention here is
that distributed cognition, like cognitive theory before it, is fundamentally flawed.5
And that persistence with such formats and methods will not bring the design effort
___________
5
Space does not allow for a thoroughgoing treatment of the deficiencies of
cognitive theory. For that see Button et al. (1995). The purpose here is only to
illuminate the irremediable inadequacies of cognitive theory when applied to the
analysis of social settings - to an Organization of Work, for example.
15
any closer to the workaday world. By way of example, and elucidation of an

alternate primary point of view for analysing the design space, the concept of
‘organizational memory’ is considered below. The concept emerged in response to
widespread downsizing brought about through economic recession in the early to
mid 1990’s. Downsizing saw the loss of the oldest and most knowledgeable
workers and brought with it an organizational risk of dysfunction. The problem and
its solution was seen as one of capturing and preserving the organizational
knowledge of workers.
Or, to put it more brutally, “how can we sack Mavis (as the stereotypical
older, female worker who ‘knew how to get things done’) and keep her
brain?” (Hughes et al. 1996)
Solutions to the problem advocated the development of IT systems that could
capture and preserve workers how-to-do-it knowledge: organizational memory
systems in short.
The design of such systems was predicated on cognitive presuppositions which
construed of the Organization of Work (this company, institution, office, etc.) as a
container of a heterogeneous yet interrelated set of information processes that are
stored in discrete locations and utilised as and when required in the making of
decisions relevant to the accomplishment of the Organization’s daily work.
Cognition on this view, and in other words, is seen to be distributed amongst the
parts of the Organization, including its staff. The design of organizational memory
systems would, therefore, consist of the design of distributed storage and retrieval
processes that would make the organizational knowledge necessary to competent
decision-making widely available. The task for HCI would be one of identifying the
locus of retention and mapping the retention processes through which information
comes to be stored by the Organization’s staff in the course of their work.
Ultimately on this view, memory is seen as essentially static – being little more than
a repository or bin - and decision-making but a matter of consulting the appropriate
how-to-do-it memory store (Walsh and Ungson 1991).
An alternative point of view suggests that memory or, more precisely,
remembering is a defeasible achievement. Organizational memory could as such
and instead be seen as a collection of socially organized activities done by persons
located in Organizations of Work (Hughes et al. 1996). On this view, remembering
is something performed purposefully by people in the course of getting their
workaday activities done. The purposeful character of remembering has radical
implications for the design of IT systems, directing attention to the ways in which
organizational remembering is embodied in practice.
Organizational Memory in Action (CAMPARI & ICE)
A long-term ethnographic study of the workaday activities at a major clearing bank
in the UK uncovered a host of artefacts, some of which might be characterised as
organizational memory devices. Manuals, for example, such as the Action File and
Action Directory, which contained formal descriptions of every bank product and
flowcharts of every bank procedure, were available in every unit. Each employee
had a copy of the bank’s ‘bible’ – the PIF (Products In Focus). Another
institutionalised organizational memory device was the lending mnemonic
16
CAMPARI & ICE. This particular memory device was intended to guide lending
decisions by highlighting a number of important factors to be considered in the
decision-making process: Character, Ability, Means, Purpose, Amount,
Repayment, Insurance; and Interest, Commission, Extras. With the exception of a
single page of the PIF, which contained current bank interest rates, these and other
organizational memory devices were rarely used as intended, however. Use of the
mnemonic CAMPARI & ICE serves to elucidate the matter and implications for the
study of the referent system more generally.
In practice the lending mnemonic CAMPARI & ICE was not utilised and
followed in a step-wise fashion as a procedure for making a lending decision. Thus,
CAMPARI & ICE did not characterise a decision-making process. This is not to say
that the mnemonic was not used, but insofar as it was then it was more often than
not used retrospectively after the event in order to assemble an institutionally
defensible case supporting a lending decision. The post hoc use of the mnemonic as
a formal accounting device is not to say that the mnemonic was disregarded in the
making of lending decisions:
(Fieldnote extract) I’ve been to see some doctors who have a business account
with the bank. They asked for an additional £6000 for a computer. Chris was
asked to sanction the purchase but it’s outside her discretionary power. The
business is entirely satisfactory – GPs with a turnover of £300k, profit £150k.
It’s not reasonable to tell them to wait for such a paltry sum.
In practice, the general spirit and not the letter of CAMPARI & ICE is attended to -
the spirit of the matter being one of not accruing bad debts. As the extract makes
clear, the mnemonic is not treated as laying out a process to be accomplished in
order to avoid accruing bad debts, but as a general rule to be complied with.
Compliance with the spirit of the rule is key. Compliance should not be thought of
as a matter of mindlessly applying the mnemonic to particular cases but, as the
extract indicates, of applying the general spirit of the rule the mnemonic embodies
through the exercise of skill and judgement. Notably, the exercise of skill and
judgement relies on the decision-maker’s knowledge of the client, of the client’s
financial circumstances, of their prospects, and a host of other local and contextual
factors – none of which are covered by the mnemonic and all of which are
constituted in the decision-maker’s daily work, which systems are directed towards
supporting.
The embodied use of the mnemonic CAMPARI & ICE radically respecifies
the concept of organizational memory as a practical accomplishment. In practice,
organizational memory devices are applied - and applied in unexpected ways.
Rather than laying out processes to be accomplished, organizational memory
devices are instead used in the course of accomplishing a host of contingent
workaday activities not specified by the device: as a means of formally accounting
for decisions made and as general rules to be complied with in making decisions,
for example. Notably, and this is the nub of the matter, in their use organizational
memory devices are not organized in terms of the device (as a how-to-do-it process
of work to be accomplished, for example) but in terms of local factors which are
nowhere specified by the device. So what? Could these local factors not be
described in terms of socially distributed information processes?
17
A simple answer to the question is yes, of course local factors could be

described in terms of socially distributed information processes. To do so, however,
would be to miss the actual work whereby such processes are produced by parties to
the work - work in which systems will be embedded and used. Information
processes of whatever kind are, at best, second order abstractions. There is no
problem with that in itself – systems models must after all be built (though design
does not need cognitive theory to do that; plenty of alternate approaches offer
process views on the workplace). The problem, however, occurs when second order
abstractions are employed as primary analytic points of view on the referent system.
As primary points of view, information-processing perspectives reify the workaday
world (Suchman 1995). That reification consists in the substitution of actual work
as it is observably and reportably performed and organized in situ for abstracted
information-processing models.
Socially distributed information processes, like all human-based processes of
whatever kind, are rooted in and produced through the local work of parties to the
daily activities that comprise the workaday world. Whatever else systems are, they
are inevitably embedded in local work, which furnishes practical situations,
circumstances, and contexts of use. With its exclusive focus on second order
abstractions – in contrast to the actual work whereby information processes are
produced – the practical situations, circumstances, and contexts of use that
comprise the workaday world are not made available to design reasoning by
cognitive science. Indeed, wherever second order abstractions are offered as a
primary means of analysing the design space, they eclipse the user and, more
importantly, the work users engage in that requires support. Despite a large
academic literature, HCI was a discipline in crisis and systems designers recognised
a pressing need for an alternate analytic point of view on the referent system
(Goguen 1993).
From Human Factors to Human Actors: Exit HCI

In reviewing the status of HCI, Liam Bannon has remarked that HCI’s failings
emerge in significant respect from cognitive science’s taken for granted orientation
to users and its primary means of analysing them:
Part of the problem resides in an implicit view of ordinary people which, if
surfaced, would seem to treat people as, at worst, idiots who must be shielded
from the machine, or as, at best, simple sets of elementary processes or
‘factors’ that can be studied in isolation in the laboratory. (Bannon 1991)
Cognitive science’s orientation to users obscures essential features of the user’s
environment – of the referent system, the workaday world and the expertise, skills,
and organizational constraints that comprise it. This situation is further
compounded by cognitive science’s methods of analysing users. In an attempt to
guarantee the validity of its findings, cognitive theory has emphasised the need for
controlled experiments in laboratory settings and the construction of generic
analytic formats accounting for observed events. Little consideration was (and is)
paid to the appropriateness of using the methods of natural science to study human
beings. Instead, cognitive science assumes that the construction of generic analytic
18
formats and the use of scientific methods will provide a solid foundation for
systems design. Curiously, and as Sutcliffe (1992) points out, such advances have
not been forthcoming to date, nor should anyone other than the cognitive scientist
expect them to be.
Following Wittgenstein, the late Norman Malcolm (1995) goes so far as to
point out why cognitive science has failed to deliver on its promise in reminding us
that cognitive phenomenon are not primarily located ‘in-the-head’ (whether
construed of as the mind or the brain) but are, primarily, constituent features of the
settings, situations and events they make visible. For example:
Suppose that in conversation with a group of people I make a certain remark.
Later, one of those present says to me: “Were you thinking when you made
that remark?” I ask: “What do you mean?” He says: “Well, what you said was
rather disparaging of Italians. Had you forgotten that Mr. A., who was present
in the group, is Italian?” I exclaim: “Oh, I had forgotten! I wasn’t thinking
when I said that. I certainly did not want to offend Mr. A.”
As the example demonstrates, ‘thinking’ (or ‘not thinking’), like any other
cognitive phenomenon, is, quite observably, a constituent feature of the social
settings, situations, and events it makes visible. Consequently, and on this reading,
notions of the mind or brain as the locus of cognitive phenomena are understood as
abstract analytic constructions in lay and professional reasoning alike; constructs
derived from and based on a ‘one-sided diet of examples’ that portray cognitive
phenomena as ‘inner’ phenomena in contrast to observable and reportable features
of the myriad things that the members of society ordinarily say and do together
(Wittgenstein 1992). In the context of ordinary sayings and doings, ‘thinking’,
‘remembering’, ‘imagining’, etc., are circumstantially relevant expressions and, as
such, part and parcel of the locally and naturally organized courses of practical
action and practical reasoning they elaborate (Coulter 1999). Cognitive phenomena
are not, then, primary features of some introspectively observable inner realm or
course of events. On the contrary, and as Coulter (1991) puts it, cognitive
phenomena are ‘praxiological’ phenomena made available through situated action
and social praxis. Malcolm (1995) makes the point concisely.
Consider the analogy of calculating (adding, multiplying, dividing). One can
multiply aloud, on paper, or in one’s head. If you multiply aloud that is not
called multiplying “in your head”. Suppose it were said: “Whenever people
multiply they multiply in their heads”. A strange contention! The words,
“multiplying in one’s head”, could not have their ordinary meaning here. For
that implies that the multiplying was not aloud or in writing. Furthermore, the
ability to multiply in one’s head logically presupposes the ability to multiply
aloud or in writing. And that is necessarily so. For a person who was not able
to execute any processes of multiplication, aloud, in writing, or in other
outward signs, could not be said to be multiplying in his head, even if he was
able to produce the right answer to multiplication problems! The ability to
multiply in one’s head is necessarily secondary to, derivative of, the ability to
display multiplying in physically perceptible signs and actions.
19
Isn’t there a similarity here between calculating and thinking? A child who
had never manifested in words, gestures, or play the working out of simple
problems could not be said to work them out “in his mind”, anymore than he
could be said to know “in his mind” the names of colours, if he was unable to
say their names, or point to or fetch the right colours when their names were
called out. Thinking in one’s mind (silent thinking, pausing to think) is not the
most fundamental form of thinking, but instead presupposes thinking in play,
work, or words.
On this reading, the analytic primacy of a publicly unobservable inner world of
mental phenomena is displaced and our attention is drawn instead to the observable
and reportable activities that comprise the workaday life of people. As Garfinkel
puts it (in Coulter 1990), “there is no reason to look under the skull since nothing of
interest is to be found there but brains” - and brains, of course, do not think, persons
do (or don’t), observably and reportably so in the course of accomplishing their
workaday affairs.6 Thinking (etc.) is not something separate from those activities
but, as with organizational memory, identical to workaday activities and organized
in terms of their local accomplishment. A fortiori, until cognitive science comes to
terms with the praxiological foundations of cognitive phenomenon its teachings
might well be expected to continue to languish in academic closets.
It might be said that HCI’s problems have emerged in failing to see users as
persons who regulate and coordinate their own activities. As such, HCI fails to see
users as competent practitioners working in concert with other competent
practitioners. Theoretical formats and methods developed in laboratory settings can
do no other than neglect the embedded character of the practitioner’s concerted
competence in the real world; especially the skills and working relations necessary
to the performance and coordination of discrete activities of work. No doubt a great
many more criticisms could be levelled at HCI, but of more importance here is the
rationale behind such criticisms. Specifically, the implications for systems design in
general that follow in the wake of the recognition that HCI suffers from a lack of
‘ecological validity’ (Thomas and Kellogg 1989). That is, a lack of adequate
reference to real world contexts of use and to the skilful ways in which practitioners
perform and coordinate their workaday activities in the actual flow of doing them.
Recognition of HCI’s lack of reference to the workaday world has prompted
reconceptualisation of the user and the interface and seen design turn away from the
cognitive to the social.
___________
6
This is not to deny that one needs a brain in order to think (etc.). It is to point out
the error of equating the brain with thought (etc.); of saying that thinking is a
property of the brain rather than a property of the human being, who possesses a
brain. Across recorded human history we have yet to encounter a brain that thinks,
and we would find it very strange, indeed utterly alien and incomprehensible, if we
actually did. Nonetheless, we see people thinking (etc.) all around us, all of the
time. Mental phenomena are located in our practical actions, observably and
reportably so.
20
Reconceptualising the User

Grint and Woolgar’s (1997) study of work in a commercial design company is often
cited as a paradigm case in the effort to reconceptualise the user. That study
revealed that design practitioners had little (indeed no) interest in the conceptions of
users offered by HCI and instead employed a stock of company knowledge about
users in the development of new technologies. Design practitioners employed a
non-scientific stock of knowledge about who users are, what their needs might be,
what they might expect, and the rest. Through this knowledge, the relationship
between the user and the machine was configured for practical purposes of design
and the status of that configuration was confirmed and-or amended through
usability trials. Although a great deal of attention has been paid to Grint and
Woolgar’s study, it is not given its usual attention here as their professional concern
with textual metaphors in description and analysis overlook a deeper phenomenon;
namely, the ways in which the stock of company knowledge consists of stocks of
commonsense knowledge about computer users. Of particular concern here are the
ways in which commonsense knowledge is employed to analyse the design space
and user needs (Sharrock and Anderson 1994).
Like Grint and Woolgar, Sharrock and Anderson studied a commercial design
company. Instead of placing emphasis on textual metaphors, however, they elected
instead to address the ‘internal configuration’ of design work – i.e., the local work
whereby designers construct and organize the design process, and the ways in
which they configure the user of the machine and machine requirements in doing
that. Drawing on Herbert Simon’s work (Simon 1984), Sharrock and Anderson
suggest that the workaday character of design might indeed be construed as one
oriented to the solution of ‘ill-structured problems’. What this means is that for any
particular design problem – the design of an order processing system, say - a
veritable multiplicity of solutions exist. The design problem is ill-structured, then,
in that there is no definitive solution yet some solution is nevertheless found.
Sharrock and Anderson are concerned with how designers find solutions, and do
that recurrently, as a matter of course?
By way of an answer the authors first turn to Bucciarelli’s (1988) ethnographic
study of engineering practice, where it was noticed that ill-structured problems are
produced by designers in their conceptualisation of the design space. Like any other
form of work, design is composed of a working division of labour within which
designers are embedded. How a designer conceives of the design space depends
upon his or her position and function in the division of labour then (i.e., on his or
her role, competence, and skills). Thus, each position in the division of labour
brings a different conception of the design space to the table resulting in the
production of an ill-structured problem of various layers of complexity.
The attributes of the object and their interrelations … are of interest to
different persons in design … [who] see the object of design differently
according to their special interests. Each will work out the design task
according to their design task, relying on different kinds of models, theories,
tools, constraints. Each will work within a different ‘object world’: a world of
21
technical specialization, with its own dialect, system of symbols, metaphors

and models, instruments and craft sensitivities. (Bucciarelli 1988)
Naturally the various heterogeneous object worlds or conceptions of the design
space constructed by designers need to be aligned if the ill-structured character of
the problem is to be resolved. It might be said that conceptions of the design space
are aligned through a locally organized process of negotiation but, while correct,
that would be to gloss matters as it leaves unsaid in important respects how the
local process of negotiation is organized. More precisely, invoking the notion of
‘negotiation’ and all that implies (cooperation, bargaining, compromise, etc.) leaves
unsaid how the design problem is worked out and design solutions are worked up
time and again, as a matter of the most routine of day-to-day working practices?
In order to answer the question Sharrock and Anderson consulted the work of
design practitioners, studying how different conceptions of the design space are
constructed and aligned in actual working practice on the ground (in contrast to
constructed and aligned in theory) in a large development and manufacturing firm.
Particular attention was paid to the ways in which users were and are constructed as
“developers’ objects” (i.e., as persons populating the design space who have distinct
needs that technical solutions might be designed to support). What is of interest in
the authors findings are not their comments on ‘the user’ per se (i.e., some generic
conceptual definition), but the structure of the work whereby reasonable, mutually
intelligible and defensible constructions of the user and technically supportable
needs were arrived at in practice.
Thus, and for instance, it might be suggested that the user might be a
secretary, or a manager, or a key operator. Having designated these kinds of
users, it was possible to introduce sets of expectations about what they might
be trying to do, what they might know about the machine or process in
question and how likely they were to initiate one or another sets of routines. In
the terminology developed by Schutz [1974], ‘secretary’, ‘manager’, ‘key
operator’ are personal types associated with which are constellations of roles
and relationships. In addition to these personal types, our designers also
deployed what Schutz calls course of action types. Here the defining
characteristic is not social identity, gender, organizational position or role, but
an envisigeable course of action which is being undertaken. It was around
what could reasonably be said about such courses of action that ‘the user’
entered design decision making.
This finding, which is supported by other studies of design practice (e.g. Schön
1988), indicates that the analysis of the design space is an activity structured or
organized to some significant extent in terms of typification. Typification is a
commonsense method of constructing shared understandings and, in a design
context, of constructing an inter-subjective sense of user needs amongst the various
members of the division of labour in the actual course of getting the job of design
done.
The method, which presupposes the deployment of formal methods, works
through using commonsense categories of social types – e.g. ‘secretary’ – as a
resource to reason about and identify the needs of the particular users that populate
22
the object world. Commonsense categories of social types may be employed in this
way as such categories are tied to particular activities or courses of action which
define the social type invoked (Sacks 1992a). Thus, and for example, ‘policemen’
arrest and prosecute wrongdoers, ‘waiters’ take orders for food and serve at your
table, ‘secretaries’ answer phones, arrange meetings, and record minutes, etc. It
may be noted that when considering the courses of action which define a social
type, we are no longer considering an isolated individual but the actions of a
generic other: policemen not a policeman, waiters not a waiter, secretaries not a
secretary. The method of typification allows developers to identify generic needs of
a particular class of users then, under the commonly known auspices that ‘these’
actions are tied to ‘this’ type of user. Thus, analysis of the design space and user
needs is rooted in commonsense knowledge of the typical courses of action that
particular social types perform: in commonsense knowledge of patterns of action to
be precise.
In using the commonsense method of typification and invoking commonsense
categories of social types, developers employ common knowledge of patterns of
action to construct a reasonable, mutually intelligible and defensible sense of user
needs and so come to formulate potential design solutions. As Sharrock and
Anderson put it,
The user is introduced into design through the use of typificatory structures.
Our aim has been to show first that these structures conform to patterns and
second that these patterns can be analysed using the concepts of personal and
course of action types … By invoking such typificatory structures, designers
are able to construct the rationale for their design decisions within the flow of
the designing. Seen from within the activity of design, in the midst of
exploring the design space, these structures enable designers to construct their
design worlds.
The appeal to and knowledge of patterns of action is an integral part of design
practice – a naturally organized lingua franca underpinning cooperative analysis of
the design space by members of the design team. This naturally organized practice
of analysis provides for the reconceptualisation of the user, not on some theoretical
basis but on the basis of consulting a perspicuous setting. Consulting, that is, the
work of a workgroup who, as their day’s work, and because they know it as their
day’s work, are able to teach us what we could be talking about when we invoke the
notion of ‘the user’ (Garfinkel and Wieder 1992).
Accordingly, the use of the commonsense method of typification instructs us
that the user is not understood by design practitioners as a cognitive object but as an
essentially social object. More specifically, in details of structure we are taught that
the sociality of the object – of the user – consists of 1) personal types associated
with constellations of roles and relationships and 2) course of action types. Thus, as
a social object, the user is 1) an Organizational object – i.e., in object embedded in
an Organizational setting of one kind or another in terms of distinct roles and
relationships. And 2) as an Organizational object, the user’s relation to the
Organization of Work and other Organizational objects – i.e., other users - is itself
organized in terms of discrete courses or patterns of action. It might otherwise be
said that the user is a socially situated object (a person occupying a distinct role or
23
number of roles defined by distinct occupational categories) whose actions are

organized in terms of discrete patterns of action, recurrent ways of working, or
working practices in other words, that make up and define ‘the job’. In details of
real world, real time workaday structures of design we are taught, then, that the user
is a social object whose relationship to the Organization of Work and other users is
organized in terms of recurrent work practices. There are no synaptic firings here,
no abstract task structures, no abstract information processes, but discrete
assemblages of organizational work practices connecting together persons located
in jobs.
Reconceptualising the Interface

The social character of users is central to the reconceptualisation of the interface. It
was earlier noted that it is not simply a matter of semantic difference that the
interface came to be construed by HCI as the computer’s interface to the user and
not the user’s interface to the computer. As a result of this emphasis the
Organizational context of the user was ignored (Grudin 1990a). Consequently,
Grudin turns the traditional HCI concern with the interface inside out in an effort to
transcend the engineering mentality.
A Computer
I/O devices
System Documentation
administrator
Training
Field
support A User
Management
Colleagues
Consider the two faces to the user-computer interface. Is the user’s interface to
a computer the mirror image of the computer’s interface to the user? It may
seem that it should be, but on reflection it is not, unless one defines ‘interface’
extremely narrowly. The user’s interface to the computer may centre on the
software-controlled dialogue, but it also includes any documentation and
training that are part of using the computer. It includes colleagues, consultants,
24
systems administrators, customer support and field service representatives,

when they are available. These artefacts, processes, and people are so
significant in shaping our interactions with a computer that it is myopic not to
see them as part of a user’s interface to the computer.
Figure 6. The user’s interface to the computer (Grudin 1990a).
HCI’s focus on the relationship between the computer and the user obscures
the wider workaday environment in which computer use is embedded. In seeking to
operationalise and develop the abstract analytic formats of cognitive theory, HCI
treats users as units consisting of generic components and information processes
that may be factored into design through the use of scientific methods. This myopic
and misguided focus obscures the continuity of the outward movement of the
computer’s interface to it’s external environment through two dramatic shifts in the
user population: the shift from engineers and programmers to non-specialized users
as primary users, and the shift from supporting individuals to supporting groups
(Grudin 1990b). As a result of the ‘historical continuity of the interface’, Grudin
argues that it no longer makes sense to think of an individual operator making use
of a single workstation, let alone a large mainframe machine, but rather, given the
user’s role in Organizational life, the computer interface needs instead to be thought
of in terms of the work of the group of users that constitute some (part of an)
Organization of Work. Grudin’s argument is that the notion of the isolated,
individual, computer user is one that is simply untenable when the lived reality of
being a user in an Organizational setting is attended to. Situated in an
Organizational context, people work in teams, groups and collectives of all kinds, in
short people work collaboratively together. As a consequence,
we are beginning to see the focus of user interface design extend out into the
social and work environment, reaching even further from its origin at the heart
of the computer. (Grudin 1990b)
Consideration of the Organizational context of use, which sees computers being
used by teams of people in the course of doing ordinary jobs of work, brings with it
a radical reconceptualisation of the interface. One that provokes a necessary move
beyond narrow conceptions of what it is that constitutes an interface to a computer,
and how that might best be designed, to the lived reality of devising technical
support for users located in an Organizational setting.
Organizational context shapes the expectations, prior experiences, priorities,
preferences and specific tasks of users … Developers who do not understand
the organizational context of use increasingly risk failure. (Grudin cited by
O’Brien 2000)
In addressing the lived reality of computer use in an Organizational setting,
Bowers and Rodden (1993) take the reconceptualisation of interface even further,
‘exploding’ a unitary conceptual entity into many fragmentary sites where users
construct interfaces to computers over the course of getting their work done.
Bowers and Rodden observe that the concept of the interface is not a given thing –
not a naturally intelligible concept like that of a stone, for example - but an a priori
25
theoretical construction. Rather than propose some alternate a priori

conceptualisation of the interface, Bowers and Rodden recommend that a sceptical
position be taken towards such practice. They argue against the uncritical adoption
of received wisdom and the imposition of taken for granted theoretical categories.
They caution against blind acceptance of the core HCI assumption that the most
important aspects of human computer interaction must lie at the interface or in any
other single, fixed location. Instead, emphasis is placed on finding out what happens
to be problematic about human-computer interaction in practice.
In order to find out, theorising the matter is replaced with a concern to see how
ordinary people produce and work with their own received wisdom and taken for
granted categories in the course of interacting with computers in their workaday
lives. The issue, then, is not one of formulating a priori questions and answers, but
one of asking questions and thereby formulating answers of an entirely different
order.
Where do participants (organization members) see the interface as residing?
What do they treat it as being? Between what separated entities? With what
properties? Raising what problems?
The matter may be reformulated in the following way. Rather than theorising
questions and answers, we might instead consult the work of a workgroup who, as
their day’s work, and because they know it as their day’s work, will be able to teach
us what we could be talking about when we invoke the notion of an ‘interface’
(Garfinkel and Wieder 1992).
Bowers and Rodden consulted the work of a workgroup in a central
government department in the UK. The Future Technologies Branch (FTB) was
responsible for exploring new computing developments that may be of relevance to
central government computing. FTB had installed a new computer network in their
own department in order to assess a variety of new applications (including the
viability of the network itself). Bowers and Rodden describe the workgroup’s
experience of the network as follows.
In addition to the different interfaces provided to users by both client and
server programs a further interface was crucial to the effectiveness of the
network. Supporting the interface between the client and server programs was
crucial to the distributed groupware systems installed on the network.
Administration within the ... network was neither allocated to a specialized
system administrator nor added to the normal working practice of the group
using the network. As a result it became the responsibility of a small number
of individuals to ensure the network was behaving ‘normally’. As one network
user stated: “The problem is people assume that these applications are easy to
install but they don’t realize that I seem to spend all my time fixing them”.
Fixing the network consisted of ensuring the availability of servers on the
network. Problems emerged which often highlighted a number of interfaces of
significance to the network.
In practice, for members (or users), there is not one single interface to the computer
but a number of interfaces (the number being contingent on the Organization and its
workaday activities). In their study of work and computer use at FTB, Bowers and
26
Rodden reported that users identified three significant interfaces: the personal-
public interface, the departmental interface, and the Organizational interface. In
practice, the unitary image of the interface explodes and leaves in its place a
‘radically heterogeneous’ set of varied and conflicting workaday concerns ranging
from the technical, to the personal, to the Organizational, and more, all of which
impact directly on human-computer interaction. Attempts to make workstations
more responsive to personal or individual tasks by FTB staff, for example, often
had public consequences in halting the server application. Working on non-standard
protocols, the network caused interference problems with the wider corporate
network, bringing departmental activities into account. And the network itself
contravened Organizational policies on computer use. These, and a great many
more issues and practical concerns, elaborate the multiplicity of different ways in
which users interface to the computer. That multiplicity dispenses with the fiction
that there is but one boundary between users and the computer, namely the
interface. Instead, a variety of interfaces to the computer are constructed by users in
their working practices as sites where workaday trajectories collide and problems
get articulated. Sites, that is, where human-computer requirements are pronounced.7
It should be said that Bowers and Rodden’s examination of the FTB network is
not aimed at simply extending the concept of the interface to encompass more of
the elements and entities which Grudin pointed to. Their work is not one of
redrawing the boundaries of the interface while retaining it as a unitary concept
applied to group-network interaction. Instead, they are concerned with
understanding and discovering the different relationships between users and
computer systems in order to develop support for work-in-context. Bowers and
Rodden demonstrate that the unitary concept of the interface is inadequate for such
purposes as a direct result of that concept’s context -free a priori construction.
Bowers and Rodden radically reconceptualise the interface as a heterogeneous body
of Organizationally constructed worksites. Analysis of the human-computer
interface is therefore placed on identifying
what the problems [of interfacing in an organization] are, what the solutions
and methods for producing them may be and so on which members suggest
and work with rather than what the ‘expert analyst’ armed with HCI theory
determines on the basis of a priori conceptual decisions. (Pycock 1999)
In other words, just what comes to constitute a human-computer interface cannot be
specified in advance but will be the outcome of consulting practice and the variety
of situationally relevant interfaces users construct together in the course of getting
their workaday activities done (see, for example, Crabtree et al. 2002c). The
question, of course, is one of how design might go about consulting practice and
identifying the organizational needs of users emerging from their work together?
___________
7
In this respect interface design may become a vehicle for cooperative analysis of
the design space, enabling a heterogeneous set of concerns to be brought to bear on
the design of potential computer support (Mogensen 1992). See Chapter 4 herein
also.
27
The Turn to the Social

As a result of cognitive bias and a misguided alliance to the methods of natural
science, HCI has succeeded in obscuring the sociality of the user and the
workplace. The challenge for design is one of getting to grips with the sociality of
the workaday world. Analysis of HCI’s failings suggest that users might be better
understood as essentially social objects, as doers of interrelated jobs of work which
are organized through discrete assemblages of Organizational work practices. In
accomplishing those work practices, users come to form heterogeneous groups or
discrete Organizational worksites, each group or site having distinct though deeply
intertwined collaborative work requirements. If we are to develop an understanding
of user needs in such situations, the first problem to be addressed is one of
developing an appropriate analytic framework guiding investigation into the
sociality of the workaday world. As Bannon puts it,
Understanding people as ‘actors’ in situations, with a set of skills and shared
practices based on work experience with others requires us to seek new ways
of understanding the relationship between, people, technology, work
requirements, and Organizational constraints (Bannon 1991)
Just what those new ways amount to is a matter to be decided - an ongoing job of
work. Design has already, however, taken an irreversible turn towards the social as
a primary point of view for analysing the design space under the auspices of
groupware and cooperative systems, and with advent of computer supported
cooperative work (CSCW) in particular. CSCW provides a range of analytic
frameworks articulating important social characteristics of work, which may be
used to guide analysis of the design space. One particularly influential framework
devised by social scientists is considered below.8
Cooperative Work?
In August 1984 Irene Greif and Paul Cashman organized an invited workshop to
address issues involved in the development of computer-based systems supporting
the work of discrete assemblies of people. Greif and Cashman coined the term
computer supported cooperative work to describe their concerns and to elaborate
“an identifiable research field focused on the role of the computer in group work”
(Greif 1988). CSCW was thus defined as an enterprise concerned with
understanding and developing technological support for the activities and
___________
8
It is fair to say that in recent times HCI practitioners have recognised the pressing
need to move beyond the narrow cognitive frameworks and methods that underpin
the discipline. Contemporary research has seen HCI turn to the social through
anthropology, cultural studies, and a variety of participatory approaches. Cognitive
formats still stand at the centre of a great deal of research in HCI however, directing
analysis whether in terms of brain metaphors, physiological processes or distributed
cognition. Nonetheless, a significant shift in perspective may be detected in HCI, as
marked by the increasing contributions of HCI researchers to CSCW and the cross-
fertilization of new ideas.
28
relationships that hold between people-working-together-in-groups. On this

account, CSCW deals with small, stable, homogenous, and relatively harmonious
assemblies of people. Specifically, with activities that involve a small number of
persons who are directly and co-presently involved in the accomplishment of some
particular workaday activity or set of activities, such as moving furniture,
conducting a meeting, performing a tutorial, etc. On this original conception, then,
cooperative work was understood as the work of a small group actively engaged in
co-located cooperation (Bannon and Hughes 1993).
As interest in CSCW burgeoned, the adequacy of Greif’s original
characterisation of cooperative work was brought into question, particularly
(although by no means exclusively) by the European faculties of human science in
general, and social science in particular. Consideration focused on the notion of
group work which, in designating a relatively closed and fixed aggregation of
people, was considered by some to limit the potential of CSCW in the workplace as
the workplace exhibits few (if any) of these characteristics (Schmidt and Bannon
1992). The perceived problem with Greif’s definition of cooperative work was that
it was too narrow a conception of the target area for computer support. The group
work conception ruled out the possibility of developing support for much of the
work that takes place in Organizations of Work, which are staffed by large,
distributed, changing, differentiated, heterogeneous assembly’s of people and are,
as such, characterised by multiple viewpoints and competing if not conflicting
interests. More elaborate conceptions of cooperative work were required if
computer support for the workaday activities of Organizations was to become a
reality.
Developing earlier notions of CSCW’s remit, Schmidt and Bannon remarked
that the category cooperative work is a specific category with certain fundamental
characteristics common to all work arrangements. Accordingly, Schmidt and
Bannon point out that the primary characteristics of all arrangements of work are
that activities of work are distributed and interdependent. In saying that activities of
work are distributed, Schmidt and Bannon mean to point out that activities of work
are performed not in one single place but in a variety of places: on the shopfloor, in
the manager’s office, in administrative departments, in accounts, sales, and
customer services, etc., and across a multiplicity of local, regional, national, and
international sites. Activities of work are spatially and temporally distributed then,
but they are also distributed in the sense that workers are ‘semi-autonomous
agents’. That is to say that each worker, or team of workers, is responsible for
accomplishing particular activities of work in the face of the unique situations and
contingencies that characterise the job and of doing so in terms of the goals, rules,
policies and procedures that govern any particular job. Activities are also
distributed then, in that responsibilities are distributed and attached to the
accomplishment of particular jobs of work. At the same time, the workaday
activities of these semi-autonomous agents are interrelated and interdependent.
Which is to say that individual activities of work are tied together and rely upon one
another. Activities of work are mutually dependent and work is, as such, not only
essentially distributed but essentially cooperative in that people are obliged to
cooperate with one another in order to get their distributed, mutually dependent
activities of work done. As Schmidt and Bannon put it, being mutually dependent
29
means that A relies positively on the quality and timeliness of B’s work and vice
versa.
The essentially distributed and interdependent nature of work requires that
workaday activities must be kept in check such that individual jobs of work are
interrelated in an effective and timely fashion. Alternately it might be said that
distributed activities of work must be ‘articulated’. Drawing on the writings of
Anselm Strauss, Schmidt and Bannon suggest that articulation work is an essential
form of work in any division of labour (or ‘total arc’).
Articulation work amounts to the following: First, the meshing of the often
numerous tasks, clusters of tasks, and segments of the total arc. Second, the
meshing of the efforts of various unit-workers (individuals, departments, etc.).
Third, the meshing of actors with their various types of work and implicated
tasks. (Strauss 1985 cited by Schmidt and Bannon 1992)
It might otherwise be said that workaday activities must be coordinated. The notion
of articulation work refers to the ways in which coordination gets done. Normative
accounts of Organizational work (be they the accounts of Social Science, Business
Management, Economics, or the Organization itself), construe coordination to be a
product of formal Organizational devices that govern interaction and collaboration;
devices such as Organizational plans and procedures, which are understood to
specify precisely the steps whereby coordination is to be achieved. Such
conceptions have proved, however, to be highly idealised and grossly inadequate in
accounting for the real world, real time coordination of activities. Gerson and Star
(1986) go so far as to point why.
Every real world system [of work] is an open system: It is impossible, both in
practice and in theory, to anticipate and provide for every contingency which
might arise in carrying out a series of tasks. No formal description of a system
(or plan for its work) can thus be complete. Moreover, there is no way of
guaranteeing that some contingency arising in the world will not be
inconsistent with a formal description or plan for the system … Every real
world system thus requires articulation to deal with the unanticipated
contingencies that arise. Articulation resolves these inconsistencies by
packaging a compromise that ‘gets the job done’, that is closes the system
locally and temporarily so that work can go on.
In other words, as a direct result of real world contingencies, formal Organizational
devices do not so much provide for the coordination of activities as require the
coordination of activities if the outcomes they prescribe are to be realized.
Lucy Suchman’s work on the practical use of Organizational procedures
elaborates the fundamental characteristics of coordination here. Work and
Organization have often been construed by system development and the social
sciences alike as being essentially rule-based in character. Work thus consists of
following a prescribed sequence of formal procedures through the accomplishment
of which workaday activities get conducted and coordinated. On this normative
reading, formal procedures organize work and provide for the coordination of
individual activities. The design of, for example, office information systems and the
30
rationale behind various object-oriented approaches is or have in the past been

based on such a priori conceptions. As Suchman (1995) points out however,
The way in which people work is not always apparent. Too often, assumptions
are made as to how tasks are performed rather than unearthing the underlying
work practices.
While there can be no doubt that procedures are common coordinating devices in
the workplace, they do not necessarily, as presumed, provide instruction as to what-
to-do-now and what-to-do-next on each occasion of work. That is to say that rules
and other formal procedures do not determine the performance of work activities
and do not, therefore, determine how coordination gets done on each occasion of
work. Rather, rules and procedures describe general guidelines for how things
should go and requirements for what they should come to in the end (Suchman
1989). In practice, procedures are treated as guidelines as they do not specify and
cannot specify in each and every instance of compliance, what-to-do-now and what-
to-do-next. They do not do so as compliance is contingent upon the actual details of
the particular case to which the procedure, or set of, is being applied by the worker
or workers here and now (Suchman 1983).
Thus, procedures do not provide for the coordination of action but require it
such that the contingencies of any particular case might be reconciled with the
demands of the formal procedures said to govern all such cases. The coordination of
workaday activities therefore consists not of following procedures but of effecting a
practically adequate ‘fit’ between formal procedures and the contingent
circumstances of actual cases to which the procedures must be applied. It is this
work, the achievement of formal procedure and Organizational routine in the face
of work’s everyday contingencies that is of central concern to the design of
collaborative systems, for it is in that achievement that workaday activities are
assembled or constructed and coordinated, and the discrete Organizational
structures of activities in which systems are embedded, are reflexively produced. As
Suchman (1983) puts it,
The procedural structure of Organizational activities is the product of the
orderly work of the office, rather than the reflection of some enduring
structure that stands behind that work.
By placing an emphasis on the orderly work of the office (or any other
worksite) Suchman seeks to draw attention to seen but unnoticed or taken for
granted features of work. All too often, Organizational structure and work activities
are separated in normative accounts. Work activities are viewed as essentially
unstructured in themselves. Obviously, some order, some structure must be
imposed upon them if efficient productivity, for example, is to be achieved. In
placing an emphasis on the orderly work of the office, however, Suchman (1989)
draws attention to the fact that
Careful observation of what actually goes on in offices [etc.] … reveals that
these ‘unstructured’ activities involve both fine-grained structures and, more
importantly, a crucial and unacknowledged form of expertise.
31
Normative accounts have gone so far as to concede that the orderly work and
expertise of which Suchman speaks consists of informal structures of practical
action, contrasting them with the formal structures of work prescribed by
Organizational procedures (etc.). Despite such insistence, real world Organizational
structures – in sharp contrast to the analytic structures that characterise normative
accounts – are, quite visibly, the concerted product of a community of co-workers
(Blau 1964). Thus, Organizational structures of activity are, in reality, self-
organizing structures, produced in the interactions and collaborations of an
Organization’s staff. The skills and expertise upon which the Organization of Work
crucially depends are not to be found in normative accounts of work then, but the in
the self-organizing structures of practical action produced by an Organization’s
staff in the course of carrying out and concerting their daily routines.
To say that work is routine is not say that it is trivial and mindless, nor that it
may be easily automated. On the contrary, the most routine of work activities
demonstrably rely on the skill and judgement of incumbents (Blomberg et al. 1994).
More often than not the skill and judgement involved in accomplishing routine
work is invisible to people located higher up the Organizational food chain.
Nonetheless, routine activities and the exercise of judgement co-exist at all levels of
the Organizational hierarchy. On the shopfloor, skill and judgement consists of
effecting a practically adequate relationship between formal procedures and the
contingent circumstances of the actual cases to which those procedures must be
applied, for example. Any such relationship is effected in the practical actions of
shop-floor workers and in those actions - which rely on the skill and judgement or
competence of incumbents – and in the face of daily contingencies, the routine is
made routine.
The making of Organizational routines implies that there is something essential
about practical action. That some actions have, of necessity, to be taken if the
routine is to transpire yet again. As the late Herbert Blumer (1969) described
matters here,
In dealing with collectivities and with joint action [cooperative work] one can
easily be trapped in an erroneous position by failing to recognise that the joint
action of the collectivity is an interlinkage of the separate acts of the
participants. This failure leads one to overlook the fact that a joint action
always has to undergo a process of formation; even though it may be a well-
established and repetitive [routine] form of social action, each instance of it
has to be formed anew.
Each activity, no matter how routine, must be formed anew on each and every
occasion of its performance. As a reoccurring consequence of workaday
contingencies, just what actions have to be taken if the routine is to transpire yet
again is not, and cannot be, specified by formal Organizational devices. This need
not cause undue concern however, as it is a grossly observable fact of working life
that a great many workaday contingencies are reoccurring. Insofar as the same
activity is undertaken again and again, day after day, then the same practical
troubles occur again and again, day after day. Managing such troubles is a part and
parcel of getting the job done and in that respect staff improvise and devise
particular courses of practical action or work practices to handle particular
32
contingencies, thereby making their activities routine yet again (Zimmerman 1973).
Thus, although
there is a ‘necessary’ character to formal rules .. it is not a prescriptive
necessity (let alone a causal one) but one of conducting Organizational affairs
in a manner whereby the rules can be said to have been adequately applied in
the face of the unavoidable contingencies of the particular ‘case’ to hand.
Insofar as contingencies are recurrent, and the manner whereby they are dealt
with suffice, then the improvised ways of adequately applying the rules
become routine and standard practice for persons who do the work. Curiously,
the Organizational adequacy of improvised practices might be said to consist
in their not being noticed, remarked upon, etc., by management in that, and
precisely because, they suffice to ‘get the job done’ without undue problem or
recourse for concern. (Crabtree 2000a)
The point of this, and it is a significant one, is that the distinct assemblages of
Organizational work practices which tie users together and define the sociality of
work are not practices specified by the Organization of Work but practices devised,
performed, and altered by an Organization’s staff in response to the formal
requirements of the Organization of Work. In taking a turn to the social, CSCW
instructs us that workaday activities are structured or organized through working
practices devised by an Organization’s staff. Analysis of the design space might
proceed, then, not only by attending to the formal requirements of the Organization
of Work but also, by attending to work on the ground, as it is actually and
observably organized in the practical actions and interactions of an Organization’s
staff. This focus on the cooperative work of an Organization’s staff and the working
practices they devise to coordinate and organize their work is not to deny the
importance of the Organization of Work. Nor is it to ignore the interests of parties
concerned with the upkeep and maintenance of the Organization. It is to draw
attention to the socially organized arrangements of work which Organizational
programmes, plans, policies, procedures, requirements, etc., rely on for their
realization; real world, real time arrangements that are often ignored by work
analysts of all kinds.
Self-organizing Structures of Work

Peter Blau’s (1964) classic study of a US employment agency serves to elucidate
the importance of attending to how Organizational programmes are actually met on
the shopfloor by those who must carry out the work when undertaking analysis of
the design space. The particular agency Blau studied was part of a national
Department of Public Employment and party to the application of general
procedures of work designed by a centralized programme to “serve workers seeking
employment and employers seeking workers”. In the fieldsite’s case, general
procedures were particularly concerned with meeting the employment needs of the
local clothing industry. The fieldsite consisted of four divisions or sections and
twenty-four members (one head of department, three section supervisors, fifteen
interviewers, and five receptionists). Two of the four sections were responsible for
manual occupations, a third served handicapped people, and the fourth screened
33
applicants. Screening was accomplished by the receptionists and clients were then
passed on to the interviewers in the other three sections who determined
qualifications, experience, skill, etc., and referred clients to suitable jobs. Blau
describes the workplace as follows.
All morning and most of the afternoon, long rows of men and women seeking
employment waited … to be screened by receptionists. Other clients were
seated in chairs waiting to be interviewed. Every few minutes, an interviewer
called a name, and a client arose and walked to his desk for an interview.
Telephone calls from employers frequently interrupted the interviews. One or
another official was always leaving his desk, either to search the files or to
consult a colleague.
According to formal accounts, organizing this constant movement of people
are the general procedures of work designed to meet the Department of
Employment’s objectives. These procedures comprise and regulate a centralized
programme of work. Summarily described, that programme consists of the
following general procedures.
q Requests for workers received from employers over the telephone must be
recorded on a form: the job order. All twenty-five categories of information on
this form must be completed. The most important category is a summary of
the qualifications required for the job. This includes a description of the tasks
the worker must perform, how he or she must perform them, the purpose of
these tasks, and the skills and responsibilities involved. Job orders are filed on
the basis of occupational code numbers obtained from a four-volume
codebook.
q When taking applications for jobs from clients, information relevant to the
categories of information on the job order is to be elicited and recorded on the
application form. The interviewer must then match the information on the job
order with that furnished by the applicant in order to select the client best
suited for a given vacancy. This matching procedure assures the selection of
the most qualified applicant among all those available for a job.
q Selected applicants are recalled to the office for a referral interview where the
requirements of the job are explained at greater length and the client is asked
to accept or reject it. Following acceptance, the employer is called to
determine whether the position is still open, and if so, a referral card is written.
q The last step in the placement process is confirmation that the referred client
has been hired, which must be obtained from the employer within two days of
the referral.
q Refusal to accept a suitable job without good cause, or failure to attend an
employer’s interview following referral, must be recorded and the client
disqualified from claiming income support.
Straightforward enough. As Blau describes it, however, the procedures used in
practice were “quite different”.
The local conditions in which work placement occurred, notably the needs of
the areas main employer - the clothing industry - gave rise to adjustments of
procedures in the interest of operating efficiency:
34
The local clothing industry was characterised by alternating seasons of

feverish activity and widespread layoffs, by erratic variations in demand
caused by changes in fashions, and by standardization of occupational tasks.
Seasonal fluctuations in employment created a large volume of work …
requiring speed in operations … [and] employers demanded workers
immediately or not at all, since sudden shifts in demand created pressing needs
for workers. Finally, employers who needed unskilled workers not only called
the employment agency but also advertis ed the vacancies by placing signs in
the street in front of their shops. Department X could serve its applicants only
if it referred a qualified worker before a passer-by responding to the sign had
been hired.
These conditions of employment required staff to modify placement procedures
such that their intended objective could be met. Since job openings had to be filled
the same day as a request was made or not at all, there was no time to call all the
clients that might be best matched to the job order. Indeed there was no time to
perform best matches at all. Instead, workers were selected for referral directly from
the flow of incoming applicants. In real world, real time circumstances, a sentence
or two describing an incoming applicant’s last job, skill and experience – in contrast
to eliciting information relevant to twenty five categories - provided sufficient
occupational information for all practical purposes here and now (i.e., for
establishing the client’s suitability for the work detailed on incoming job orders).
Should the client accept the job offered to him or her, then a call to the employer
revealed whether the vacancy had been filled, and if not the client was given a
referral card with travel directions on it.
In practice, occupational codes were not used then. Application forms were
rarely made out. The selection of candidates for jobs was not made from application
files but from incoming applicants, and so on. Blau’s illustrations suffice to show
that it is insufficient to appeal to rules, procedures and other formal devices, in
accounting for the social organization of workaday activities.9 These illustrations
also serve to elucidate how rules are complied with and how procedures are carried
out in particular circumstances - and all circumstances are particular without
exception. Blau’s studies of work demonstrate that Organizational policies, plans,
procedures, and the rest, are carried out and executed in terms of the local
accomplishment of working practices devised by staff to coordinate their workaday
activities and meet formal requirements. Developing collaborative systems to
support the cooperative work that is essential to Organizational life thus requires
that we attend not only to Organizational programmes and procedures but also, and
significantly, to the real world, real time working practices devised by an
Organization’s staff to realize specific programmes and procedures of work. Even
in situations where radical Organizational changes are afoot, the need to attend to
actual working practice is paramount as a failure to do so runs the serious and
expensive risk of building technology solutions which are misaligned with work on
___________
9
It is worth noting that a failure to recognise the real world character of compliance
with rules in systems design has proved to be “fateful” as result of the
“inflexibility” of systems in actual situations of use (Jirotka et al. 1992).
35
the ground (Button and Harper 1996); of designing perfect solutions to the wrong
problems of work as it were (Crabtree et al. 2001a). That said the problem for the
analyst now becomes one of making the social organization of work – staffs’
cooperative work and organizing practices - visible and available to design
reasoning?
36
Even though design may be concerned with
developing a completely new system, under-
standing the context, the people, the skills they
possess, what kind of work redesign may be
involved, and more, are all important matters for
designers to reflect upon.
John Hughes et al.

2. Making Cooperative Work Visible
The need to appreciate the fundamentally social or cooperative nature of work in
undertaking collaborative systems design mitigates against a technology-driven
approach as a primary point of view for analysis. Technology-driven approaches to
analysis, such as object-oriented analysis for example, are inappropriate as they are
not, in themselves, concerned with understanding the cooperative nature and
characteristics of work but with modelling the information processes within the
problem domain. As Madsen et al. (1993) put it, for example,
The analysis phase is primarily concerned with understanding the problem
domain, i.e. the referent system … In this phase it is important that the
developer is not restricted to (formal) mechanisms of a programming language
like BETA. This also applies to any other formal language proposed for
analysis including the many proposals for graphical notation. If the developer
is restricted to the use of formal notation this may impose too narrow a view
on the referent system. The developer should [therefore] make use of any
means available when doing analysis, including informal description
Informal description contrasts with formal description, which reduces the referent
system to a narrowly conceived technical realm. This, of course, does not mean that
there is no place for technology-driven approaches in the analysis of the design
space. Obviously there is, but as secondary points of view; as a means of
abstracting from the real world and developing underlying models to support the
cooperative work of intended users. In the first instance, however, technology-
driven approaches provide little (if any) insight into cooperative work (Schmidt and
Bannon 1992) as they are not designed to analyse that work but the information
processes produced in the course of the work’s production and coordination. With
the emergence of CSCW the challenge to design is, then, one of finding an informal
mode of description that supports analysis of the sociality of the design space and
the moulding of technology to cooperative work.
The effort to locate a suitable candidate providing a social point of view on the
referent system has attracted interest from across the human sciences, including
Sociology, Anthropology, Psychology and the Organizational sciences to name but
a few. Organizational theory was a primary candidate in the field although it rapidly
transpired to be unsuitable for the task. Joan Greenbaum (Knudsen et al. 1993)
sums up the failings of the management perspective succinctly.
I believe that the field of management science and its offspring organizational
theory are like the emperor with no clothes. Everyone is looking at him, but no
one is saying it. Organizational theory acts like the magic cloth that keeps us
from looking at the essential issues within the workplace … The field of
organizational theory throws us off that course, as it defines Organizations and
their behaviour as rational entities acting through managerial practices.
Although the subject matter may differ, the problems that emerged in the encounter
with management science were the same as cognitive theory and a multiplicity of
other competing perspectives, namely methodological. Like cognitive theory,
37
Making Cooperative Work Visible
organizational theory assumes that the validity of its findings are guaranteed in the
use of scientific methods. Accordingly, organizational theory emphasizes the need
for rationally validated methods (generic analytic formats and mapping procedures)
– i.e., methods where the ‘validity’ of the matter is established prior to their
application to particular cases. Rationally validated methods determine how work is
to be described and analysed in design. As Hughes (1993) puts it,
They impose, by fiat, a version of reality insensitive to the ways in which the
social world is a meaningful one and one constructed by those who live within
it. In other words, [such] methods produce or construct the social reality they
intend to investigate as a discovering science through the methods themselves;
methods which do not so much discover facts about social life as construct a
version of that life by its methods.
As a consequence, and as Greenbaum points out, the rationalist mentality embedded
in methods of description so prevalent in the human sciences “keeps us from
looking at the essential issues in the workplace”; which is to say that rationalist
methodologies gloss and obscure the real world, real time character of work.
Recognition of this fact soon emerged in the case of organizational theory’s
candidacy. Accordingly, it was recognised that what collaborative systems design
required were not scientific credentials as it were, but approaches capable of
securing adequate reference to the real world, real time character of Work and
Organization (Knudsen et al. 1993).
In light of that need, designers have turned to the ‘interpretative’ traditions in
anthropology and sociology – traditions that eschew natural science modes of
inquiry.10 The requirement here was and is to devise methods
that provide access to the world experienced by social actors themselves and
methods appropriate to the phenomena being investigated. The catchword
might be, ‘fidelity to the phenomenon’, namely, the experiences and
knowledge social actors exhibit in the course of their daily lives … the prior
requirement of this is the development of a descriptive apparatus rather than
an explanatory one. (Hughes 1993)
The validity of any such apparatus depends not on a priori rationalizations but on
the adequacy of the results it produces in its deployment. Within the context of
design, and analysis of the design space in particular, any such apparatus will be
required to handle a variety of work domains and pay careful attention to the
subtleties of work in particular workplaces; subtleties that are too often obscured by
the generic formats employed to explain the social character of Work and
Organization and which predominate in the human sciences. Bound up with these
issues - which are concerned with describing work-in-context - are requirements to
identify cooperative work activities and their interdependencies. The implication
here is that the cooperative work of intended users is not readily packaged (as it has
___________
10
More precisely, such approaches eschew scientism, which sees the wanton
misuse of scientific methods in pursuit of the misguided idea that all things may be
adequately accounted for through the accomplishment of scientific practices.
38
not as yet been described anywhere) but needs to be brought out in the analysis of
informal (i.e., non-technological) work descriptions. Placing an emphasis on
description in the effort to understand social life from the perspective of those
studied before stepping back to make a more detached assessment, ethnography
presented itself as a potential candidate providing a social point of view on the
referent system.
Ethnography: An Informal Mode of

Description and Analysis
Ethnography emerged as a broad approach to social inquiry from anthropology in
the early 1920s (Malinowski 1922) and by the end of the decade the approach was
adopted for domestic employment by members of the Chicago School of Sociology
(Prus 1996). The shift to domestic employment followed the initiation of a wide-
ranging programme of research by Robert Park and Ernest Burgess into the social
organization of urban life in Chicago. Gathering all kinds of data on a wide variety
of topics, Park outlined the ethos of the research programme to his graduate
students as follows.
You have been told to go grubbing in the library, thereby accumulating a mass
of notes and liberal coating of grime. You have been told to choose problems
wherever you can find musty stacks of routine records based on trivial
schedules prepared by tired bureaucrats and filled out by reluctant applicants
for aid or fussy do-gooders or indifferent clerks. This is called ‘getting your
hands dirty in real research’. Those who counsel you are wise and honourable;
the reasons they offer are of great value. But one more thing is needful; first-
hand observation. Go and sit in the lounges of the luxury hotels and on the
doorsteps of the flophouses; sit on the Gold Coast settees and the slum
shakedowns; sit in the orchestra hall and in the Star and Garter burlesque. In
short, gentlemen, go get the seat of your pants dirty in real research. (Cited in
Prus 1996)
Park’s injunction to ‘go get your hands and the seat of your pants dirty’ – i.e., to
conduct research through first-hand observation - quickly proved itself to be a
fruitful means of developing a rich portrait of the social organization of urban life
(in sharp contrast to theorising or playing around with statistical aggregations). The
following sections address the work involved in getting your hands and the seats of
your pants dirty, particularly the work involved in extracting some intelligible tale
of cooperative work from the data that is gathered in the course of first-hand
observation.
Investigating Cooperative Work

Having gotten access to a worksite, which is not necessarily the easiest of tasks but
one that confounds prescription beyond the exercise of courtesy and commonsense
(Rouncefield et al. 1997), one of the biggest problems often encountered in
undertaking ethnographic research is establishing a sense of where to start. As
Malinowski (1922) somewhat amusingly described the experience of starting his
39
classic study, “I had periods of despondency, when I buried myself in the reading of
novels, as a man might take to drink in a fit of tropical depression and boredom.”
Figuring out where to start the study is more often than not experienced as
something of a daunting prospect, until the researcher realizes that where to start is
really not the issue as cooperation abounds and one can begin anywhere within the
boundaries of the design space. Starting somewhere is what counts. The researcher
who is concerned with ethnomethodological analysis should also bear in mind that
he or she cannot hope to have a clear enough sense of the work of the site to guide
the study and determine particular areas of relevance at the outset. This should not
be considered at all problematic since the ethnographer’s task is to uncover matters
of relevance, unfettered by preconceptions of what might be important. Why
unfettered by preconceptions? As the late Herbert Blumer (1969) pointed out, most
social science research, even much that is passed off as ethnographic, is not
designed to develop a close and intimate familiarity with the area of life under
study.11 Immersion in the field is often prefigured and directed towards abstract
problems rather than what thoroughgoing exploration and inspection of the daily
work of the site might have to say about such problems. Here the analyst might ask
whether or not prefigured problems exist as practical problems at the site? If so, in
what ways are they problematic for the site’s staff? What problems do the site’s
staff encounter in their work? How do staff manage and conduct their work
together? And so on?
In place of the flexible exploration and inspection of the site’s work –
exploration and inspection driven by that work – ethnographic inquiry is all too
often started with generic analytic formats which are employed to formulate a
research agenda and protocols for its investigation. In other words, generic analytic
formats are used to pose a research problem which may be explored through the
application of a particular set of research methods (such as task analysis, for
example). As Blumer pointed out, none of this provides for firsthand knowledge of
the work of the site however:
See how far one gets in submitting proposals for exploratory studies to fund-
granting agencies with their professional boards of consultants, or as doctoral
dissertations in our advanced graduate departments of sociology and
psychology! Witness the barrage of questions that arise: Where is your
research design? What is your model? What is your guiding hypothesis? How
are you operationalising the hypothesis? What are your independent and
dependent variables? What is your sample? What is your control group? And
so on. Such questions presume in advance that the student has the firsthand
___________
11
Herbert Blumer is, in a great many respects, the unsung hero of ethnographic
research, being a leading member of the influential Chicago School of Sociology
that instantiated the use of ethnography in urban environments in the late 1920’s
following the pioneering work of Malinowski and others in more exotic settings.
Blumer, in other words, was very much responsible for putting ethnography to work
in the study of our own workaday activities and his insights are as pertinent today
as they were when originally formulated.
40
knowledge that the exploratory study seeks to secure. Since he doesn’t have it
the protocolised research procedure becomes the substitute for getting it!
Consequently, just what is seen through research protocol, is not a reflection of
cooperative work, but a function of the methods applied and the theorising done by
the researcher in applying them. As Blumer put it,
The questions that are asked, the problems that are set, the leads that are
followed, the kinds of data that are sought, the relations that are envisioned,
and the kinds of interpretations that are striven toward – all these stem from
the scheme of the research inquiry instead of from familiarity with the
empirical area under study.
If cooperative work and the practices whereby it is organized are to be made visible
and available to design reasoning, the researcher must set aside his or her
preconceptions and instead be faithful to the phenomenon, exploring and inspecting
Work and Organization as it is observably ‘put together’, constructed and
assembled by the Organization’s staff in their real time collaborations. How is the
researcher to be faithful to the real world, real time nature of cooperative work?
What does ‘doing being faithful’ to that phenomenon consists of in accomplishing
exploration and inspection of a site’s work?
Exploration
There are no fixed set of procedures for accomplishing exploratory work, as how
one comes to develop a familiarity with cooperative work will very much depend
on the nature of the work under study. Consequently, just about any ethically
acceptable array of techniques may be employed to explore the work of the site
insofar as they are appropriate to the study of that work. Like any member of the
ordinary society trying to discover the organization of work in a novel setting, the
researcher might engage in direct observation of the work, being a co-located party
to its accomplishment. He or she might be rather more remote, observing
interactions on video or listen to talk on audiotapes. She might engage in informal
talk or interviews with the site’s staff, or listen to their conversations in situ.
Personal biographies may be elicited. Group discussions conducted. Letters, diaries,
and records be consulted and discussed with parties to their production. To reiterate,
just how the researcher comes to develop an intimate familiarity with the work of
the site, will depend on the nature of the site’s work. The daily work of some sites
may practically exclude conducting informal interviews as the work unfolds, such
as in the doing of interrogations in courtrooms or police stations. Other sites may
exclude observation of participants’ work via video, such as in psychiatric centres
where ‘being watched’ may alarm inmates and trigger disturbing psychological
episodes. Further still, what of counselling sessions or doctor-patient interaction?
Just how the researcher goes about developing an intimate familiarity with the site’s
work is an open question to some extent, the limits of the extent being that he or she
develops a thoroughgoing familiarity with what goes on without upsetting,
offending, or jeopardizing the careers of parties to the work. Nonetheless, all that
matters at this stage is that by some means acceptable to the parties to the work, the
researcher develops ways of getting to know the work of the site.
41
Exploration work is highly flexible then, and driven by the real world, real
time character of worksite activities in contrast to the requirements of
(pseudo)scientific protocol. While the misguided who harbour scientific pretensions
may be scornful of such a general procedure, treating firsthand observation as
peripheral, as soft science, or journalism even, there is nothing soft about
exploratory work. As Blumer put it,
The flexibility of exploratory procedure does not mean that there is no
direction to the inquiry; it means that the focus is originally broad but
becomes progressively sharpened as the inquiry proceeds.
What should be borne in mind, then, is that the initial phase of an ethnographic
study – exploration - is one of familiarising oneself with the work of the site. So, at
the outset, start anywhere, with any person that looks approachable and least likely
to be bothered by the presence of a researcher, and collect as much material as
possible of whatever sort is appropriate. In doing that, the researcher will find that
at some point relatively soon, a concrete understanding of the work of the site and
its organization will begin to emerge. He or she will then be able to decide where to
focus their efforts to cover the elements of the worksite most relevant to the broader
issues framing the research. It is important not to worry about issues of relevance at
this stage - they will be resolved with time and closer inspection.
Inspection
The purpose of exploration is to gain firsthand knowledge of the work of the site
and, thereby, to develop a concrete focus to the research; a focus that is emergent
from and shaped by real world, real time cooperative work. Over the course of
exploration, certain aspects of the work become more interesting than others.
Certain activities and work practices start to capture the researcher’s attention and
become more pronounced. Certain analytic themes begin to emerge, such as the real
world character of ‘interviewing’ in Blau’s study, for example. These emergent
categories of analysis start to direct the researcher’s inquiries. He or she starts to
inspect them in fine detail.
The procedure of inspection is to subject such analytic elements [as
‘interviewing’] to meticulous examination by careful flexible scrutiny of the
empirical instances covered by the analytical element.
In doing inspection, the researcher strives to understand emergent categories of
analysis as they are put together by members at the worksite in the course of the
activity’s occurrence. So the researcher starts to gather materials from the activity
in order to assemble instances of the activity actually being done and, thereby, to
subject the activity to close examination and scrutiny.
Assembling instances of the particular activities that comprise the daily work
of the site lies at the core of the inspection stage of ethnographic research. The
assembly of instances of particular worksite activities being done requires of the
ethnographer that he or she visit and re-visit the work of the site to fill in emergent
gaps in his or her knowledge of the work (video is an excellent tool to support
inspection). Just what is happening there? Just how? These are ever-present
questions in doing inspection and, indeed, those questions drive that work. The
42
requirement to visit and re-visit the work of the site, to consult work as it is done in
order to fill in the gaps in one’s knowledge of it, stands in sharp contrast to a
standard academic practice of filling in gaps through the use of generic analytic
formats to interpret events that occur in the workplace (as will be elaborated in the
following sections). It might be said that if the researcher finds herself in a situation
of using generic analytic formats to interpret just what’s happening and how – that
is, of guessing, no matter how erudite the form – then she is going off track. That
occasions of interpretation emerge is not a bad thing in itself, however, as it might
also be said that the topic of one’s guesswork provides direction to the inspection
work. Insofar as guesswork is occasioned by this (interviewing in placing people in
jobs, say) then this (interviewing work) is what the researcher needs to go back to
and inspect in detail.
Ultimately, inspection work provides for the careful scrutiny of the work of the
site. Thus, instances of particular worksite activities actually being done constitute
the primary unit of analysis (although, as we shall see this is not always the case in
ethnographic research more generally). As Blumer described matters,
Inspection is the opposite of giving a ‘nature’ to the analytic element by
operationalising the element (for example, defining intelligence in terms of the
intelligence quotient). It seeks, instead, to identify the nature of the analytic
element by an intense scrutiny of its instances in the empirical world.
Before one can inspect anything, however, one must have materials with which to
assemble instances of work for inspection.
Assembling Data or Instances for Inspection

In the course of getting the research done, the ethnographer accrues materials from
the worksite - materials that are assembled so as to provide instances of particular
activities of work actually being done, which come to constitute data for analysis.
Simply put, materials are not data for analysis until made so. Just how worksite
materials are transformed into data, and the consequences that work has for the
production of findings, is a matter of some considerable importance. Before
considering the production of findings it is important to consider what the gathering
of worksite materials consists of as a practical job of work, insofar as the materials
gathered come to constitute the focus of analysis from out of which findings
informing the formulation of design solutions are extracted.
In a design context ethnographic work is often characterised by the frenetic
gathering of worksite materials. Note-taking on what is done, heard and overheard
at the worksite is relentless. Sketches, diagrams, and photographs of spaces, places,
and the arrangement of material artefacts (tools, instruments, technologies,
documents, etc.) therein abound. Photocopying of official documents proliferates.
Audio or videotapes of the site’s staff in action amass. This, and more, is the ‘stuff’
of the ethnographic record, the material from out of which an account of the work
of the site, and its organization, is extracted, assembled and compiled. Although a
hectic activity, gathering materials from the worksite is the least of the problems
one encounters in doing ethnographic work, as there is nothing to find that is
43
hidden. Rather, gathering worksite materials consists of looking out for and
recording what is already in plain view. As Rouncefield et al. (1997) point out,
in ‘plain view’ … [means] that there is nothing to see which requires a special
method, a particular instrument, or a special capacity to find. The objective of
the fieldworker is to collect a record of what ordinarily in the ordinary course
of their activities, the persons involved in the setting do.
What kind of materials should be collected in order to make the work of the site
visible then? Well it could be said that whatever can be grabbed from the course of
staffs’ material work that makes the making of their ordinary activities observable
(remember, even the most routine of activities must be constructed anew each and
every time). Thus, in collecting worksite materials the ethnographer’s job is to
listen to the talk, watch what happens, see what people do, when, and where, to
write it down, tape it, copy what documents can be copied, and so on. The
following is an illustrative list of the sorts of useful worksite materials that can be
recorded and collected together.
q Activity or job descriptions.
q Rules and procedures (etc.) said to govern particular activities.
q Descriptions of activities actually being done.
q Recordings of the talk taking place between parties to the actual doing of
activities.
q Informal interviews with participants elaborating particular activities and the
skills, competences, troubles, and practical solutions involved in getting them
done.
q Diagrams of the material arrangement of the space and place within which
staff are located and related, and the arrangement of artefacts therein.
q Photographs of artefacts (documents, diagrams, forms, computers, etc.) used in
the course of activities actually being done.
q Videos of artefacts in actual use (in contrast to prescribe use).
q Descriptions of artefacts in actual use (how artefacts are actually used in
getting the work done).
q Workflow diagrams delineating the sequential order of tasks involved in the
actual doing of particular activities.
q Process maps delineating sequential connections between activities.
All these materials included, one of the most important piece of equipment in
the ethnographer’s toolkit is, without doubt, the notebook (or diary) in which
everything the ethnographer thinks is worth recording is initially put down.
Naturally, the important question is what should be recorded in the notebook and
otherwise attended to when exploring and inspecting worksite activities?
It is necessary, not only to note down those occurrences and details which are
prescribed by tradition and custom to be the essential course of the act, but
also the ethnographer ought to record carefully and precisely, one after the
other, the actions of the actors … With his attention constantly to this aspect
of tribal life, with the constant endeavour to fix it, to express it in terms of
44
actual fact, a good deal of reliable and expressive material finds its way into
his notes. (Malinowski 1922)
While audio and video recordings are particularly useful pieces of equipment,
indeed essential, the humble notebook cannot be dispensed with. The notebook is of
such value because it is here that the ethnographer first records matters of potential
relevance in attending to and describing the actions of actors in the actual doing of
particular worksite activities, thus locating materials in the lived work of the site.
No matter how good support technologies become, they cannot attend to nor
describe the actions of actors anymore than they can identify matters of potential
relevance to design in doing so. Those actions are dependent on the judgement and
expertise of the ethnographer, on his or her sensitivity to the haecceities or lived
details of interaction and collaboration. While audio and video recordings are an
excellent way of preserving action for analysis and may be used to instruct others in
the organization of cooperative work, the humble notebook is of importance as it is
employed to develop a concrete sense of the cooperative work of a site and the
practiced ways in which that work is organized by parties to its accomplishment.
Typically, in the initial stages of fieldwork the notes will appear as little more
than random jottings about possibly interesting situations the ethnographer has
witnessed, snippets of conversation, sketches of what person X and Y did together,
situational vignettes, and so on. As the research progresses, and the researcher gains
a more informed sense of what is going on at the site, such notes may become
longer, more detailed, more structured and coherent. Cooperative topics or themes
(such as ‘interviewing’ in Blau’s study) begin to emerge as the researcher becomes
more and more familiar with the setting, and the research becomes more directed in
the sense that the ethnographer begins to get a better idea of what is important to the
research, what more there is to find out about particular activities and events, and
what more needs to be explored and inspected. Nonetheless, there is no intrinsic
value to the worksite materials gathered. Those materials become valuable insofar
as they can subsequently be made relevant to design through analysis and in terms
of what they show of, and thus allow the researcher to say about, the work of a
setting and its social organization.
Analysing Cooperative Work

As noted above, worksite material does not become data until it is made so. The
purpose of this section is to explicate broad ethnographic methods or work practices
for the production of data and findings. The practicalities of gathering material
concerning the worksite and its constituent activities consists of the production of
textual descriptions and sketched outlines of the ecology of the workplace (its
physical layout), the artefacts used, the activities which take place there, and the
relationship between activities (i.e., how they connect together). Where permission
is given, the ordinary flow of conversation and workplace chat is recorded and
transcribed at a later date, forming an important part of the ethnographic record.
Field notes and audio recordings are accompanied, where appropriate, by the use of
video and still photography, which, in combination with textual description, set out
to portray a concrete sense of the real world, real time organization of the work,
rather than some idealised version of events (Rouncefield et al. 1994).
45
To anyone but the researcher, the composite fieldwork descriptions (the

sketches, texts, transcripts, photographs, etc.) that comprise the ethnographic record
have a tendency to appear idiosyncratic, messy and confusing at first glance. Some
kind of order needs to be brought to bear whereby some intelligible tale of
cooperative work and its organization can be extracted from the raw material and
findings can be made publicly available. The production of data and extraction of
findings from the record is called analysis, which is often conducted through the use
of a classification scheme for interpreting the data. Classification schemes are
provided by the categories that make up generic analytic formats. These categories
are used to ‘code’ the data, a method of analysis that has a long history in
anthropology and social research more generally (Wolcott 1999). The method
consists of reading the narrative an analytic format is constructed of as instructions
that allow the narrative’s analytic categories to be applied to the ethnographic
record. The TAEMS ‘task structure’ narrative (Decker 1996; Lesser et al., unpub.
manu.) provides a relatively simple example.
A TAEMS task structure is essentially an annotated task decomposition tree.
The highest level nodes in the tree, called task groups, represent goals that an
agent may try to achieve. Below a task group there will be a sequence of tasks
and methods which describe how that task group may be performed. Tasks
represent sub-goals, which can be further decomposed in the same manner.
Methods, on the other hand, are terminal, and represent the primitive actions
an agent can perform … The structure above will work out to be a tree
structure containing goals and sub-goals that can be achieved, along with the
primitive methods needed to achieve them. Annotations on a task describe
how its subtasks may be combined to satisfy it. (Lesser et al.)
The codification of workaday activities (e.g. as ‘task groups’, ‘tasks’,
‘primitive methods’, etc.) allows the analyst to identify the social organization of
work (e.g. the ‘task structure’ organizing the work). The work of identification
consists of treating fieldwork descriptions as signs that indicate a type of socially
organized activity (such as a ‘task’). Treated as signs, fieldwork descriptions are
amenable to coding then, where abstract analytic categories are attached to
descriptions of real world activities. Once abstract analytic categories – such as
‘task groups’ and ‘tasks’ - have been attached to these activities it becomes possible
to identify the organization of work (e.g. the ‘task structure’). The social
organization of workaday activities is not so much made visible through
codification then, as rendered apparent through the use of fieldwork descriptions as
signs which function to index some presumed organization of work. It might
otherwise be said that fieldwork descriptions are used as ‘documentary evidences’
that index or point to an underlying organization of activities articulated through the
application of prefigured or a priori classification categories. Garfinkel (1967)
instructs us that the use of this method of analysis consists of
treating an actual appearance as ‘the document of’, as ‘pointing to’, as
‘standing on behalf of’ a presupposed underlying pattern [such as a task
structure composed of task groups, tasks, and primitive methods, etc.]. Not
only is the underlying pattern derived from its individual documentary
evidences, but the individual documentary evidences, in their turn, are
46
interpreted on the basis of ‘what is known’ about the underlying pattern. Each
is used to elaborate the other.
Findings from the codification exercise are made publicly available through
the further use of the analytic format to represent the social organization of work.
Disengaged, impartial, matter of fact, generic analytic formats work through a
particular method of instruction or pedagogy that uses the analytic categories the
format’s narrative is made up of to describe workaday activities as orderly
enterprises (as activities organized in terms of ‘task groups’, ‘tasks’, ‘primitive
methods’, and the rest). Generic analytic formats are employed then, both in the act
of codification and in representing findings to others, to describe the real world
order of work and so configure the social organization of workaday activities in
terms of underlying, analytically available, structures of action (such as ‘task
structures’) which the format’s narrative articulates. Thus, generic analytic formats
are employed to make the social organization of work observable through
associating the components that make up the analytic structure of action (e.g. ‘task
groups’, ‘tasks’, ‘primitive methods’, etc.) with real world referents (ethnographic
descriptions of interviewing in the employment agency, say).
Once this way of analysing and talking about the social order is entertained, it
can be used to grab onto little bits of the observable society, reinterpreted as
illustrations of the master narrative. (Livingston unpub. manu.)
This is the pedagogy of ‘normative’ modes of ethnographic analysis (i.e.,
ethnographic approaches that employ generic analytic formats to describe, analyse
and represent the organization of work). Through the use of the method, texts are
constructed which instruct the reader how to see the social organization of
workaday activities. Such texts make the organization of work ‘instructably
observable’ by grabbing onto little bits of the observable society and using those
bits to elaborate a theoretically constructed account of their organization. These
accounts are over-arching, furnishing generic descriptions of workaday activities as
activities-organized-by-an-underlying-structure-of-action. They may be referred to
as constructive analytic accounts.
The Problem of Constructive Analysis

It might be thought that the purportedly scientific character of constructive analysis
warrants persistence with the approach. A curious feature of the generic analytic
formats offered by the social sciences and employed by many ethnographers to
account for the social organization of workaday activities casts serious doubt on
such claims, however. As the late Harvey Sacks (1963) pointed out, unlike the
generic forms of account offered by the natural sciences or mathematics, individual
and concrete cases cannot be recovered from the generic accounts of the social
sciences. This is because the identification of such things as ‘tasks’ and ‘task
groups’, for example, is not the outcome of recognising natural objects in the world,
such as stones or trees, but the outcome of a complex course of categorisation work.
This means that generic analytic formats are always contestable when applied to
particular cases under the auspices of the ‘et cetera problem’ (ibid.).
47
The et cetera problem recognises that any generic form of account may be
indefinitely extended, although for practical purposes it must be brought to a close.
‘Et cetera’ does just that for practical purposes of writing (or talking) up an
explanation of action and its organization. It is just that point of closure that comes
into dispute, however, in assessing the adequacy of the description offered. More
may be added may it not? Or the adequacy of account itself may be challenged.
Consequently, a refined analytic format accounting for the social organization of
workaday activities is offered, or an alternate one is formulated, each of which is
brought to a close in just the same ways and in the same ways comes into dispute.
Such is the perennial nature of normative social science. Nothing ever gets settled
once and for all as talk proceeds at an abstract and general level under the
unremitting auspices of the et cetera problem. Rather than settling matters, new
intellectual fashions emerge under the et cetera clause that frames normative
discourse in the social sciences, all of which get conducted in the same fundamental
way (Button 1991). That is, through the construction of generic analytic formats in
the attempt to formulate adequate solutions to the et cetera problem; a never-ending
task brought about through the use of generic analytic formats in the first place.
Consequently, given the endless invocation of the et cetera clause brought about
through abstract accounting practices, it is by no means clear that the social
organization of a particular ensemble of workaday activities has been accounted for
when generic analytic formats are employed as instructions for locating and
observing that organization.
The notion of instruction is key: generic analytic formats employed to account
for the organization of activity X do not furnish adequate instructions for the
visibility of X’s organization as they do not describe the particular organizational
features implicated in X’s real world, real time accomplishment. Instead, X is used
as a real world referent to render the constructive analytic account of the
organization of X real worldly (Baccus 1989). Thus, one makes particular concrete
objects – e.g. X in the real world – versions of a generic object – e.g. a ‘task group’
- and in doing so secures a real world referent for a particular analytic structure of
action (e.g. a ‘task structure’). As Blumer (1969) put it,
this conventional protocol of scientific analysis is not suitable or satisfactory
for the kind of analysis that is needed in direct examination of the empirical
social world. Even though using the more realistic data yielded by exploration,
the conventional protocol of scientific analysis still forces such data into an
artificial framework that seriously limits and impairs genuine empirical
analysis.
The understanding or knowledge of workaday activities and their organization
generated by normative accounting practices is the product of the ethnographer’s
situated accomplishment of the work practices of constructive analysis. What we
see, then, is not how workaday activities are socially organized by parties to their
accomplishment but how they are said to be organized from the point of view of the
constructive analyst in furnishing accounts generated through the use of generic
analytic formats.
The source of these probative troubles lies in the treatment of composite
fieldwork descriptions or instances. As Garfinkel (1967) points out, coded results
48
are treated as impersonal or disinterested descriptions of witnessed events. The

disinterested, scientific character of coded results, which are the actual material of
constructive analysis qua analysis in contrast to the stuff of the ethnographic record
itself, is seen to be provided by the coding instructions. Coding instructions are
treated as scientific protocols or procedures, which are said to provide for the
rigorous description of the social organization of workaday activities in their
application. Insofar as the ethnographic record is a product of that organization on
any occasion of inquiry (as it is derived from direct observation of workaday
activities), and in so much as the coding instructions are applied to the record of
observed activities, then the coded results are taken to reflect the actual social
organization of workaday activities. Thus, coded results are said to make the social
organization of workaday activities in particular settings visible. As Garfinkel
(1967) describes it however,
Coded results consist of a persuasive version of the socially organized
character of [some setting’s work], regardless of what the actual order is,
perhaps independently of what the actual order is, and even without the
investigator having detected the actual order. Instead … the [constructive
analytic] account may be argued to consist of a socially invented, persuasive,
and proper way of talking about [the setting and its activities] as an orderly
enterprise, since ‘after all’ the account was produced by ‘scientific
procedures’.
Constructive analytic accounts of socially organized activities may be argued to be
socially invented and by implication fictional in that, and precisely because,
normative social science treats coded results
in much the same way that one might treat a person’s report on his own
activities as a feature of his activities. (ibid.)
Such a report does not describe the activities of which it is a feature however - the
activities themselves and the cooperative work practices implicated in their
production and coordination (i.e., in their social organization) remain to be
described. A fortiori, under the auspices of constructive analysis, the social
organization of workaday activities has not yet been described but glossed over
through the scientific rendering of work.
Furthermore, the methodology of constructive analysis denies any prospect of
identifying the real world, real time social organization of workaday activities as
those practices have been designed to satisfy criteria of scientific rigour that are
incongruent with the subject matter of the social sciences (Winch 1988). The
phenomena seen, and thus the understandings generated through the practices of
constructive analysis, are the products of those self-same practices and not of the
practices constitutive of the phenomena itself. As such, normative practices of
constructive analysis can do no other than pass the organization of cooperative
work by. As Livingston (unpub. manu.) puts it,
Ed Rose … once told a story about a bar in Denver. He said it was a bad place:
there were drugs, prostitution, fights, stabbings, shootings. Every once in a
while the local police would stage a raid. They would get together a team and
49
swoop down on the bar. The problem was, every time they did this, they never
found any drugs, prostitution, fights, stabbings, or shootings. As Ed Rose put
it, society was out-to-lunch. Every time the police went to look, the action was
not there .. In classical sociology [and constructive analysis more generally],
society is similarly out-to-lunch.
This is not to ridicule or ironicise constructive analysis but to point out the
limitations of its work practices in the context of ethnographic study broadly
construed. As Armour (1997) puts it, practitioners of constructive analysis
have targeted innumerable phenomena for analysis and that the achievements
of [constructive analysis] are beyond dispute is attested to by its
bibliographies. It has targeted areas for analysis by ‘describing’, ‘specifying’,
‘testifying’, ‘showing’, ‘demonstrating’, and generally supplying adequate
grounds for inference. By its practices a phenomena of order is made
instructably observable.
Making the social organization of workaday activities instructably observable by
providing adequate grounds for inference from a text is the primary achievement of
constructive analysis. Being predicated on inference, the observability of
cooperative arrangements of work is thus provided for through reasonable courses
of instruction: the reasonableness of the matter consisting in the setting up and
association of indexical relations between underlying analytic structures and real
world referents.
Nevertheless, it is fair to say that we may entertain a well-grounded and
warranted problem with constructive analysis. We may do so in that, and precisely
because, the social organization of workaday activities has not yet been described in
the accomplishment of constructive analytic work practices. The classical practices
of constructive analysis systematically gloss, pass-by or obscure the social
organization of workaday activities under the auspices of ‘doing good scientific
work’. Consequently, instead of explicating the social organization of workaday
activities as that organization is observably produced in the day-to-day
collaborations of participants, and by participants, constructive analysis instead
configures the social organization of work as underlying structures (patterns,
processes, networks, and the rest) that are said to shape and thus organize workaday
activities. Constructive analytic structures take precedence and the setting under
study becomes yet another incidental area in which to observe such structures at
work. The ordinary society is, as such, invariably out-to-lunch.
Ultimately, the source of the probative troubles that beset ethnographic
analysis may be located in the substitution of the members’ perspective for the
professional analysts’. With that substitution goes the recognisable (observable and
reportable) social organization of workaday activities and in its place goes the
social organization of workaday activities as seen and understood through the
constructive analyst’s work practices; work practices which describe, analyse and
represent the social organization of workaday activities in terms of generic analytic
formats. In effecting this substitution - real world organization of work for
constructive analytic account of the real world organization of work - constructive
analysis makes the sociality of workaday activities the analyst’s problem. An
50
alternate way of treating the issue is to see the ‘problem of order’, of social
organization or cooperation, as a members’ problem (Zimmerman and Wieder
1973). That is, as the problem of parties to interaction and the accomplishment of
workaday activities. The following section examines two distinct approaches to
ethnographic analysis that have come to prominence within CSCW by treating the
problem of order as a members’ problem.
Analysing Cooperative Work: Sacks and Garfinkel

Sacks’ investigations into the shortcomings of conventional modes of analysis saw
the development of two alternate modes, one of which unwittingly takes the analyst
up the constructive analytic path under the auspices of Conversation Analysis
(Lynch and Bogen 1994), and another developed by Harold Garfinkel in light of
comments by Sacks, which eschews the use of generic analytic formats entirely.
This latter approach to analysis was initially characterised as ‘ethnomethodology’,
an analytic approach that has evolved over time under the auspices of the radical
studies of work programme (Garfinkel and Wieder 1992) or, more simply, studies
of work. The studies of work programme was inspired by Sacks’ recognition that
constructive analytic accounts ignore the real world, real time interactional and
collaborative work whereby workaday activities come to assume their distinctive
character as organized activities. As Garfinkel puts it,
Harvey Sacks speaks of a curiosity in the work and history of the social
sciences: the ‘missing interactional what’ in lay and professional studies of
organization. Several observable phenomena make specific what he is talking
about. 1) Available for observation is the omnipresence of accountable
organizations of commonplace activities like ‘families’, ‘faculties’, ‘traffic’,
‘welfare agencies’, ‘hospitals’, ‘manufacturing plants’, ‘city governments’, or
‘street gangs’. 2) It is a matter for observation too that endlessly many
inquiries accompany these accountable organizations as constituent features of
them. It is to be observed in these accountable organizations and their
inquiries that the occasioned, embodied, interactional just-so just-what of
ordinary activities remains … ignored, unknown, unsuspected, and unmissed
as technical phenomena. 3) Finally, there is to be observed that 1) and 2) taken
together compose a technical phenomenon that is discoverable, is
consequential, and for the study of naturally organized activities is criterial.
The phenomenon consists of the essential, used, and ignored relevance to the
collaborated production of the orderliness … [of] ordinary activities, of the
occasioned, embodied, interactional just-so-and-just-what of ordinary
activities. (Garfinkel unpub. manu. 1)
It might otherwise be said that in accounting for the organization of ordinary
(workaday) activities, the social sciences pass by, ignore, and otherwise fail to
describe (and thus miss) the observable and reportable collaborative work of the
streets through the accomplishment of which people construct and produce
accountable organizations of commonplace activities: like ‘families’, ‘faculties’,
‘traffic’, ‘welfare agencies’, ‘hospitals’, ‘manufacturing plants’, ‘city governments’,
‘street gangs’, and the rest (Garfinkel and Sacks 1970). It was plain to Garfinkel
51
and Sacks, then, that there was a significant gap in the social science literature and
it is this that their pioneering work set out to address.
The gap in the literature provided a common focus for the study of naturally
organized (rather than theoretically organized) activities, providing the opportunity
to develop a rigorous empirical approach to the study of cooperative work and its
organization, particularly through exploring the notion of ‘member’.
The notion of ‘member’ is at the heart of the matter. We do not use the term
‘member’ to refer to a person. It refers instead to mastery of natural language,
which we understand in the following way.
We offer the observation that persons, in that they are heard to speaking a
natural language, somehow are heard to be engaged in the objective
production and objective display of commonsense knowledge of everyday
activities as observable and reportable phenomena. We ask what it is about
natural language that permits speakers or auditors, and in other ways to
witness, the objective production and objective display of commonsense
knowledge, and of practical circumstances, practical action, and practical
sociological reasoning as well? What is it about natural language that makes
these phenomena observable-reportable, i.e., account-able phenomena? …
The interests of [our] research are directed to provide, through detailed
analyses, that account-able phenomena are through and through practical
accomplishments. We shall speak of ‘the work’ of that accomplishment in
order to gain the emphasis for it of an ongoing course of action. ‘The work’ is
done as assemblages of practices … (Garfinkel and Sacks 1970)
With the notion of member, the missing interactional what of organizational studies
is specified as assemblages of work practices. Which is to say that naturally
organized workaday activities come to assume their distinctive character as
organized activities through discrete ensembles of work practices. Work practices
are made available as accountable phenomena – i.e., as observable empirical
phenomena that may be reported or described - through the naturally occurring talk
of parties to the work. Thus, the organization of cooperative work may be
accounted for empirically, and in the first instance, by attending to the talk of
parties to the work, and in the second instance, by explicating the work practices
made visible through that talk.
Conversation Analysis
Sacks approached the study of cooperative work and its organization through the
development of Conversation Analysis (CA). Without going into undue detail, it is
worth considering CA’s treatment of natural language and analysis of work practice
in order to appreciate the alternative approach developed by Garfinkel.12 At the
heart of CA stands the notion of the ‘turn-taking machine’ (Sacks et al. 1974;
Ruhleder and Jordan 1999).
___________
12
For a thorough review of Conversation Analysis see Lynch (1993).
52
Turn-taking is used for the ordering of moves in games, for allocating political
office, for regulating traffic at intersections, for serving customers at business
establishments, and for talking in interviews, meetings, debates, ceremonies,
conversations, etc. … It is obviously a prominent type of social organization,
one whose instances are implicated in a wide range of other activities. (Sacks
et al. 1974)
Sacks and his colleagues observed that turn-taking was a significant feature of
naturally occurring conversation, which offered the prospect of accounting for the
organization of ordinary activities.
CA construes of natural language as a ‘speech exchange system’ which parties
to conversation employ to assemble and coordinate (i.e., to organize) interaction
through the allocation, management, and control of turns at talk. Sacks and his
colleagues wanted to find out how the speech exchange system enabled
conversationalists to do this. Examining audio-recordings of naturally occurring
talk, it was observed that in conducting conversations, speakers design their talk for
recipients by constructing turns. For example,
Jeanette: Oh you know, Mittie- Gordon, eh- Gordon, Mittie’s husband died
(0.3)
Estelle: Oh whe::n
Jeanette: Well it was in the paper this morning.
Estelle: It wa::s,
? Jeanette: Yeah
Such utterances are said to be made up of turn-constructional components, of which
there are a plethora of unit-types (see Sacks et al. 1974). Turn-constructional
components provide for turn-transition between speakers by providing a transition
relevance place (e.g. It wa::s?) in the unfolding flow of talk. In examining transition
relevance places a discrete group of turn constructional units called turn-allocation
components were identified. For example,
Sara: Ben you want some ( )?
Ben: Well all right I’ll have a,
((pause))
Sara: Bill you want some?
Bill: No.
Turn-allocation components are distributed into two groups: 1) those in which a
next turn is allocated by the current speaker selecting the next speaker (as above),
and 2) those in which a next turn is allocated by self-selection. Questions, greetings,
summonses, invitations, and more, are a special class of turn-allocation components
all of which select a particular recipient who may then speak next. Such utterances
are classed as adjacency pairs. Adjacency pairs consist, as the name suggests, of a
first-pair part (e.g. a question) which is connected to an adjacent second-pair part
(e.g. an answer). Not only do such devices select next speaker but they establish the
sense of the relevant type of action to be produced in response. This is not say that
the selected speaker will respond in the prompted way, only that turn transitions
53
may, and often are, assembled and coordinated through the use of adjacency pairs.
Insofar as the selected speaker may not respond accordingly, adjacency pairs are
said to be ‘conditionally relevant’. That is, they organize turns at talk on condition
that the selected speaker also finds the prompted action relevant as well.
Alternately, persons engaged in conversation may self-select at the projected end of
the current speaker’s story, joke, answer, or any other type of utterance that does
not select a particular recipient.
The use of both groups of turn -constructional units is governed by some basic
rules for their application. Sacks et al. (1974) described these rules as follows:
For any turn, at the initial transition relevance place of an initial turn-
constructional unit:
If the turn-so-far is so constructed as to involve the use of a ‘current
speaker selects next’ technique, then the party so selected has the right
and is obliged to take next turn to speak; no others have such rights or
obligations, and transfer occurs at that place.
If the turn-so-far is so constructed as not to involve the use of a ‘current
speaker selects next’ technique, then self-selection for next speakership
may, but need not, be instituted; first starter acquires rights to a turn, and
transfer occurs at that place.
If the turn-so-far is so constructed as not to involve the use of a ‘current
speaker selects next’ technique, then current speaker may, but need not
continue, unless another self-selects.
If, at the initial transition relevance place of an initial turn-constructional unit,
neither 1a nor 1b has operated, and, following the provision of 1c, current
speaker has continued, then the rule-set a-c reapplies at the next transition
relevance place, until transfer is effected.
These rules constrain each of the turn-taking options they provide and are
constrained by one another, defining in their use participants rights and obligations
to speak and listen. Thus the rule-set ensures that the normative conversational
order ‘one speaker at a time’ is produced and accomplished in conversational
settings of all kinds.
Naturally, there are periods in any conversation when more than one speaker
speaks, when interruptions are made, and when turns at talk are violated in various
ways. Nonetheless, the operation of the rule-set ‘repairs’ violations and restores
normative order. If, for example, a current speaker selects a next speaker (Rule 1a)
and he or she fails to respond, then the current speaker, or some other participant,
may employ components in compliance with the options provided by Rule 1c. The
rule-set not only supports the production and accomplishment of a normative
conversational order, then, but also provides for the maintenance of that order in its
in vivo production. Consequently, Sacks et al. described the basic device organizing
talk as an “interactionally managed, party-administered, local management system”.
It is a local management system in that the turn construction and allocation
components and rules comprising the device allow turn-size and turn-order to vary
according to the local circumstances of conversations’ production, across variations
of participation, and in the face of violations. It is interactionally managed in that
54
turn-allocation and transition is accomplished in concert by parties to the

developing course of each turn and their achieved orientation to a next turn in the
course of the current turn’s production. And it is party administered in that it
subjects the taking of turns to the control of parties to conversation’s talk.
Importantly, Sacks et al. noted that the principle
mechanism by which the system lends itself to party administration, by which
turn-size and turn order determinations are integrated, and by which the
system achieves comprehensiveness for any turn-transition, is the option-cycle
provided by the ordered set of rules.
The underlying rule-set constitutes a coordinating mechanism providing for the
local operation of a generic machinery that enables speakers and hearers to
construct, allocate and manages turns at talk and so organize their interactions.
Thus, Conversation Analysis accounts for the social organization of workaday
activities in terms of a generic ensemble of conversational practices governed by an
underlying rule-based conversational machinery. Just what that organization of
work consists of on any occasion may be explicated by attending to the workings of
the turn-taking machinery as made available by parties to the setting’s talk.
The job of explication may be conducted through specialized methods of
description devised for the job. The most notable of these was developed by Gail
Jefferson (1978). Jefferson devised a generic “transcript format” for the description
of natural language utterances. The format seeks to provide a technical description
that “will look to the eye how it sounds to the ear”, thereby allowing the workings
of the turn-taking machine to be identified. This is achieved through the use of a set
of symbols that track events through a conversation, as in the examples provided
above. Codification symbols would perhaps be a more accurate description of such
devices however, as the following sequence of CA shoptalk serves to demonstrate.
Jon: Does anyone have references for published observations on ‘latching’? I
am wondering if speculation has been made on the interactional work
accomplished by this phenomenon.
Dave: [I think the notion] was used to refer to changes of turns of talk that
were so quick as to show virtually no time lag between the end of the previous
utterance and the beginning of the next. We used a ‘=’ sign at the end of the
last word of the utterance to which the second was latched, and at the
beginning of the first word of the latched utterance. I believe that
nomenclature was in Jefferson’s transcription symbols.
Don: Maybe it’s just me but I cannot make/hear any distinction between
‘changes of turns of talk that (are) so quick as to show virtually no time lag’
and instances of ‘no-gap’ speaker transitions. Consequently, I only use the ‘=’
symbol in my transcripts to indicate a continuation of same speaker’s turn on
another line.
Geoffrey: The latching symbol (=) is meant to indicate those instances of no
gap turn transition ... These are ‘marked’ transitions (because they begin
early) when compared with the majority of transitions (during which a beat of
silence develops between the end of the last turn and the beginning of a next).
(Email extracts cited in Crabtree 2001a)
55
What the talk makes available in observable and reportable details of real
world work practice is that applying transcription symbols is not simply a matter of
mapping the empirical features of talk but a matter of skill and judgement. Just
what does a particular symbol mean? Just when should it be applied and just how?
By way of an answer instructions for the application of transcript symbols are
furnished in CA’s shoptalk (and its texts). In other words the application of
transcription symbols relies on the use of coding instructions which ‘tell’ the user
just how to apply them. Once signs – such as latching symbols - have been attached
to natural language utterances and workaday activities alike through coding it
becomes possible to identify the organization of work (e.g. the turn-taking
machinery in use). The organized character of workaday activities is not so much
made visible through CA then, as rendered apparent through the treatment of
natural language utterances as signs which function to index a presumed underlying
organization of work. CA conducts its daily business not through the explication of
the work practices organizing workaday activities then, but rather, through the
production and interpretation of signs (Garfinkel and Wieder 1992). In other
words, and as Lynch (1993) notes, when pressed, CA is only logically empirical. Its
technologies of production, particularly transcript notation and (of late) Interaction
Analysis (Jordan and Henderson 1995), lend an illusion of rigorous empirical work
which hides a very conventional art (Crabtree 2001a).
Ethnomethodological Analysis
Instead of asking what the turn-taking machinery is doing when members take turns
at talk, pace Conversation Analysis, an alternate approach to the analysis of
cooperative work through natural language use might be to ask what members are
doing when they do taking turns at talk? Lynch (1993) suggests that this analytic
orientation refocuses attention on talk to the work done through talking. As Michael
Moerman (1992) puts it,
talk is not an object of study in its own right. Talk is, rather, the locus,
accomplice, and accomplisher of social organization.
Talk, in other words, is a tool that people use to get their activities done together.
As Wittgenstein (1992) reminds us, in their capacity as tools “words are also
deeds”. Thus, the concern with talk becomes one of what is being done in and
through talking; a matter that goes to the heart of collaborative systems design as it
is the work not the talk of computer users that computers will be embedded in, just
as their talk is embedded in and reflexively elaborates that work. Rather than ask
what it is about talk that engenders coordination then, refocusing the issue directs
our attention to the work people do together in and through talking, thereby
coordinating their actions. Of course the question is: just how might work practice
be analysed through talk then?
Rather than employ some generic analytic format (such as a transcription
format or a classification scheme) the analyst might instead attend to the
conversational formulations produced by members in their talk together (Garfinkel
and Sacks 1970). As Garfinkel and Sacks point out,
56
formulating is an account-able phenomenon. This is to say that (a) it is a

phenomenon that members make happen; that members perform. (b) It is
observable by members. (c) In that members can do the phenomenon and
observe it, it is reportable.
As analysts, we can observe members’ talking, listen to their conversations, and
describe their formulations. We can observe and report members’ formulations not
because we possess some special analytic skill, but because of an ordinary expertise
that we constantly employ in the unfolding and collaborative flow of everyday life.
Conversational formulations are to be found anywhere and everywhere and we can
observe and report them because we are, first and foremost, members ourselves
(being a ‘designer’, a ‘work analyst’, a ‘mother’, etc., comes after). As members,
we are masters of natural language who conduct our everyday affairs with one
another through conversational formulations. Doing and recognising formulations is
a fundamental feature of our ordinary everyday competence then. Indeed we display
(or fail to display) our competence in the practical situations that make up our lives
through doing and recognising formulations. As competent natural language users
we are masters in doing and recognising formulations, hence the fact that we can
hear and subsequently analyse conversational formulations being done by others.
It is notable that when we hear formulations being done one of the things we
hear is what is being done. In others words, in the course of talking together, it is
observable that one of the things that conversationalists do over the course of their
talk is articulate what it is that they are doing, what is going on, what project of
action they are together engaged in here and now. This practical course of
articulation is the object of analytic attention to conversationalists’ talk as it
displays the interaction being engaged in by the parties to the talk and so makes the
cooperative work of the setting available to report and analysis.
Conversational Formulations in the Workplace (The Library Help Desk)
The analytic value of attending to members formulations may best be appreciated
through practical example. An extract of talk that routinely occurs at library help
desks is presented and analysed below. The example is selected because of its
relevance to a design project, which sought to explore ways of supporting the
cooperative work involved in searching for information in libraries; a design case
that is addressed in the following chapters to elaborate the relationship between
ethnomethodologically-informed ethnography and design.
Libraries have long been a site of technical development and have seen the
relatively simple inventory lists of the eighteenth century transformed into complex
cataloguing systems in the nineteenth century, to card-based index systems in the
twentieth century. The development of the computer saw the widespread
implementation of the Online Public Access Catalogue (OPAC) in the early 1970’s
(Hildreth 1982). Ethnographic studies of OPAC use suggest that OPAC works well
in situations where users know in advance what information they are searching for
(Twidale et al. 1997). OPAC is rather less effective, however, in situations where
users do not know what information they require in advance but are interested in a
general topic or theme (a very common situation in the library and other settings).
Users often encounter difficulties in such situations and may turn to the help desk
for assistance. Prior studies of ‘intermediated searching’ (i.e., searching conducted
57
by users in collaboration with help desk staff), and particularly the canonical work
of Robert Taylor (1968), suggest that information requirements are identified in
such situations through sophisticated methods of interrogation.
These methods are difficult to describe, indeed some believe they are
indescribable … [Because] We are dealing here, of course, with a very subtle
problem – how one person tries to find out what another person wants to
know, when the latter cannot describe the need precisely … The negotiation of
reference questions is one of the most complex acts of human communication.
In this act, one person tries to describe for another person not something he
knows, but rather something he doesn’t know. (Taylor 1968)
Taylor described the work of interrogation as ‘filtering work’, which consists
of translating expressions of the information requirement provided by users into
descriptions that fit the library catalogue’s organization. The work of translation is
said to be organized by passing expressions of the information requirement through
five filters, which articulate 1) the general character of the search, 2) the user’s
interest and 3) motivation, 4) the relationship of the inquiry to the catalogue’s
organization (e.g. to literature, science, art, etc.), and 5) what might constitute an
acceptable answer to the query (e.g. information on a particular topic, such as
quantum physics). In providing a constructive analytic account, however, we are
not told how expressions are passed through these five filters and so in the context
of the design case the need arose to inspect the accomplishment of filtering work
directly. The following sequence of naturally occurring talk at the help desk
involves two users and one member of staff. While occurring in a specific setting
and for specific purposes, the organization of that talk provides methodological
insights for the analysis of cooperative work more generally.
Two users approach the help desk.
1. Sarah: Could you tell us where market - what was it - market intelligence?
2. Lisa: Yeah.
3. Sarah: Market intelligence?
4. Sylvia: Marketing is C floor. (Staff points to the OPAC system located at
help the desk) Do you know how to use the screens?
5. Lisa: Yeah but,
6. Sylvia: You need to find the classmark for the book. (Sylvia leaves the help
desk, leads Lisa and Sarah over to a nearby OPAC terminal, and initiates a
title search).
7. Lisa: It’s not a book.
8. Sarah: It’s like information, information about these particular products and
services. It’s called market intelligence and leisure intelligence et cetera et
cetera.
9. Sylvia: And is that the name of,
10. Sarah: That’s the name – market intelligence and leisure intelligence. It’s
not a book as such. It’s usually in the reference library.
11. Sylvia: Is, is it a serial?
12. Lisa: Yeah.
13. Sylvia: It’s a serial. (Sylvia initiates a serial search on OPAC)
58
14. Lisa: It’s a journal.

15. Sarah: It’s not so much a journal but it does come out every few months.
16. Sylvia: (Browsing through the serial search retrieval lis t). Is it marketing
intelligence and planning? Is that the one? (Sylvia points to an item on the
retrieval list).
17. Sylvia: T6 – it’s a journal.
18. Sarah: No. It’s not a journal.
19. Sylvia: Do you want to check at that and find the journal itself? (Sylvia
points to the item’s classmark on the OPAC screen, which tells the users
where the item is located in the library).
20. Sarah: Been there.
21. Sylvia: But have you actually looked at the classmark?
22. Lisa: Yes.
23. Sarah: Yes.
24. Sylvia: You’ve looked at that and it’s not what you’re looking for?
25. Sarah: It’s not what I’m looking for.
26. Sylvia: Right; but that’s the title of the book you’re looking for -
marketing intelligence?
27. Sarah: Market intelligence, and its got a list of all the products and
services - its basically a reference book - it tells you about particular market
products and services and what to look for.
28. Sylvia: You’ve checked in the reference area?
29. Lisa: Well, no.
30. Sylvia: Right. (Sylvia takes the users to the reference area, returning alone
to the help desk some three or four minutes later).
30. Staff: What was it she wanted? What did she ask for?
31. Sylvia: Marketing intelligence.
32. Staff: Marketing intelligence?
33. Sylvia: Which is a joke - she didn’t want that. I eventually got out of her
that it was breweries, which we’ve got in the reference area.
Close attention to members’ conversational formulations instruct the analyst that
the cooperative work of filtering work consist of the following organizational
phenomena.
1. The initial expression of a query in an intermediated search consists of, and is
organized in terms of, the formulation of a specifically vague description of the
information requirement.
2. Lisa: Yeah.
3. Sarah: Market intelligence?
4. Sylvia: Marketing is C floor.
This is a very vague description insofar as it covers many things and so just what is
wanted is not at all clear but at the same time, and without contradiction, it is also
very specific as the information required is, in some yet to be articulated way,
nonetheless understood to be connected to ‘marketing’. The provision or elicitation
59
of a specifically vague description is the first action in an unfolding course of

cooperative work. It serves to circumscribe the search area.
2. Furnishing a specifically vague description does not provide for the
accomplishment of the search, only for the undertaking of a search in cooperation
with help desk staff. In order to find and retrieve information that satisfies the
users’ information requirements, the connection between the search area (e.g.
marketing) and the information requirement stands in need of articulation.
Members’ formulations instruct the analyst that this articulation work consists of
and is organized through a discrete course of categorisation work , where more
detailed descriptions of the information requirement are first elicited and then made
intelligible in terms of the online catalogue’s organization.
6. Sylvia: You need to find the classmark for the book. (Sylvia leaves the help
desk, leads Lisa and Sarah over to a nearby OPAC terminal, and initiates a
title search).
cetera.
9. Sylvia: And is that the name of,
12. Lisa: Yeah.
13. Sylvia: It’s a serial. (Sylvia initiates a serial search on OPAC)
16. Sylvia: (Browsing through the serial search retrieval list). Is it marketing
intelligence and planning? Is that the one? (Sylvia points to an item on the
retrieval list).
In terms of the organization of cooperative work, the shared use of OPAC consists
of the joint formulation of preliminary information requirement categories where
specifically vague descriptions (such as marketing intelligence) are elaborated (as
being ‘about products and services’, ‘marketing and leisure’) and categorised in
terms that fit the catalogue (e.g. as ‘books’, ‘serials’, ‘journals’, and the rest). These
categories serve to elaborate the information requirement.
3. Members’ formulations instruct the analyst that preliminary information
requirement categories are, in turn, used cooperatively as resources providing for
the joint formulation of more specific information requirement categories
identifying candidate categories of solution.
19. Sylvia: Do you want to check at that and find the journal itself? (Sylvia
points to the item’s classmark on the OPAC screen, which tells the users
where the item is located in the library).
60

22. Lisa: Yes.
23. Sarah: Yes.
26. Sylvia: Right; but that’s the title of the book you’re looking for -
marketing intelligence?
27. Sarah: Market intelligence, and its got a list of all the products and
services - its basically a reference book - it tells you about particular market
products and services and what to look for.
This course of categorisation work elaborates the information requirement ni
greater detail and so allows users and staff to narrow down the search. Thus, over a
discrete course of categorisation work a vague description such as ‘marketing
intelligence’ is transformed into something ‘about products and services, marketing
and leisure’ and then into something that ‘lists products and services’ and a
‘reference book’ about ‘breweries’ to be precise. Thus, the joint formulation of
specific information requirement categories allows staff to focus down on a
particular part of the catalogue and identify the information required.
4. Members’ formulations instruct the analyst that categorisation work may be a
practically troubled affair, when users and staff find it difficult to formulate a
shared category of inquiry (is it a book, serial, journal, what?). The search cannot
continue in the absence of shared categories of inquiry and staff elicit users’ search
histories in order to identify shared categories and so elaborate and refine the
search.
22. Lisa: Yes.
23. Sarah: Yes.
28. Sylvia: You’ve checked in the reference area?
29. Lisa: Well, no.
30. Sylvia: Right. (Sylvia takes the users to the reference area, returning alone
to the help desk some three or four minutes later).
Search histories are appealed to and elicited as a matter of course when
categorisation problems arise in the accomplishment of filtering work. The appeal
to search histories both eliminates certain search areas and elaborates the search by
furnishing new categories of information (Crabtree et al. 1997).
General Methodology: Thick Description

This account of filtering work is not exhaustive but illustrative of analytic method.
It shows that members’ formulations make cooperative work and the real world,
real time practices organizing that work, visible. Formulations implicated in the
accomplishment of filtering work show that filtering work consists of the
61
formulation of specifically vague descriptions, which are transformed through

appeals to the users search history and the formulation of preliminary and more
specific information requirement categories into descriptions that fit the library
catalogue (in contrast to a number of analytically constructed filters). The practices
organizing this work are not distinct from the work but identical to it (Garfinkel
1996). The notion of work practice draws our attention to the practical courses of
action (such as the formulation of specifically vague descriptions, etc.) that are
recurrently engaged in order to get the job (e.g. filtering work) done and so organize
the day-to-day accomplishment of the work. No special methods are required to
identify these practical courses of action, what is needed instead is ‘thick
description’ (Ryle 1971).
Thick description stands in contrast to thin description and delineates the
difference between mere behavioural accounts describing only what can be seen
literally and those characteristics which identify some action as the action it
recognisably is for members. As Ryle puts it,
[the] thinnest description of what the person is doing, e.g. pencilling a line or
dot on paper … requires a thickening, often a multiple thickening, of a
perfectly specific kind before it amounts to an account of what the person is
trying to accomplish, e.g. design a new rigging for a yacht.
The notion of thick description draws attention to the need for “multiple thickening
of a perfectly specific kind” when describing workaday activities. This thickening
specifically requires that the analyst describe the ‘accomplishment levels’
implicated in work’s observable production and recognition. The accomplishment
levels relevant to the analysis of cooperative work consist of the description of
members’ formulations as they are hearably produced and recognised in situ by
parties to their production and recognition (as questions, answers, greetings,
arguments, etc.). No special transcript formats are required here as the aim is to
convey the ordinary meaning of what was said, and in the ordinary ways that it was
said, rather than provide technical accounts. Ordinary textual practices of
description are perfectly fit for the job and, unlike Conversation Analysis, provide
for widespread intelligibility of the text. The second accomplishment level requires
that the analyst describe relevant non-verbal practical actions, particularly those
involving material resources or artefacts (such as OPAC use, for example) if the
account is to be coherent and meaningful. Accomplishment level two makes the
real world, real time use of technology visible and available to analysis then.
Descriptions of relevant non-verbal, technologically-mediated actions should be
woven into the description of members’ formulations in the places that they occur.
When assembling data or instances for inspection it is towards providing materials
supporting the description of these two accomplishment levels that the analyst
should be particularly concerned.13
___________
13
Photographic and video material is particularly useful when addressing
accomplishment level two and may be interwoven with members’ formulations to
elaborate the material resources and artefacts implicated in the work (Crabtree
2001b).
62
The third accomplishment level requires that the analyst describe the work
practices made visible by members’ formulations and relevant non-vocal actions.
The analyst may achieve this by attending to two general features of work. In the
first instance, the analyst may note that work is sequentially organized, having a
beginning, a middle, and end at its most basic level. In the second instance, and
insofar as work has a beginning, middle and end, then work might be said to be
composed of component events. The organization of cooperative work might be
explicated then, by attending to the sequential structure of work and describing the
component events that structure is made up of.
Technically, social phenomenon are not simply sequential organizations
consisting of component events. They are, in addition, 1) situated; 2) available
to inspection by and to be done by members; 3) contingent practical
achievements; 4) unavoidably collaborative; 5) practiced productions – those
practices being ‘unique’ or essentially tied to the phenomenon’s production; 6)
those unique practices visibly provide in the course of the phenomenon’s
occurrence for its analysability; 7) they contingently occasion practical
troubles which are repaired in ‘characteristic detail’ as a feature of their stable
achievement. (Garfinkel unpub. manu. 2)
As Garfinkel points out, description of the component events that make up the
sequential structure of work serves to elaborate the unique work practices through
the accomplishment of which workaday activities come to assume their distinctive
organized character. It is, for example, through the concerted formulation of
specifically vague descriptions, preliminary and more specific information
requirement categories, and the appeal to the user’s search history in times of
trouble, that filtering work in the library comes to assume its distinctive character as
an organized job of cooperative work. Furthermore, it is through the
accomp lishment of these work practices that filtering work is made into a stable
achievement – an activity that may be undertaken time and again, day after day, and
which others may be trained in and for other reasons instructed in if needs be. This
is not to say that work practice is immutable, after all, the historical development of
the library instructs us that work practice changes over time. It is to say that given
the current Organization of Work in some setting, the work of the site is stably
organized through a particular assemblage of work practices that the analyst may
identify through direct observation of the work and description of accomplishment
levels one through to three.14
The notion of thick description is not to be taken as a claim to have furnished a
complete and exhaustive description of all the factors involved in work’s
organization. As Ryle reminds us, “there is no top step on the stairway of
accomplishment levels” and so any description may be infinitely extended. For
purposes of studying and analysing cooperative work, however, the assembly and
___________
14
In keeping with the edicts of Ryle’s original exposition, the unique focus on the
‘description of accomplishment levels’, rather than on the ‘inscription of structures
of signification’, sets this reading of the notion of thick description apart from
Clifford Geertz’s popular misreading of Ryle’s work.
63
inspection of instances of work is adequate insofar as the description of

accomplishment levels one to three makes it visible how workaday activities are put
together by participants in the course of their interactions and what the putting
together or co-construction of workaday activities therefore relies upon.15 Thick
description of the three accomplishment levels is adequate, then, as the levels make
available the missing interactional what of organizational studies, an
accomplishment which confounds generic analytic forms of account or explanation
more generally. As Garfinkel (1996) puts it,
Just-in-any-actual-case immortal ordinary society is a wonderful beast.
Evidently and just in any actual case, God knows how it is put together. The
principal formal analytic devices currently in hand, of paying careful attention
to the use, the design, and administration of generic representational theorising
[i.e., generic analytic formats] … get a job done that with the same technical
skills in administering them lose the very phenomena that they profess …
[The] immortal ordinary society evidently, just in any actual case … is only
discoverable. It is not imaginable. It cannot be imagined but is only actually
found out, and just in any actual case. The way it is done is everything it can
consist of and imagined descriptions cannot capture this detail.
Explanation – imagining in Garfinkel’s terms or constructing generic analytic
formats – cannot capture the lived work whereby workaday activities are put
together and organized by participants in their collaborations. There is, then, a clear
need to consider the lived, socially organized work of a setting in and of itself and
not in other terms when studying Work and Organization for purposes of design, as
it is this work that the accomplishment of Organizational objectives rely upon and
that systems will inevitably be embedded in and change. Predicated on thick
description, rather than generic analytic formats made up of a priori analytic
categories, the studies of work programme is unique in its concern to explicate and
represent the lived ways in which work is organized by parties to its
accomplishment.16
___________
15
Naturally, when dealing with a discrete ensemble of workaday activities,
instances must be assembled to analyse the individual workaday activities that
make up that ensemble or working division of labour (Crabtree 2000a). Instances
‘latch together’ to elaborate the working division of labour and in doing so,
elaborate the flow of work through the division of labour. Thus instances may be
employed to illuminate both discrete work processes and information processes in
the workplace while preserving the naturally organized ways in which those
processes are produced (Crabtree et al. 2001). In this way instances support the
production of design abstractions which are grounded in the actual organization of
work. In all cases, the social organization of work may be analysed through the
assembly of instances meeting the requirements of accomplishment levels one
through to three, whether the setting is small or large in scale (Christensen et al.
1998).
16
It might be argued that the method of analysis outlined above constitutes a
generic analytic format. This is not the case however, for while it provides a general
64
Representing Cooperative Work

Rather than embed thick descriptions of work in the master narratives that make up
generic analytic formats, accounts of the social organization of work might instead
be made publicly available through the construction of instances as first segments
of Lebenswelt Pairs (Crabtree 2001b; Garfinkel and Wieder 1992; Livingston
1987). The strong notion of Lebenswelt Pairs is derived from Edmund Husserl’s
Phenomenology (1970). Husserl was concerned to explicate the “genetic origins of
independent Galilean objects” in coherent details of human praxis. By independent
Galilean objects Husserl refers to things that exist independently of the individual;
things that comprise the world ‘out there’; things which are the objects of the
sciences, and more mundane reasoning.17 Husserl’s injunction to take account of the
genetic origins of independent Galilean objects is an injunction to return to the
prescientific or pre-constructive analytic world (pre-analytic world for short) of real
observable work whereby independent Galilean objects are produced and
recognised. In calling for a return to the pre-analytic, Husserl argues that the
scientist (natural or social) dresses up the objects of everyday life (be it the social
organization of work or the phenomenon of natural science) in “a garb of ideas” or
“symbols and symbolic forms” which are used to represent that world, to dress it up
as “objectively actual and true”. Husserl’s is a call to suspend constructive analytic
idealizations of the world however, and to return to the “vital practices” through
the accomplishment of which independent Galilean objects come to be produced
and recognised in the practical actions of members in everyday life (including the
actions of the scientist, natural or social). These vital practices are “forgotten” by
the scientist; so much noise to be ignored and the vacuum filled with abstract
principles of scientific method and constructive analytic accounts.
It might otherwise be said that independent Galilean objects do not simply
exist ‘out there’ but are potters objects made available to human beings in and
through particular assemblages of work practice; assemblages that are reflexively
productive of particular fields of human endeavour: of physics, maths, sociology,
software engineering, searching in the library, and the rest. This is not to say that
___________
format for analysing and identifying the organization of cooperative work in a wide
range of settings, it is content free. It provides no analytic categories with which to
describe work but instead instructs the analyst to attend to certain features of work
in order to conduct description and analysis. Just what the organization of work will
look like is not preconfigured, then, but left to the analyst to explicate by following
the instructions. The problem of constructive analysis is thus avoided.
17
It may seem strange to think of the objects of natural science (and mathematics)
as having a genetic origin in human praxis. A momentary pause for reflection
reminds us however, that is only in and through their collaborative work that
scientists (and mathematicians) make their discoveries of independent Galilean
objects (Garfinkel et al. 1981). It is in this respect, then, that it makes sense to speak
of independent Galilean objects being produced in, and recognised through, human
praxis. The natural sciences are as much fields of practical action as any thing else
and subject to work study as such (ibid.).
65
independent Galilean objects only exist as a result of human praxis. That human
praxis casts and recasts the real world of things concrete. Rather it is draw attention
to what we already know but too often forget, namely that the real world of things
concrete only exists for human beings as a result of human praxis, and as praxis
changes so does our understanding of the real world of things concrete. Thus,
independent Galilean objects are cultural objects through and through; objects
which are accountably constituted in and through human praxis. Independent
Galilean objects and human work practices are intertwined creatures then, and it is
recognition of this irremediable relationship that underpins the strong notion of
Lebenswelt Pairs (Garfinkel et al. 1981).
Specifically, for any independent Galilean object, the first segment of a
Lebenswelt Pair of segments – the instance - is a description of the lived work
involved in the object’s observable and reportable production and recognition
(Garfinkel unpub. manu. 3). Thus, the strong notion of Lebenswelt Pairs situates
description in discrete assemblages of materially embodied work practices, in
contrast to abstract rules of method, bodies of ideas, formulae, formal structures,
generic analytic formats, and other theoretical and metatheoretical formulations
regarding the social organization of workaday activities (Lynch 1993). As such,
instances may be viewed as
Corrigible claims written as sketch accounts [which are to be] read
praxiologically as first segments of lebenswelt pairs (Garfinkel and Wieder
1992).
Garfinkel (1996) elsewhere describes the significance of this statement as follows.
In endlessly many disciplines, as local occasion demands, practitioners are
required to read descriptive accounts alternately as instructions …
The [Ethnomethodological] EM catalogue examines … various ways in
which an account … can be read alternatively so that the reading provides for
a phenomenon in two constituent segments of a pair: 1) the-first-segment-of-a-
pair, which consists of a collection of instructions; and 2) the work, just in any
actual case of following which somehow turns the first segment into a
description of the pair.
Call 2) the-second-segment-of-a-pair. Call the pair an instructed action,
and call the work of reading a descriptive account, as related constituents of an
instructed action, “praxiologizing” descriptive accounts.
For both technologies of social analysis [Constructive Analysis and EM]
… somehow is key. Both CA and EM are preoccupied with … empirically
specifying praxiologizing’s work. Both seek to replace somehow with an
instructably observable just how. Each does so with distinctive policies and
methods …
Characteristically, CA does the specifying job by designing and
administering generically theorised formats … EM does the specifying job
differently … [in describing the] haecceities that constitute … the phenomenal
fields of ordinary human ‘jobs’ … as work-site specific practices of shopwork
and shoptalk.
66
With praxiologizing’s work we reach the nub of what the probative description of
cooperative work amounts to and turns upon. As noted earlier, constructive analysis
attempts to make the social organization of work instructably observable and thus
publicly available through inference from generic analytic formats. In sharp
contrast, in assembling instances as first segments of Lebenswelt Pairs,
ethnomethodology attempts to make independent Galilean objects instructably
observable through description of sequential orders of lived work and the unique
work practices involved in that object’s (e.g. filtering work’s) actual production and
recognition. Treated in the reading as instructed actions, the sequential orders of
cooperative work practices described by the instance display the object and make it
recognisable: the reader may go out and look and see 1) if the object exists and 2) if
the description of its organization is correct. The recognisability of the object
provides for the corrigibility of the account, which in turn provides for its
validation.
Thus, the validity of organizational accounts is provided for by practitioners
rather than by abstract a priori criteria specified by analysts who have neither
encountered nor considered the particular job of work in question. Practitioners
possess the practical know-how to produce and recognise the object described and
may, therefore, concur with or refute its description. Probativeness turns on the
description of the practical competence and expertise whereby membership is
produced and recognised, then, in the craftful accomplishment of workaday
activities, and not in abstract principles of method. The ethnomethodologically-
informed ethnographer’s job is to represent that craft in coherent details of the
unique work practices made visible in members’ shopwork and shoptalk. It might
otherwise be said that when investigating cooperative work in some setting and
accounting for its organization, the ethnographer must satisfy the unique adequacy
requirement.
The Unique Adequacy Requirement

The unique adequacy requirement stands in direct opposition to the requirements of
constructive analysis, as it excludes the use of preconfigured analytic formats. From
an ethnomethodological point of view the analyst should be indifferent to claims
made for the use of a priori methods (Lynch 1993) as the real world organization of
work can neither be identified through such methods nor its existence demonstrated
in the established terms of normative studies of work (Garfinkel 1991).
[T]he unique adequacy requirement … is identical with the requirement that
for analysts to recognise, or identify, or follow the development of, or describe
phenomena of order in local production of coherent detail the analyst must be
vulgarly competent in the local production and reflexively natural
accountability of the phenomena of order he [or she] is ‘studying’. We will
replace the abbreviation ‘studying’ with the specific requirement that the
analyst be, with others, in a concerted competence of methods [i.e., work
practices] with which to recognise, identify, follow, display, and describe
phenomena of order in local productions of coherent detail. These [work
practices] are uniquely possessed in, and as of, the object’s endogenous local
production and natural accountability. (Garfinkel and Wieder 1992)
67
The insistence that the work analyst eschew normative methods (i.e., constructive
analytic practices) and develop ‘vulgar competence’ in the cooperative work under
study is an insistence that the analyst be able to recognise work practice as members
recognise it in the first instance. In other words, it is an insistence that the analyst
develop an intimate familiarity with the cooperative work under study such that he
or she can see the endogenous sense of just what is being said and done, and in the
ways that it is being said and done. This requirement sits uncomfortably with
normative social science, which prefers to gloss over work practice and predicate
organizational change on what ought to be given the ideological agenda of the day.
The simple fact remains, however, that appropriate organizational change cannot be
implemented if the object of change is not explicitly and adequately understood in
the first instance (Sharrock 1980). With an eye towards implementing appropriate
organizational change through technology design, the development of a vulgar
competence in the work practice under study enables the analyst to deliver an
account of the social organization of work in coherent detail – i.e., an account that
is intelligible to competent members or practitioners and which may corroborated
by them.18
An example may help the reader appreciate the fundamental importance of
developing vulgar competence in work practice in order to satisfy the unique
adequacy requirement. Paul ten Have tells us of the following study:
A few years ago, in a data session in Amsterdam, we were discussing some
materials on a medical consultation’s diagnostic phase. The patient voiced a
number of complaints and we felt that the physician was not taking some of
these up. One of us, however, Charon Pierson, of the School of Nursing of the
University of Hawaii and a student and collaborator of Britt Robillard, used
her professional expertise to point out that some of his subsequent questions
were motivated by some of the complaints we thought he did not attend to. In
other words, from a professional perspective, he was working on those
complaints, but this was not noticeable for us, non-medical overhearers, and
indeed for the patient. So from a Conversation Analytic perspective, we could
understand some of the patient’s repetitions of her complaints as dealing with
‘notable absences’ on the doctor’s part, while we were not getting the fine
details of his ‘diagnostic work’ qua professional practice. (Email
communication cited in Crabtree 2000b)
Charon Pierson was, and is, vulgarly competent in the work practice under study,
that’s why she could hear and otherwise recognise what was going on and why the
other analysts could not (or rather, could only recognise that aspect of the work that
fell under their competence as ordinary memb ers of society; competence they
___________
18
Corroboration may be conducted by presenting studies to members/users or,
alternately, by conducting end-user experiments on prototypes based on work
studies and designed to support members’ work-practices. This latter method may
be more useful to design as it engages the real experts in work’s accomplishment in
direct analysis of the design space. See Chapter 4 for further details.
68
themselves exercise when assuming the patient’s role). Developing competence in

the work under study is as indispensable to the work analyst as it is to the member.
Although generic analytic formats are eschewed as a means of describing,
analysing and representing workaday activities, the unique adequacy requirement
does not to rule out the need for specialized methods. Such methods will be
specialized, however, in the sense that they belong to the workaday activities in
question rather than the analysts’ arsenal. The adequate description, analysis and
representation of the diagnostic phase in medical consultation, for example, will
involve specialized methods of description as it is through such methods that its
phenomena (e.g. cerebral palsy; Parkinson’s disease, autism, etc.) are detected and
made visible. It just so happens that the work practice addressed here (filtering
work in the library) requires no specialized competency or the mastery of special
methods in the same way that medical diagnosis does in order to understand what’s
going and what’s being done. No one needs a higher degree, for example, to do
filtering work or a great many other workaday activities. This is not to say that
filtering work (etc.) does not require a special competency – it does, ordinarily so.
Indeed, it is the ordinary expertise implicated in the accomplishment of filtering
work that makes it readily intelligible to a great many of us, as a great many of us
have had recourse to engage in that work: we are masters of it. The notion of vulgar
competence should not be understood, then, as making a distinction between
‘ordinary’ activities (such as finding a book in a library) and ‘specialized’ activities
(such as conducting medical diagnoses) but as referring to an unrecognised and
essential competence which consists of the mastery of the methods or work
practices for getting the workaday activities in question done.
Vulgar competence is constitutive of membership in all areas of practical
action, is everywhere taken for granted, and as a result is systematically ignored by
the social sciences. Nonetheless, the requirement to develop competence in the
work practice under study is essential to accurate ethnographic reportage as it
provides a solid basis for writing praxiological accounts, which may be analysed
with an eye towards grounding design in concrete use practices. In order to achieve
that goal the analyst needs to become part of the phenomenal field of practical
action that constitutes their object of study. ‘Become part of the phenomenal field’
means this: if the work analyst is to explicate the real world, real time social
organization of work in a setting then she needs to immerse herself in the work of
the setting – administering compliance documents (surveys, questionnaires,
structured interviews, etc.) and generic analytic formats will not do. ‘Immersion’
means this: that the analyst must learn and thereby gain an adequate mastery of the
day-to-day work of the setting as a condition of their studies. ‘Adequate mastery’
means this: that the analyst can recognise as members recognise what is going on in
the phenomenal field of practical action under study and how it is getting done. In
such a way the analyst might develop a vulgar competence in the object of study
(such as filtering work) and may, as such, undertake the writing of praxiological
accounts (sketches of cooperative work and its in real world, real time organization)
which may be verified by members and used to inform design.
69
The Particular Need to Transcend Generic Analytic Formats

The break with generic analytic formats makes members’ methods or work
practices the exclusive topic of analysis, in contrast to abstract structures, processes,
networks, etc. Normative social science has reacted wildly to this ‘radical’ approach
to the study of work, abandoning reasoned dialogue on occasion in favour of
indignant objections and sarcastic caricatures (Coser 1975). More composed
reactions contend that it is not enough to attend to work in situ if one wishes to
understand its organization. If we are to understand the organization of work then
we must understand the wider social, political, and economic context of work
(Giddens 1978), and so generic analytic formats are said to be indispensable to the
work analyst. Even a brief consideration of the general character of generic analytic
formats suggests otherwise, however.
Take Marx’s generic analytic format, for example, a widely known format that
addresses the social, political, and economic context of work. According to this
format, work is organized in terms of the ‘forces of production’. The forces of
production consists of 1) the ‘means of production’ – i.e., the raw materials (land,
minerals, livestock, etc.) of production and the technologies of production (be it
stone axes, steam engines, or computer systems); 2) the ‘relations of production’ –
i.e., the social relationships which tie people together people in the act of
production (such as slave labour, feudal tithes, wage labour, etc.); and 3) the
‘process of production’ – i.e., the concrete mode of production produced through
the combination of the means and relations of production (e.g. feudalism,
capitalism, communism, etc.). Employing this generic analytic format to analyse the
organization of work in his own time Marx observed that capital production is
characterised by the appropriation of the profits made from the products of one
group’s labours (the workers) by another group (the owners of the means of
production). Thus, the organization of work in capitalist societies is characterised as
being fundamentally exploitative, with one group gaining at the expense of the
labours of the other. Furthermore, it is predicted that this state of affairs will
inevitably ‘alienate’ the labour force, producing social tension and conflict that will
propel positive change in the structure of society in the longer term; change that
may be all the more rapidly promoted in making members aware of the exploitative
conditions of their existence.
Whether one agrees with or wishes to dispute Marx’s analysis of capitalism or
the formulation offered here, that would be to miss the point that formulations of
work’s organization produced through the construction of generic analytic formats
inevitably fail to address work in the particular. ‘Work’, it should be noted, is a
gloss on an almost infinite array of different practical activities. Generic analytic
formats ignore difference, however, describing work everywhere in the same
theoretically configured ways. The diverse organizational character of workaday
activities simply cannot be accounted for by generic analytic formats and so it is
evident that such formats are far from indispensable to the work analyst but are
instead, hugely problematic. As Button and Harper (1996) put it,
theoretically generated formulations that typify the ‘sociology of work’ at
large fail to address the details of how that work is ‘put together’, or organized
70
in the actions and interactions of those who perform it as a real time

phenomena. Thus Marx’s description of alienation refers to work per se in
capitalist society and has nothing to say about the way in which recognisable
categories of work are assembled in the real time actions and interactions of
workers.
Recognition of the inability of generic analytic formats to deal with the social
organization of work in the particular have led to the suggestion that the studies of
work programme might support a remedial exercise. The ambition here is to
sensitise normative social science to “core practices of occupational worlds” and to
render them “into objects suitable for treatment in the accounting practices of
professional social science” (Heritage 1984). However, Garfinkel (1996) eschews
any attempt to marry the empirical enterprise with constructive analysis.
There have been authors of ethnomethodological studies whose reputations
were promoted by offering to the members of the worldwide social science
movement ways of upgrading their craft. “Your science is cockeyed. We need
to sit down and diagnose for you just where you’re going wrong.”
Ethnomethodology has yet to deliver promised repairs to [constructive]
analytic social science enterprises without losing its own phenomena … [This
is not to say that EM] has no concern with a remedial expertise and has
nothing to promise or deliver. Ethnomethodology is applied
ethnomethodology. However, its remedial transactions are distinctive to EM
expertise.
That expertise is offered for phenomena whose local, endogenous
production is troubled in ordered phenomenal details of structures. EM does
not offer a remedial expertise that is transcendental to these phenomena. In
these the generality of EM’s remedial expertise is indifferent to (independent
of) the use of policies of generic representational theorising and methods of
constructive analysis
To cut through Garfinkel’s complicated locution, studies of work offer a
remedial expertise to occupations which need, for problematic reasons, to
appreciate the social organization of work in real world detail. Systems design is a
primary but by no means exclusive example of a ‘troubled’ occupation in its efforts
to appreciate and be more responsive to the social circumstances of system usage
(Grudin 1990; Goguen 1993). Studies of work do not offer remedial expertise to
constructive analysis however, for the reason that the two approaches to analysis
are asymmetrical and incommensurate or mutually exclusive (Garfinkel and Wieder
1992). There simply is no middle ground between the two: the analyst either
describes the organization of work abstractly in general theoretical details that are
incidental to the work of the site, or concretely, in recognisable details of the real
world interactions and collaborations that make up and organize the work of the
site. Insofar as the work analyst is concerned to inform the development of
collaborative computing systems that are compatible with the actual circumstances
of their use, the latter course of description, analysis and representation is
defensible course to take.
71
The problem is a methodological one – one of
developing policies and practices of discovering
the social practices in and through which an
organization’s daily business is conducted, and
of relating that discovery in some intelligible
and useful way to designers.
Jon O’Brien
3. Work Studies and Design
Ethnomethodological studies of work are often simply referred to as ethnographic
studies in a design context. In a social science context the term ethnography
delineates little more than a distinction between quantitative and qualitative
methods of social research. As Shapiro (1994), commenting on the limits of
ethnography in CSCW describes matters,
While ‘ethnography’ as a term strikes a useful contrast to traditional methods
of requirements capture, within sociology and anthropology themselves it
denotes rather little. It marks a distinction between quantitative and qualitative
approaches to social science and carries with it a commitment to a period and
degree of immersion in the social setting being studied that is sufficient to
reach a qualitative understanding of what happens there. These are important
matters, but beyond this, ethnography can be put to the service of virtually any
theoretical school: there are, for example, functionalist, structuralist,
interactionist, Weberian and Marxist ethnographies.
This is not the place to explore the differences between such schools of thought. It
is the place, however, to note that the term ethnography denotes neither a unified
method nor a coherent school of thought. Rather, and as Shapiro makes clear, the
term ethnography is a gloss on various and different analytic formats.19 In turning
to ethnography, systems designers are not turning to some distinct coherent entity
then, but to a varied and competing array of analytic formats, not all of them
theoretical in character. One such framework is the ethnomethodological one which
has, to use a phrase of Shapiro’s, ‘dominated CSCW’ in light of Lucy Suchman’s
pioneering work in the field of human-computer communication (Suchman 1987).
As Shapiro puts it in accounting for the format’s purchase in design,
ethnomethodology sets for itself a strict agenda which separates it in certain
ways from most mainstream social science. It insists on a rigorously
descriptive rather than theoretical program, or an explanatory one (in the sense
that most social sciences would understand it). This lends it its strength in
producing rich descriptions of work-in-context
___________
19
One such format of some prominence in HCI and CSCW alike is provided by
Activity Theory (Kuutti 1996). Activity theorists often employ ethnography as a
means of studying their unit of analysis – i.e., activity – in the first instance. In the
second instance they seek to analyse the ethnographic data they gather in terms of
the constructs from which the theory is composed. Constructs such as ‘actions’,
‘operations’, ‘motives’, ‘goals’, and ‘tasks’, etc. In other words, activity theorists
use the generic analytic format furnished by Activity Theory to code and classify the
ethnographic data and thereby grab onto little bits of the real world in order to
render the theory real worldly. The accounts of work practice produced through the
use of Activity Theory – and any other generic analytic format employed to analyse
ethnographic data – are thus subject to the problem of constructive analysis outlined
in Chapter 2.
72
Work Studies and Design
Ethnomethodology rejects theory in order that work-in-context may be appreciated

in concrete detail and that designers may, therefore grasp “what is really going on”
in the course of a piece of work, “what is really the problem” about doing it, and
what instruments might therefore be devised to help resolve these problems
(Hughes et al. 1992). Although the contextual and non-theoretical character of
ethnography has proved to be of great value to designers (Kensing and Simonsen
1997), the approach is not without its own practical problems. As Bardram (1996)
puts it,
From the very beginning, workplace studies have played a prominent role in
the research field of Computer Supported Cooperative Work. They are used to
understand and shed light on work and interaction happening in a workplace
… and as such [have provided] an important insight into the subtleties of ..
socially constructed work practices. Within CSCW the value of these insights
into the social nature of work activities, gained through such workplace
studies, is unquestionable. However, there has been an ongoing dispute in the
field … [as] to the exact value of these often very detailed and specific
investigations of the workplace. Questions like; how effective is the field
study approach for informing [the] design of CSCW systems? How can
typical ethnographic field studies, which take months or years, be done within
the fast pace of systems development? What should they be used for within
the design process? Are they economical, or even practically desirable in a
complex design process? Is it possible to generalize such detailed and narrow
studies into applicable design recommendations? … Questions like these are
often coming from the social scientists themselves.
The Role of Ethnomethodological

Studies of Work in Design
In the first instance, one of the primary roles of ethnography to date has been to
sensitise designers to the sociality of work (e.g. Heath and Luff 1992; Hughes et al.
1994; Bowers et al. 1996); a job, which as Bardram points out, has been admirably
achieved. The purpose of sensitising designers to the sociality of work is not
necessarily one of addressing design issues directly but rather of identifying broader
issues upon which effective design turns - issues to do with what to automate and
what to leave to human skill and judgement, for example? Deciding what to
automate and what to leave to human beings is an important matter, not least
because of the critical consequences of inappropriate design decisions. Predicated
on first-hand observation, ethnographic studies of work are a primary resource in
the effort to identify appropriate target areas for design. That said, and as Bardram
points out, ethnographers have recognised the need for their craft to become far
more responsive to the needs of designers and to the practicalities of design in
particular. In its home territories ethnography is a lengthy and time consuming
exercise whereas design is a fast paced and essentially ‘satisficing’ activity (Shapiro
1994), doing the best it can within constraints of time, budget, and with the
resources to hand. If ethnography is to be incorporated into the already diverse
collection of methods, tools, and techniques used in system design, then it has to be
73
tailored to suit the satisficing character of design. Recognition of this need has seen
the development of a number of discrete yet complimentary strategies, tailoring
ethnography to meet the demands of the design process. These include quick and
dirty ethnography, concurrent ethnography, evaluative ethnography, and re-
examination of studies (Hughes et al. 1994).
Some Practical Strategies for the Use of Ethnography

Quick and Dirty Ethnography
Quick and dirty studies are designed to support scoping activities in design,
particularly in large-scale settings where it is important to get an overview of the
work of the site in as short a time as possible.
Outline project meetings
Short
Short
Short
focus
Shortfocus
focus
focus DEBRIEFING MEETINGS
studies
studies
studies
studies
Scoping document
Figure 7. Quick and Dirty Ethnography (Hughes et al. 1994).

Quick and dirty studies are designed to help designers develop a ‘picture’ of the
workplace in a relatively short time frame and, in so doing, support their strategic
decision making in selecting aspects of work that are important to design. Quick
and dirty studies do not set out to furnish an exhaustive view on the work of the site
but instead seek to map and make visible through the assembly of instances the
working division of labour, the work activities it is composed of, and the major
interdependencies between activities of work. Quick and dirty studies provide a
broad understanding of the work domain in a relatively short period of time (the
relativity of the matter depending on the size of the Organization being studied and
designed for). They provide an informed sense of what the work is like and what it
consists of and may be built upon in an iterative design life cycle to provide a more
focused investigation of the work of the site by undertaking concurrent
ethnographic studies.
74
Concurrent Ethnography
Concurrent ethnography is a parallel process in which investigation of work and
systems design proceed at the same time. Concurrent ethnography was originally
configured to precede design. There is no good reason to exclude design from
pursuing its own inquiries as to systems use in the first instance and the process
may be adapted accordingly.
Ethnographic Systems
study DEBRIEFING MEETINGS
development
System
prototype
Figure 8. Concurrent Ethnography (Hughes et al. 1994).

Following initial investigations, a debriefing meeting is held between the

ethnographer and the designers in order to identify, discuss, and elaborate issues of
relevance to design. Findings in hand, iteration of the prototype may proceed and
further fieldwork may be undertaken with respect to the designers concerns.
Concurrent ethnography is a directed process then, in which each stage of the
fieldwork is intended to target issues raised by designers in debriefings. It is a
process characterised by fieldwork? debreifing? prototype-iteration? fieldwork.
Concurrent ethnography is a very flexible process which may undertaken as and
when required and for as many iterations as required. Having developed a working
prototype, evaluative ethnography may then be undertaken.
Evaluative Ethnography
Evaluative ethnography is a more focussed version of quick and dirty ethnography;
which is to say that it does not require a prolonged period of fieldwork. The purpose
of evaluative ethnography is provide a ‘sanity check’ of design proposals or of an
existing prototype, where analytic emphasis is placed on establishing the ‘work-
ability’ of the proposed design solution – i.e., to assess the proposed solution’s
efficacy in relation to the actual performance of work. Evaluation studies are not
intended to be exhaustive but rather, to assess the prima facie viability of technical
75
solutions as seen and understood from the point of view of work’s accomplishment
and to identify problematic issues that may subsequently emerge. Evaluation
studies may also be extended to support more rigorous assessments of a developed
prototype (an issue that will be addressed in due course).
Initial outline design

or specification
Short ethnographic
study
DEBRIEFING MEETINGS
Amended design
or specification
Figure 9. Evaluative Ethnography (Hughes et al. 1994).

Re-examination of Studies
This is an entirely different order of ethnographic usage, emergent from wider
research endeavours. The purpose here is to assemble a corpus of studies that may
be drawn upon to identify common issues across a variety of domains. Such
findings may be used to sensitise designers to common arrangements of cooperation
in various workplaces and to issues that may therefore be of relevance in particular
kinds of design undertaking. Experience in the field also suggests that it may be
useful to re-examine studies as and when particular problems in a design project
emerge. Being a satisficing activity, oversights are made, aspects of work are
disregarded, certain issues are put on hold or ruled out of scope for the time being,
and so on, and re-examining previous studies conducted in the course of a project
can, on occasion, be a productive way of addressing obstinate design problems.
These four strategies should not be understood as laying out mutually
exclusive or rigidly demarcated approaches to the study and analysis of cooperative
work in design. On the contrary, the four modes of investigation are intended to
complement and shade into one another as design work demands. In contrast to
ethnography’s employment in a social science context, none of the above
approaches require prolonged periods of immersion in the field. While this may be
disconcerting to social science purists, it should be understood and taken seriously
76
that the point of work study in design is not to conduct social science research for
its own sake. Rather, the point is to develop social science ‘methods’ (i.e. analytic
perspectives) in order that designers may develop an awareness of the real world
character of work and do so in a manner that fits in with and enhances their day-to-
day working practices. As Hughes et al. (1994) remind us here,
much can be learned from relatively short periods of fieldwork. Indeed, within
the context of design, and we emphasise this, diminishing returns to fieldwork
set in relatively quickly. In other words, fieldwork of prolonged duration is not
always necessary in that it would be more effective to direct that effort in
accordance with design objectives.
The turn to the social, and ethnomethodologically-informed ethnography in
particular, is not in itself a turn to prolonged courses of social research in design,
but to adapted social science ‘methods’ to provide perspicuous representations of
the sociality of work within the constraints of, and for the for purposes of, design.
Ethnography, as Sharrock (2000) points out, has no strategic role to play in design
then. It offers no radical transformations of design practice (as some have
promised), but acts as the designer’s eyes and ears on the ground. The practical
strategies outlined above represent primary configurations of an empirical approach
to describing, analysing and representing the sociality of work within the flow of
design work . Although these configurations have proved to be effective ways of
weaving ethnographic insights into the design process, they have not passed without
complaint from some quarters, however.
Bardram (1996) suggests, for example, that the ethnographic strategies
outlined above create a problem of
one-way communication between users and designers, meaning that
information is floating from the work practices to the designer, but no
information about the future technology, the use of computers etc., is floating
back to the future users in the workplace.
This is not entirely true as ethnographers often act as communicative agents
between users and designers in the course of conducting fieldwork. Telling users
why they are being studied, for what reasons, and towards what ends, is an essential
part of getting access to the worksite and getting permission to study the work.
Neither is the problem of one-way communication a problem for design per se but
for Participatory Design (Schuler and Namioka 1993). Participatory Design is
dedicated to involving users directly and actively in the process of design. While
ethnography has no objection to direct user involvement in the design process, the
economic realities of design often mitigate against this, as leading advocates of the
Participatory Design movement are well aware (Grønbæk et al. 1997).20
Nonetheless, the problem of one-way communication, and thus the separation of
users and designers, is a significant problem to be reckoned with and it is in this
respect that ethnography has been charged (quite rightly) with misrepresenting itself
as a ‘proxy user’ (Kyng 1995). Such criticisms come in light of comments to the
___________
20
Information about the use practice is not, after all, a free a product in design.
77
effect that ethnographers may act as ‘users champions’ in the early stages of design
(Bentley et al. 1992). More considered reflections on the ethnographer’s role in the
design process recognise that the ethnographer can never know the work domain as
users know it (Hughes et al. 1993). However, it is not (or should not be) the
ethnographer’s responsibility to speak on behalf of or represent users in the political
sense of the word (and Participatory Designers are deeply concerned with the
politics of representation as will be addressed in due course). The ethnographer’s
responsibility is, instead and quite legitimately, one of representing the sociality of
the job in the descriptive and ethical sense of the word (ethical in sense of being
faithful to phenomena and thus describing it a practically adequate fashion, and in
the sense of not putting the persons observed at risk of sanction, etc.). Representing
the sociality of work requires the ethnographer to explicate the work practices
whereby the coordination of workaday activities gets done, day in and day out and
by different production cohorts or members of staff. Thus, the ethnographer is
concerned with portraying those features of work that tie individuals together,
which maintain regardless of particular individuals, and which individuals may,
therefore, find it very difficult to articulate (Crabtree 1998). Knowledge of the
cooperative work practices through which work is organized by parties to the work,
whether those parties be co-located or distributed across space and time, is what the
ethnographer brings to design. The ethnographic methods and strategies outlined
above provide tried and tested methods for accomplishing this goal.
The effort to bring an awareness of the cooperative aspects of work to bear on
design has prompted further complaints from design practitioners regarding the link
between studies of work and design. As one computer scientist describes matters
here,
Look, I don’t care about all this ethno babble, just tell me what to build! All
you ever do is tell me stories. Why is this useful? What can I do with it?
(Cited in Crabtree et al. 1997)
Ethnographers in the field originally responded to the challenge in one of two ways,
attempting to address the requirements problem on the one hand and contesting
ownership of the problem on the other, arguing that it was and is no part of
ethnography’s remit to come up with design solutions. Ethnography’s role is to
‘impart knowledge’ as to the cooperative work of intended users, not to ‘give form’
to potential design-solutions supporting that work (Plowman et al. 1995).
It might be said that those who contested ownership of the problem were right
to do so only in the sense that ethnographers rarely possess the n ecessary technical
competence to formulate design solutions on their own. After all, what constitutes a
solution very much depends on the technology being developed, on the purpose of
design, on the often divergent needs of users, and on a host of other contingent
Organizational factors. The ethnographer cannot sit down, then, and analyse a work
study with an eye towards formulating design solutions as just what constitutes a
solution will be the outcome of considering a host of contingent factors (social,
technical, economic, political, and the rest). This, however, does not rule out a
constructive role for ethnography in the formulation of design solutions. Adopting
any such role will require that ethnographers move beyond ‘imparting knowledge’
to directly inform the construction of design-solutions in collaboration with the
78
other parties to systems development. Indeed, it could be argued with good reason
that satisfying that requirement is essential to the approach’s long-term inclusion in
design. As Shapiro (1993) puts it,
Any role at all for sociologists [anthropologists or ethnographic work analysts
in general] in this field rests on their claim to being in a better position to
identify particular aspects of “what is really going on” in a given field of work
and “what is really the problem” that people encounter in doing it. If this claim
is not sustainable then sociologists [etc.] have no contribution to make to
systems design.
If ethnography cannot actively and constructively support system developers in the
reorganization of work through technology design rather than run for cover then it
has no business in the field. While rightly leaving the actual production of design
solutions to designers, ethnographers are nevertheless obliged to assume a
constructive role in design if their craft is to be of any lasting utility. This means
that the ethnographer will have to rid him or herself of disciplinary baggage and
become a bricoleur in design practice.
Using Ethnography to Give Form to Design

(The Bricoleur’s Craft)
The problem of linking ethnography to design and thus of giving form to design is
primarily a problem of figuring out what work studies mean in a design context. As
ethnographers rarely possess a technical competence, working out what work
studies mean for design requires direct collaboration with designers, involving them
in cooperative analysis of studies of the design space and identification of user
needs. Thus, the problem becomes one of communication – that is, of conveying the
findings of work studies to designers and in readily digestible ways that support
cooperative analysis of the design space. Early work in the field saw the
development of the Designers Note Pad (DNP) as a means of promoting effective
communication between ethnographers and designers (Hughes et al. 2000). DNP is
a flexible hypertext system that supports the rapid construction of directed graphs
used in structured design methods. The tool allows ethnographers to present and
communicate the results of work studies in a way that fits current design practice
then. The presentation of findings is organized through a number of ‘viewpoints’
(Kontonya and Sommerville 1992). Specifically, the ecology of work viewpoint,
the workflow viewpoint, and views of work viewpoint (Hughes et al. 2000).
The Ecology of Work Viewpoint
This viewpoint is concerned with representing the physical layout of the workplace
and the spatial distribution of parties to the work. The purpose of this viewpoint is
to furnish a sense of the physical setting within which the work takes place, the
spatially situated arrangements of cooperation and assistance that obtain between
parties to the work, and the artefacts employed in getting the work done.
79
The Workflow Viewpoint

This viewpoint is concerned with the sequential relationships that hold between
workaday activities; with what the workaday activities are in a setting and how they
connect together to form distinct interrelated processes through the production and
transformation of information over the course of the assembly and coordination of
work. The workflow viewpoint represents distinct process of work and embedded
information processes then.
The Views of Work Viewpoint

This viewpoint is a collection of viewpoints on work, specifically, distributed
coordination, awareness of work, and plans and procedures.
q Distributed coordination is concerned with the ways in which the component
activities of the workflow are coordinated by parties to the work. It is
concerned with how this group of people put this particular job of work
together and coordinate it with the next job in the flow of work.
q Awareness of work is concerned with the ways in which parties to the assembly
and coordination of workaday activities make one another aware of the work
they are engaged in and its status. It is concerned with the ways in which
‘where in the process we are now’ and ‘what needs to be done next’ is
displayed by and for parties to the work in order that they might coordinate
their efforts effectively.
q Plans and procedures is concerned with the specification of Organizational
requirements and controls. In paying attention to distributed coordination and
awareness of work, emphasis is placed on the ways in which – i.e., on the
cooperative work practices through the accomplishment of which –
Organizational requirements are actually met.
Thus, the views of work viewpoint is concerned with ways in which the workflow
is actually produced in the real world, real time actions and interactions of parties to
the work. Each viewpoint is presented in diagrammatic form and linked to relevant
viewpoints. Thus, and for example, the plans and procedures governing a particular
process of work may be linked to the workflow diagram, which may be linked to
the distributed coordination and awareness diagrams, and the ecology diagram. In
the linking of viewpoints, ethnographers may articulate the real world, real time
character of work and embedded information processes, the activities involved, the
cooperation they entail, and the ways in which artefacts are used to get the work
done. The work of articulation is supported through textual annotations attached to
the viewpoint diagrams and-or objects therein. These may describe the real world
work of particular workers assembling and coordinating particular jobs and-or the
use of particular artefacts (computers, documents, files, etc.) embedded within the
workplace, as observed by the ethnographer.
Attempts to marry viewpoints with industry standard notation, specifically the
Unified Modelling Language or UML (Fowler and Scott 1997) have seen the
development of the Coherence Method (Viller and Sommerville 1999). The
intention here is to enable designers to extract systems requirements from the
findings of work studies. The method is predicated on Jacobson’s (1995) use-case
80
driven approach. Use-cases define the work a system should support by describing
the different users or more specifically ‘actor nodes’ of a system, whose work is
defined through a number of ‘use-case nodes’ which combine to form a use-case
model. Actors exist outside the system, whereas use-cases exist inside the system.
Actor nodes are connected to use-case nodes through ‘communication arcs’, which
allow stimuli to be sent between ‘instances’ of the actor classes and use-cases
classes the model is composed of. Instances of actor classes are sequences of
actions engaged in by users in the course of performing particular activities,
withdrawing money from a cash dispenser for example. Instances of use-case
classes are sequences of actions pro duced by the machine in response to user
actions, instructing users to input PIN code, specify the amount of money to be
withdrawn, and checking the user’s balance before issuing money, for example.
Thus, use-cases are sequenced design solutions to sequences of user actions and
interactions. Use-cases are envisioned courses of machine response to concrete user
actions performed on and through a system. They are produced through
observations of work, which are used to sketch out potential design-solution. As
Jacobson describes matters,
Use-case modelling is an important tool to develop an outside view of a
system. Combined with other techniques for human-computer interaction, it
will help us build systems with high usability. Furthermore, it is a powerful
means of communication between different kinds of people participating in
the development work, such as orderers, users, requirements analysts,
designers, and testers.
Formulated use-case models are subsequently employed to construct a formal
analysis model, a design model, an implementation model, and a testing model
(Jacobson et al. 1992). The Coherence Method takes the notion of use-case
modelling, combines it with the viewpoints approach and applies it to the
ethnographic record. Modelling proceeds from the plans and procedures viewpoint
(i.e., from the Organizational viewpoint) but describes observable-reportable
workflows, collaborations, and the artefacts used in terms of sequence diagrams,
thus reconciling formal Organizational requirements with the actual circumstances
of work. The production of sequence diagrams enables designers to identify
sequential orders of action that are the focus of support in design (see Figure 11, for
example). Having identified sequential orders of work, designers may then set
about formulating use-cases to support those sequences of practical action.
Despite its appeal to the engineering mentality, the Coherence Method is not
without its problems. As Sommerville and Viller put it,
Whilst it could be claimed that Coherence has removed the communication
problem between sociologists and software engineers, the effect has been to
shift the problem from one of understanding people in conversation, to
understanding people via the method’s documentation.
While there is much of value to viewpoints and the use-case driven approach, the
Coherence Method does not so much solve the problem of communication as side-
step it. The ethnographer’s job finishes with the structuring of the ethnographic
record in terms of viewpoints, and requirements are identified by designers through
81
the application of standard notation to that organized ensemble of data. This

assumes that designers will see the data in the same way as an ethnographer; that
designers will appreciate the data’s significance in a similar fashion. Unfortunately
this not the case and there is, then, a serious risk that although informed by the real
world, real time organization of cooperative work, designers will formulate perfect
technical solutions to the wrong problems of work.
Ethnographic Record
Controller Pilot Flight strip
Controller: Speedbird 799L there
is a delay at Lambourn, slow
down if you wish and on reaching
Lambourn I will require you at
110 or less. Take the hold at
Lambourn
Pilot: Speedbird 799L, roger hold
at Lambourn.
Controller: Speedbird 799L delays
running at 13-15minutes at the
moment. I’ll try to keep you
advised.
Pilot: Speedbird 799L thank you.
Controller: Speedbird 799L

descend flight level 120.
Pilot: Speedbird 799L roger,

descend flight level 120.
Controller writes it on strip
Figure 10. Identifying sequences of action (Sommerville and Viller 1999).

© 1999, IEEE. Reprinted by permission.
Take the design situation of computer support for Air Traffic Control (ATC)
represented in Figure 11, for example. While design would be right to focus on the
cooperative work of the controller and the pilot, attending in particular to the
sequences of action that take place between the two, it would be a mistake to think
that those sequences identify targets and requirements for computer support. One
might, for example, target the resources used (e.g. the flight strips) and take
requirements to be articulated by the sequences of actions implicated in the use of
those resources (e.g. in the cooperative work of the controller and the pilot). If we
consider the use of the flight strip, a piece of paper about one inch wide and eight
82
inches long, a rather different picture emerges from an ethnographic point of view,
however.
The flight strip is an essential resource in the work of controllers, work that
might be described as “manoeuvring aircraft in an ordered way through the skies”
(Hughes et al. 1988). Seen from a controller’s point of view, manoeuvring aircraft
in an ordered way through the skies first requires that a picture of the skies is
available to work with. ‘Getting the picture’ is of paramount concern to air traffic
controllers and it might be thought that this is a relatively straightforward matter of
consulting the radar. In practice, however, radar is not sufficient for getting a
picture of the skies.
(Fieldnote extract) It would be an impossible job to sit and look at the radar
and look at all the different blips and try to avoid [conflictions] by putting the
aircraft into blank spaces on the radar, so you’ve got to have [some] other
information to tell you what traffic is coming into and going out of your
sector. (Air Traffic Controller)
That other information is furnished by the flight strip, which provides information
concerning the flight path of each individual aircraft.
(Fieldnote extract) From your strips you can find out whether or not there is a
possible confliction and what you can do about it. You then go to your radar
and look for that particular aircraft and see where it is in reference to the
outbound from Heathrow, for example … Then you decide what you’re going
to do with it, whether you are going to go up underneath it, whether you are
going to wait until its gone past, whether, if its on your frequency, whether
you can put them on parallel headings and then you can climb it up to the
other aircraft levels. Same as with the inbounds, it’s the same sort of thing.
Information on the flight strip includes the aircraft name or call sign (e.g. Speedbird
799L), its departure and destination point, its preferred route and height, the type of
aircraft and its speed. The aircraft’s estimated time of arrival at particular
navigation points is printed on the left-hand side of the strip besides the
abbreviation for each navigation point. Each flight sector has three or four key
navigation points and strips are printed and placed in racks or bays next to the
controller’s radar screen some ten minutes or so before each aircraft’s arrival into
each control sector. The flight strip represents an aircraft at each stage of its journey
through a flight sector and, as such, enables the controller to get a picture of the
skies and to work that picture, thereby manoeuvring aircraft in an orderly way
through the skies.
As Hughes et al. (1992) point out, the above is not to say that the strips
determine the sequence of actions undertaken by controllers in working the picture
in the sense that what comes along a production line determines what a line worker
has to do next.
Rather, the controller has to organize the strips so that they can become an
instrument that helps organize, and so make possible, controlling work. Strips
are ‘manipulated’, ‘glanced at’, ‘taken heed of’, ‘ignored’, ‘revised’, and so
on. And not just when they are first placed on the racks, but continuously all
83
the time they are in use. The end result of these activities is that, at any
moment in time, what the strips indicate and create [in their use] is the
sequence of controller actions that results in the achievement of order in the
skies. Thus, management of the strips constitutes a large part of the work that
underscores controlling competence.
Managing or working the strips is the cooperative achievement not only of the
controller and the pilot but also, of the ATC team. When a strip is first printed
(information is initially generated from flight plans submitted by the pilot and
augmented with weather details), the controller’s assistant places it in the
appropriate rack. Placing the flight strip is not a mechanical task but requires that
the assistant check the strip for its accuracy. Errors are not infrequent – the
designated flight path may be inconsistent with the flight number, for example –
and it is the assistant’s responsibility to rectify any visible errors on the strip, which
may well require collaboration with others outside the control room as
contingencies dictate. Having tracked and changed any errors, the assistant may
place the annotated strip or a newly generated strip in the flight rack.
Insofar as the strip is annotated by the assistant then annotations are indicated
by the use of a distinctly coloured pen. Each member of the control team may
annotate the flight strip at any time and each has a different coloured pen so that the
person who made the annotations is immediately identifiable and may be quickly
consulted if needs be. In placing the strip on the rack the assistant does not just put
it anywhere. The rack is organized in terms of two distinct sections: pending and
live. Furthermore, as there is a temporal flow of aircraft into each sector, so in
placing strips into the pending rack the assistant organizes them in terms of time
sequence. More still, in organizing the temporal placement of strips problems may
become apparent – it may be seen that two aircraft are projected to reach the same
navigation point simultaneously and at the same height, for example. On
recognising a potential confliction through the action of placing the strips, the
assistant or any other member of the team indicates the problem by cocking the
problematic strips out of the rack. This makes it immediately obvious to the
controller that when the time comes to deal with those flights that a problem will
have to be considered and, as Hughes et al. (1992) note, to the practiced eye it will
be obvious at-a-glance what the problem is.
Cooperative work on the strips continues once they become live. A strip
usually becomes live on receipt of a radio message from the aircraft crew as it
enters the sector. On receiving this message, the controller removes the strip from
the pending rack and places it in the live section. Once again, placement of the strip
is a highly organized affair. In placing the strip in the live section the controller
places it in that part of the rack designated by the navigation point being used.
Furthermore, just as the assistant orders strips according to time sequence, then so
too does the controller. Thus, as strips become live a temporal flow emerges, with
new strips at the top and old strips at the bottom (or vice versa as the controller
prefers) and from navigation point to navigation point. More still, as and when
strips become live they are colour marked by the controller to indicate that he or she
has moved them. In the course of being live, strips may be replaced by the sector
chief or the assistant with more up-to-date or revised ones. Such replacements lack
84
the controller’s mark and the controller can, then, see at a glance that the strip
requires attention and that its implications be taken on board. The controller also
marks any commands issued to the aircraft on the live strip (as recognised in Figure
11). This provides a publicly available record of just what the controller has done to
date. Finally, as and when the aircraft crosses each navigation point, the controller
crosses through it on the flight strip. This indicates the last point through which the
aircraft passed in the sector. When the aircraft crosses the last navigation point in
the sector the controller directs the aircraft to contact the next sector controller and
then crosses through the strip. This indicates that the controller’s work has been
completed.
Seen from a design perspective, the sequences of action implicated in
organizing the flight strips might identify requirements for a computer-based
artefact replacing the paper strips. That artefact might display automatically
generated flight strip information, annotate changes automatically, automatically
order flight information in pending and live status, display controller’s marks and
the other actions that comprise the discrete sequences implicated in the working of
the strips. However, automation of the flight strips overlooks the fact that the
sequences of action that the working of the strips is composed of are themselves
embedded in and produced through the cooperative work of the ATC team. This is
not a trivial point. As Hughes et al. (1992) inform us, ATC in the UK has the best
record in the world – not a single civil collision has ever been attributed to air
traffic control.
If one looks to see what constitutes this reliability, it cannot be found in any
single element of the system. It is certainly not to be found in the equipment
[radar etc.] … Nor is it to be found in the rules and procedures, which are a
resource for safe operation but which can never cover every circumstance and
condition. Nor is it to be found in the personnel who, though very highly
skilled, motivated and dedicated, are as prone as people everywhere to human
error. Rather, we believe it is to found in the cooperative activities of
controllers across the ‘totality’ of the system, and in particular in the way it
enforces the active engagement of controllers, chiefs and assistants with the
material which they are using and with each other. This constitutes a
continuing check on their own work and a cross-check of that of others.
It might otherwise be said that the reliability of work in the air traffic control suite
is to be found in the cooperative work practices of its staff. Those work practices
are designed by staff to construct a protective cocoon around the controller and in
so doing to provide all the resources required so that the controller can concentrate
exclusively on the work of ordering the skies. That cocoon is not an accidental
construct nor is it a product of a simple division of labour and allocation of tasks.
On the contrary, it is an active construct created moment by moment through the
sequences of action embedded in and produced through the cooperative work of the
ATC team organizing the flight strips. Ordering the skies in a safe manner is the
cooperative accomplishment of the ATC team’s collective working of the flight
strips then. Thus, when considering the social organization of sequences of action it
is important to consider one sequences relation to another (such as the relation of
pilot-controller interaction to controller-assistant interaction). As Viller and
85
Sommerville point out, there is no guarantee that the Coherence Method will be
sensitive to the social relationships and constellations of cooperation and assistance
that shape the work of the setting. This means that although designers may be able
to identify much of relevance to design through the Coherence Method’s
documentation, the work analyst cannot be dispensed with in the ‘creative process
of design’ (Twidale et al. 1993); a situation which again raises the problem of
communication.
A Lingua Franca for Design

Recent efforts in the field have been directed towards establishing a lingua franca
supporting communication between ethnographers, designers, and others involved
in the development process.
lingua franca. 1 a language adopted as a common language between speakers
whose native languages are different. 2 a system for mutual understanding.
(The Concise Oxford Dictionary)
Underpinning the call for a lingua franca in design is the recognition that
ethnographers, designers, and other parties to design conduct their daily business in
different professional languages, a situation which compounds the problem of
communication (Crabtree et al. 2000a; Hughes et al. 2000). Researchers have
consequently emphasised the need to develop a ‘pattern language’ for structuring,
presenting and analysing the findings of work studies (Erickson 2000a). A wide
variety of pattern languages have been developed for various purposes in design,
including those of software engineering (Gamma et al. 1995), HCI (Bayle et al.
1998), and work study (Erickson 2000b). Software engineering and HCI pattern
languages are marked by a concern to address problems encountered in previous
development projects and to make solutions available to the wider community of
practitioners. Pattern languages constructed to support work study eschew the
problem-solution focus and place emphasis instead on the description of common
arrangements of cooperative work (Martin et al. 2001). Such languages are
essentially retrospective in character, re-examining previous ethnographic studies in
order to discover patterns of interaction or cooperation that occur across a variety of
settings.
Recent developments in the field have sought to develop a prospective pattern
language to support communication and cooperative analysis of the design space
(Crabtree et al. 2001b; Crabtree and Rodden 2002). This approach seeks to use a
pattern language as a means of conveying the important details of ongoing work
studies to designers in the flow of design work. Like all other pattern languages in
design, this prospective approach draws on the seminal work of the architect
Christopher Alexander (1979). It is also inspired by existing design practices that
are central to the analysis of the design space. Specifically, the prospective
approach is predicated on Sharrock and Anderson’s (1994) study of how analysis of
the design space and user needs is structured in design practice through the
commonsense method of typification (as discussed in Chapter 1). The method
consists of the appeal to and use of knowledge of patterns of action to provide for
86
cooperative analysis of user needs and to construct an inter-subjective

understanding of the design space.
The commonsense method of typification presupposes the use of formal
methods in design and may be supported through the adaptation of Alexander’s
original architectural framework to structure and present ethnographic findings to
designers. Alexander’s framework is constructed on the foundational observation
that towns and buildings are organized through reoccurring patterns of action (or
“patterns of events” in his own terminology) that people take part in over and over
again. Being in bed, taking a shower, making breakfast, sitting in the study writing,
walking in the garden, eating lunch, going to the movies, taking the family to a
restaurant, having a drink at a friend’s house, driving on the highway, and going to
bed again are examples used by Alexander to illuminate the point. Our lives are
organized through reoccurring patterns of work, leisure, travel, relaxation, and the
rest.
While patterns of action are implicated in the daily lives of individuals, a great
many patterns of action are not individualistic but organize our lives together as
members of society:
they are the rules through which our culture maintains itself, keeps itself alive,
and it is by building our lives out of these patterns of events, that we are
people of our culture.
Thus, and for example, each morning people get up, shower, eat breakfast, and
drive down the highway to work, where they together engage in other patterns of
action, such as checking their mail, attending meetings, or going for lunch, etc. A
great many of the patterns of events whereby towns and buildings are organized are
thoroughly social in character then, and so make the social organization of towns
and buildings visible.
Alexander also observes that patterns of action are tied to particular places
within a society. So taking a shower in a morning is tied to the bathroom, eating
breakfast to the kitchen, driving to work to the highway (and not the sidewalk), for
example. As Alexander puts it, patterns are always anchored in space:
I cannot imagine any pattern without imagining a place where it is happening.
The patterns of action out of which any particular place – a bathroom, a kitchen, a
motorway, a library help desk, etc. – is made up are also rather small or finite and
defined by social convention, which provides for the generalization of the patterns
that occur in a place to other such places in the wider society. Thus, by virtue of
social convention, showering may be generalized to bathrooms, eating breakfast to
kitchens, driving at high speed to motorways, intermediated searching to library
help desks, and so on. Alexander’s framework ties patterns of action to the
architectural environments in which they naturally occur then, and provides a basis
for analysing settings and imp roving towns and buildings
The work of analysis consists of locating the patterns of action that occur in
and across the distinct places that make up a particular setting and of explicating the
patterns of relationships that exist between patterns of action and the material
arrangements of place: between cars and pedestrians crossing the road, between a
person entering a building and the physical entrance, between cooking and the
87
physical layout of the kitchen, etc. (Alexander et al. 1977). Placing analytic
emphasis on patterns of relationships, Alexander draws our attention to the
reoccurring ways in which people interact with their architectural environment and,
particularly, with the material arrangements that it is made up of. These patterns of
relationships are the primary object of pattern analysis in Alexander’s framework.
They elaborate the socially organized ways in which people use the material
arrangements of place and the problems they encounter in the course of use.
Knowledge of patterns and problems is made publicly available, along with
proposed architectural solutions, through the use of a distinct presentation format,
which Alexander describes in the following way.
First, there is a [pattern number, a title and a] picture, which shows an
archetypal example of [a] pattern. Second, after the picture, each pattern has
an introductory paragraph, which sets the context for the pattern, by
explaining how it helps to complete certain larger patterns. Then there are
three diamonds to mark the beginning of the problem. After the diamonds
there is a headline, in bold type. This headline gives the essence of the
problem in one or two sentences. After the headline comes the body of the
problem. This is the longest section. It describes the empirical background of
the pattern, the evidence for its validity, the range of different ways the pattern
can be manifested in a building, and so on. Then, again in bold type, like the
headline, is the solution – the heart of the pattern – which describes the field
of physical and social relationships which are required to solve the stated
problem, in the stated context. This solution is always stated in the form of an
instruction – so that you know exactly what you need to do, to build the
pattern. Then, after the solution, there is a diagram, which shows the solution
in the form of a diagram, with labels to indicate its main components. After
the diagram, another three diamonds, to show that the main body of the pattern
is finished. And finally, after the diamonds there is a paragraph which ties the
pattern to all those smaller patterns in the language which are need to
complete this pattern, to embellish it, to fill it out. (Alexander et al. 1977)
In talking of larger patterns Alexander may be understood to be talking about the
primary patterns that define place – e.g. making breakfast, lunch or dinner in the
kitchen – and in talking of smaller patterns he may be understood to be talking
about the component patterns that make up a primary pattern – e.g. getting
foodstuffs from the refrigerator, implements from drawers, using the cooker or
microwave, cleaning the table, etc. It is in this respect that an adapted patterns
framework and presentation format might be of utility to design. Illuminating
primary and component patterns of events and technological (rather architectural)
relationships identified in ethnographic studies, an adapted framework might
support the commonsense method of typification that underpins analysis of the
design space.
The Adapted Patterns Framework

Refocusing Alexander’s framework to address technological rather than
architectural arrangements of place, allows ethnographers and designers to identify
88
generic (or typical) patterns of relationships that obtain between people and
computers in particular places (such as the library help desk) from out of the
minutia of ethnographic studies; patterns that may be employed to support the
formulation of design solutions. Generalization might be supported by adapting
Alexander’s pattern format to a web-based presentation vehicle. A web-based
format means that much richer resources may be provided to designers than can be
contained in a text and so the ‘archetypal picture’ may be replaced with actual video
footage that displays the pattern in question. The video may be viewed via a
hyperlink embedded in the pattern’s title. The title consists of a commonsense
description (e.g. searching at the help desk). Given the analytic emphasis placed on
relationship of action to technology, a sub-heading key technologies may be added
to the format, listing keywords that describe the technologies used in the video
sequence (e.g. Online Public Access Catalogue, reading list, notes, etc.).
Pattern No. 5 Searching at the Help Desk

[click on hyperlink to view video]
Key Technologies: Online Public Access Catalogue
Figure 11. The ‘Archetypal Picture’.

The ‘introductory paragraph’ is renamed interactional setting of the pattern . This
section briefly describes a) where the pattern occurs; b) who is involved in the
sequence of interaction; c) what the parties to the interaction are doing; and d) the
primary pattern this pattern is a component of (e.g. doing an intermediated search,
where just what is wanted is not known in advance). Hyperlinks in this section
connect the pattern to a primary patterns log, where access to the corpus of
component patterns making up the particular primary pattern in question (e.g.
intermediated searching) is provided (component patterns in intermediated
searching would include user-subject librarian interaction around OPAC and the
collaborative use of the physical catalogue, for example).
89
Interactional Setting of the Pattern

The sequence of interaction on the video takes place at the library help
desk, where users often turn when they cannot find items satisfying their
information requirements. Two users are involved in the interaction along
with a member of staff. Together they try to establish the identity of
specific items that will satisfy the users’ information requirements. The
pattern of action is part of the primary pattern ‘intermediated searching’
[hyperlink to component patterns listed in patterns log], where just what is
wanted is not known in advance.
Figure 12. The ‘Introductory Paragraph’.

The ‘essence of the problem’ is renamed the organizational context and provides a
formal summary of the practical issue addressed by the pattern.
Organizational Context of the Pattern

Library users often turn to the help desk when they cannot find
information satisfying their information requirements Help desk staff
characterise this work with users as ‘getting details out of people’, as
‘trying to find what they are looking for’, or more generally and formally,
as ‘filtering work’. Filtering work is concerned with making user
inquiries intelligible in terms of the library catalogue’s organization in
order that useful materials satisfying users needs might be located. Users
and help desk staff conduct filtering work together through performing a
course of categorisation work in which they work up a concrete sense of
just what is being searched for.
Figure 13. The ‘Essence of the Problem’.
The ‘body of the problem’ is renamed the work of the pattern and describes the
routine activities that make up the pattern. The work is summed up in a synopsis ,
which is followed by a transcript of the talk and description of the relevant non-
verbal practical actions of the parties to the interaction (see Figure 14).
90
???
The Work of the Pattern
Synopsis: Two users approach the help desk and ask staff where a certain
section of the library is. Staff directs them to OPAC and asks them if they
know how to use it. Staff takes them over to OPAC and the users explain that
what it is they are looking for. Their explanation is in the form preliminary
information categories, which staff uses to initiate a search on OPAC. The
three of them employ the OPAC retrieval list to work up more precise
information categories. This enables the users and the librarian to focus down
on a manageable and sufficiently small collection of information in the
catalogue and from that point, to identify and extract information of personal
relevance to the user. Staff takes the users to a section of the library and locates
materials the users are looking for.
Transcript:
2. Lisa: Yeah.
3. Sarah: Market intelligence
4. Sylvia: Marketing is C floor. (Points to OPAC located at help desk) Do you
know how to use the screens?
5. Lisa: Yeah but
6. Sylvia: You need to find the classmark for the book.
Sylvia leaves the help desk, leads the two users (Lisa and Sarah) to a free
OPAC terminal nearby and initiates a title search.
cetera.
9. Sylvia: And is that the name of
12. Lisa: Yeah.
13. Sylvia: It’s a serial.
Sylvia initiates a serial search on OPAC
Sylvia browses the serial search retrieval list
16. Sylvia: Is it marketing intelligence and planning? Is that the one?
Sylvia points to an item on the retrieval list
19. Sylvia: Do you want to check at that and find the journal itself?
Sylvia points to the item’s classmark on the OPAC screen
Figure 14. The ‘Body of the Problem’.
91
The ‘solution’ is renamed the practices ordering the work of the pattern and
articulates the recognisable social practices implicated in the work’s routine
accomplishment. This section describes the familiar, recurring ways in which
routine workaday activities get done. Description of these reoccurring practices
provides for the identification of the pattern.
The Practices Ordering the Work of the Pattern

1. Formulating a specifically vague description. Users initially provide a specifically
vague description of their information requirements or ‘keyword’ (such as “market
intelligence”). Such opening descriptions are very vague insofar as they cover many
things but at the same time, and without contradiction, are also very specific as the
information required is, in some yet to be articulated way, connected to “marketing”.
Library users furnish help desk staff with such descriptions as a matter of course, and so
broadly circumscribe the search area.
2. Formulating preliminary information requirement categories. The connection
between the circumscribed search area (e.g. marketing) and the information
requirement, which is (in part) in the user’s head, needs to be articulated. In articulating
that connection, vague descriptions are transformed into more precise descriptions that
fit the catalogue. The transformation of vague descriptions is accomplished through the
cooperative formulation of preliminary information requirement categories, which
consists of associating vague descriptions with categories that the library catalogue is
composed of. The work of association is often accomplished through the use of OPAC
and allows users and staff to work up candidate categories of solution to the search
problem – that the users information requirements concerning marketing are located in
a journal, for example - thereby narrowing down the search area.
3. Formulating specific information requirement categories. Preliminary information
requirement categories are used in turn and cooperatively to formulate more specific
information requirement categories which enable users and staff to establish just which
journal, for example, will satisfy the information requirement. Again OPAC (and
occasionally other resources to hand such as reading lists, notes and the contents of
shelves) may be used to specify more precisely the nature of the information
requirement. Over the course of this work, preliminary information requirement
categories are often respecified – the information need may change from one located in
a journal to one located in a reference book, for example – and the search area is further
narrowed down.
4. Appealing to immediate user search history to perform categorisation work in
troublesome situations. Searches with help desk staff do not always run smoothly.
Particular troubles arise in formulating specific information requirement categories. In
such cases help staff desk routinely appeal to the users immediate search history (what
they have been looking at prior to turning to the help desk for assistance). In spelling
out in detail just where users have been and just what they have looked at, their search
history is employed by help desk staff both to eliminate areas of the search and to
furnish new resources with which to elaborate and refine the search. Search histories
are appealed to and elicited as a matter of course in the accomplishment of filtering
work, providing for the narrowing down of the search through the cooperative
formulation of specific information requirement categories and location of potentially
suitable search materials.
Figure 15. The ‘Solution’.

92
The ‘diagram’ is replaced with a more appropriate category to the task at hand,
namely the pattern of technology usage. This section of the format describes the
technologies used in the sequence of action as elaborated by the work of the
sequence and the practiced ways in which that work is routinely organized.
The Pattern of Technology Usage

The online catalogue (OPAC) is used to work up information requirement
categories and locate items that may satisfy the user’s requirements. OPAC is a
text -based system that allows vague descriptions of the information
requirement provided by the user to be categorised in terms that fit the library
catalogue. Vague descriptions are made to fit the catalogue through a number
of static categories (“author”, “title”, “journal”, etc.). OPAC provides lists of
bibliographic items in response to queries issued (e.g. “marketing journals”, or
“java titles”, for example), which users work through and employ to generate
more specific information requirement categories and so refine the search.
Notably, OPAC lists are randomly ordered and collect together all items
containing the search terms employed (e.g. “marketing journals”, or “java
titles”). Thus users and help desk staff alike are presented with a vast array of
topics which they must browse through in order to identify materials relevant
to the current search, which takes a great deal of work.
Figure 16. The ‘Diagram’.
The pattern section is moved up and placed after the organizational context of the
pattern. This is done for reasons of relevance, as it is assumed that systems
designers will primarily be interested in the pattern of technology usage. The other
sections may subsequently be read and analysed for their relevance to the pattern.
The ‘tying paragraph’ is renamed connected patterns and uses hyperlinks to
93
connect the pattern to a patterns index, which provides access to any other patterns
in the setting that use the same key technologies and elaborates a bricolage of
patterns of action that coalesce around particular technologies thereby articulating
important sites for design.
OPAC Use
[hyperlink to corpus of patterns of OPAC use listed in patterns index]
Figure 17. The ‘Tying Paragraph’.

Unlike the use of pattern languages in software engineering or HCI, the
adapted format offers no solution to designers (i.e., it doesn’t tell designers what to
build). This is quite intentional for as Vlissides (1997) reminds us,
Clearly, one pattern format does not fit all. What does fit all is the general
concept of pattern as a vehicle for capturing and conveying expertise,
whatever the field.
The structure of the adapted format is relevant to the problem at hand, namely the
requirements problem. No solution is offered by the format as it would conflate the
design task then: before devising technological solutions, we first need to establish
a concrete sense of what is to be built? This means that we need to develop an
intimate familiarity with the work of the site, with what goes and their and how it is
organized? The adapted format is configured to address that question and so
provides shared resources for analysing the design space and reasoning about the
potential role of technology given the observable collaborative work of the site.
The adapted patterns format mediates communication between ethnographers
and designers, providing a common focus for cooperative analysis of the design
space. Patterns highlight important arrangements of cooperative work that the have
been identified in ethnographic studies of the workplace and present these to
designers in an accessible and relatively concise way (relative in respect of the thick
ethnographic texts that are traditionally produced by ethnographers). In a similar
manner to process maps (Crabtree et al. 2001a), patterns also serve to create a
shared inter-subjective sense of the design space among the parties to design. The
adapted framework supports analysis of the design space across the design team by
illuminating the ecologically situated uses of technology and typificatory structures
or common patterns of action that technology use is embedded in. Thus, the
framework enables the members of the design team to identify the local
constellations of cooperation and assistance shaping work in the real world and to
reason about the demands that will be placed on design solutions. Patterns elaborate
the actors, the concrete arrangements of collaboration they work within, and the
sequential orders of cooperative work they routinely perform and so provide a solid
basis to reason about user needs and to formulate use-cases or use scenarios
outlining potential design solutions supporting members’ cooperative work
(Crabtree et al. 2002a).
94
Analysing the Design Space with Patterns

(Formulating Design Solutions 1)
Twidale et al. (1993) note that although various structured methods and CASE tools
have emerged in recent years in support of software engineering, such approaches
have provided very little support for the creative process of design, as distinct
from solution structuring, refinement and documentation.
By the creative process of design Twidale et al. refer to analysis of the design space
and the initial formulation of potential design-solutions. Naturally, the creative
process of design may be on ongoing process, one that is engaged iteratively as
systems develop over time. Nonetheless, and as Twidale et al. point out, the
creative process of design does not proceed through the use of formal methods in
the first instance, but is carried out in “informal ways”, the outcomes of which are
subsequently “normalised” or made publicly intelligible and available to others
through the use of formal methods. Rogers and Bellotti (1997) provide some
instruction as to what that informal work consists of with respect to ethnographic
involvement in the design process in saying that
ethnography is most likely to show its value in being expounded within an
ongoing dialogue between collaborating ethnographers and designers about
observations and understandings derived from field studies, together with
interesting capabilities of new technology configurations.
The cooperative analysis of patterns, upon which the initial formulation of design
solutions stands, is not situated in the use of formal design methods then, but in the
ongoing dialogue that takes place between work analysts and systems developers in
design meetings. The work of a perspicuous setting (a design meeting where
support for search activities in the library is being considered) is consulted below in
order to explicate what the work of analysis and formulation of design solutions
observably and reportably consists of.
Library Design Meeting #1. (Edited fieldnote extract)
Jonathan: For me, every single search you perform on the library produces a
new world, OK. You take that as my base thought. So you search by
classmark, you search by title, you search by keyword, OK? Basically there
are objects that come back, and they are labelled with their titles or whatever,
and what I imagine is that you lay them out in a 3D space. You might bring
the ones that are more commonly used closer to you (Jonathan sketches a
diagram of the 3D space on the whiteboard). These are atomic objects, these
aren’t worlds, these are single objects, single books (points to objects in the
diagram).
Andy: I think that’s something that’s useful afterwards but there’s a basic
problem here. There’s users who know exactly what they want, and there’s
users who have some sense of what they want but they don’t know exactly as
an item what they want. So what I know as a user is, I want something on
Dada, for example, and I want something on the history of Dada but I don’t
know exactly what I want on the history of dada, but I want that. So you’ve
95
done this search. Rather than getting two hundred and thirty objects back in
various relations (on an OPAC list), what you are getting back is maybe five
or six categories, and one of those categories is going to be history. That’s
what I want – history. I don’t want philosophy, you know what I mean? What
you are not having to do is wade through all possible things there (points to
diagram on the whiteboard), and all those possible things consisting of
irrelevant topics I’m just not interested in. This allows me at a glance to say,
history, and go straight into that world.
Jonathan: Some of what you are saying is the common shortcomings of Q-
pits. Of just - literally, you have a query and then you have a whole
information space consisting of the results of that query, and then they are laid
out x, y, z according to some criteria. The big problem with that is if you have
got a billion objects it’s meaningless. It’s very difficult to get through it and
hence, that’s to do with what John and I have been talking about, about clouds
- so you don’t ever see, you don’t get back a million objects, you get back
several - four or five objects. They are labelled clouds based upon some
commonality.
As the talk makes available, ‘analysis’ is a gloss on a lively context of work in
which work analysts and designers formulate, discuss, argue over, contest, criticise,
recognise problems with, reformulate, refine and otherwise negotiate the practical
character of potential design solutions. Patterns of cooperative work are not simply
relayed and responded to then, but invoked and made relevant to design
conceptions in the unfolding flow of talk. That work is quite observably done
through story-telling. Story-telling may sound like a trivial way to talk about
something as sophisticated as analysis in design. Nonetheless, design talk of all
sorts, including the articulation of typificatory structures, is witnessably embodied
in story-telling. Story-telling should not be treated lightly then. Indeed, and as
Erickson (1996) points out, the telling of stories is central to analysis of the design
space:
Stories work well as a way for promoting collaborative work and
understanding within the design team. Stories are a sort of equaliser. It doesn’t
require much expertise or training to listen to and tell stories. Team members
from any background can be made part of the process of telling and collecting
stories. And once stories have been gathered, team members can discuss
stories, argue about their interpretation, and [so on]. This process sensitises
everyone to the usage domain, helps people identify questions and issues to
probe … and best of all provides concrete examples which can prove
invaluable when team discussions threaten to veer into debates about vaguely
defined abstractions.
Story-telling is central to the analysis of the design space and the formulation of
design solutions because the telling of stories is an ordinary method of analysis
(Sacks 1992b), which design work trades upon whether working with
ethnographers or not. As an ordinary method of analysis, story-telling allows people
with very different competences, expertise, knowledge, and professional languages
– such as ethnographers and designers – to analyse situations together such that
96
mutually intelligible understandings of the design space and user needs may be
arrived at. The method permits cooperative analysis of the design space and
diagnosis of problem-situations. In and through telling stories, the ethnographer and
the designer (and others of course) are able to analyse and construct a mutual
understanding of the design space and user needs and diagnose problem-situations
which technical solutions might be designed to support. Story-telling thus permits
patterns of cooperative work to enter design reasoning in a readily digestible way. It
does so, as the late Harvey Sacks (1992b) put it, because
on analysing a situation they’re in, [people] discover that they know about it
with some story, which can be made, then, [into] something they .. have at
hand, and may tell as a proposed analysis of [the] current situation.
So, for example, the situation that is articulated by the designer’s story regarding
how searching might be supported (through a system that allows keywords to be
issued, that returns atomic objects, labels them according to various criteria, lays
them out in 3D space, and places the most commonly used ones up front) is known
about and analysed through the ethnographer’s story that contests the proposed
solution in telling of patterns of cooperative work and inherent problems
encountered in searching (that users don’t always know what they want, that OPAC
lists are randomly organized, that users have to wade through or browse lots of
irrelevant items to find what they want). The ethnographer’s story also tells of a
potential solution in light of those patterns and problems of work (that the 3D space
might be organized in terms of an intermediary layer of topical categories that
group atomic objects together). This story in turn becomes the focus of analysis and
a potential solution is offered in the terms of Q-pit technologies that group objects
together in clouds according to some criteria of commonality.
As the example indicates, the work of doing analysis through story-telling does
not just consist in the telling and analysing of discrete stories but over the course of
telling and analysing a series of stories, in the working up, elaboration and
refinement of potential design-solutions. Thus, it is through cooperative analysis
and diagnosis of patterns of cooperative work that work studies may come to give
form to design in the first instance.21 Story-telling is anything but trivial then,
indeed, as Orr (1996) points out, it is a much neglected area of research in
___________
21
The working up of potential design-solutions through story telling is, more often
than not, accompanied by the drawing of sketches and diagrams on pieces of paper
or at whiteboards, etc. Such artefacts tend to be very rough and informal and should
be understood as temporally situated resources produced and used in the production
of mutual understandings of the problem-situation and of the general character of
potential solutions, rather than as firm specifications for design. In that respect,
such artefacts are subject to revision or amendment at a later date, or they may even
be thrown away having served their purpose (positive or negative) in the temporal
flow of design work. What the developers are left with (what is more enduring) are
the ‘war stories’ produced over the course of design work, as these articulate in the
re-telling, and in both a readily digestible and economical way, the rationale for
what is being done and in the ways that it is (Orr 1996).
97
occupational studies of all kinds. In the context of systems design, stories are
unnoticed technical objects in the accomplishment of the day’s work. Studies of
their collaborative production and use promise to reveal mu ch of design as a
cooperative endeavour. That is not all there is to the bricoleur’s craft however, for
although design solutions may come to take a preliminary shape through story-
telling, that solution has yet to be fleshed out in detail.
Co-Constructing Use Scenarios (Formulating Design Solutions 2)

Initial design solutions formulated in the course of considering patterns may be
fleshed out in detail through the co-construction of use scenarios (Carroll 1995).
The production of scenarios is today a commonplace approach to working up
design solutions. Just what the notion means, however, cannot be reduced to a
simple set of work practices. A multiplicity of different forms of scenario exist –
such as current work scenarios, future work scenarios, illustrative technical
scenarios, evaluative scenarios, and so on – each of which plays a different role in
the creative process of design (Bødker et al. 1995). Insofar as scenarios are an issue
here, then it is largely with respect to future work scenarios. That is, to just what
work will require technical support in the future and should, as such, be taken into
account in the design of the new system (categorisation work in supporting
searching in the library, for example). Kyng (1995) describes such scenarios as use
scenarios. Whatever one chooses to call them, such scenarios are based on studies
of work and
indicate how computer support and (or) changes in work organization may
improve upon work situations. Where work situation descriptions and
overviews are about existing situations, use scenarios describe future
possibilities … these scenarios presuppose certain qualities of the computer
support, and in this sense they also give some indication of requirements and
thus resemble the use cases of Jacobson. But our use scenarios are not fixed
requirements; rather they represent hypotheses to be evaluated through
[envisionment] workshops [with end-users] – and further revised and
developed. Our use scenarios don’t make sense in themselves … [but] are
understood through the mockups or prototypes realizing them. Thus, we don’t
develop our use scenarios before our mockups and prototypes, but concurrent
with them. (Kyng 1995)
Use scenarios might otherwise be described as open-ended use-cases. They do not
fix design solutions but elaborate them over the course of their production,
retrospectively through observations of work and prospectively through
consultations with users. Just how use-cases may be worked up through consulting
users will be addressed in the following chapter. First however, we need to
appreciate what it means to base use scenarios on studies of work, thereby
grounding the formulation of design solutions in sequential orders or patterns of
cooperative work.
By way of articulating what it means to base use scenarios on studies of work,
Kyng (1995) argues quite rightly that the role of proxy user suggested by some
98
involved with ethnographic work is not tenable, but that does not mean that there is
no room for ethnography in design.
Doing initial analysis, developing work situation descriptions and use
scenarios, preparing mockups for specific envisionment, and conducting
workshops requires specific skills that are difficult and time-consuming to
develop. Often designers, and obviously end-users, lack such skills. Thus
cooperative design definitely needs facilitators, people skilled in working with
different kinds of design representations and involving both users and
designers in cooperative activities; people who can convince designers, end-
users, and managers of the benefits of working cooperatively; in particular,
people who can organize the workshops where mockups and prototypes of
new design are tried out by end-users in worklike settings.
Kyng respecifies the perceived role of the ethnographer in the creative process of
design from proxy to facilitator (by contrast, it might be argued that this has in
various ways been the ethnographer’s role all along but it is of little consequence
here). Just what this means is rather vague, however, and one might say that just
what it means concretely will be the outcome of doing the work, of engaging in
design. In that respect it may be argued that the ethnographer’s role as facilitator –
as bricoleur – is not one of doing work studies and writing use scenarios in light of
those studies. Rather it is one of doing work studies and collaborating with
designers in the joint formulation of use scenarios. Many ethnographers are not in a
position to write use scenarios on their own or in collaboration with other work
analysts. The ethnographer simply does not posses the technical competence needed
to envision the future in light of the present. There is a necessity, then, to
collaborate with designers in the production of use scenarios.
Given the necessity for collaboration, it makes sense to speak of a division of
labour in the production of use scenarios. On one side of the division stands the
designer, who brings knowledge of technology and technological possibilities to the
design exercise. On the other side of the division stands the ethnographer, who
brings knowledge of the social organization of work to the exercise (and, of course,
users and other stakeholders need not be excluded from this work). Knowledge of
these respective areas is originally articulated and combined through story-telling
and the stories produced provide a basis for the formulation of use scenarios, filling
out in detail the practical character of design solutions (i.e., what the design solution
will do and how). As a result of discussing proposed design-solutions in relation to
the sociality of work in the library, for example, the ethnographer and designer
produced a story that served as a basis for developing a specific use scenario. That
story specifies systems support for searching’s work such that on issuing a keyword
search, items are returned, labelled, grouped, and linked together in navigable
clusters of clouds according to the search criteria specified when the search is
issued. This arrangement provides an ‘intermediary layer’ mediating between users
and the catalogue, and furnishes material resources which may be employed by the
parties to searching’s work to accomplish categorisation work.
Just how any of this is to be achieved technically is not the ethnographer’s
problem, not in the production of use scenarios at least. The ethnographer’s
problem is not, as such, one of specifying how one should get from A to B as it
99
were, but of specifying what A and B (and C and D, etc.) are in the first place. It is
the designer’s responsibility to make the technology answerable to these
specifications. Thus, and for example, in considering technical support for
searching’s work the designer is required to articulate potential design solutions that
will support categorisation work. The extract below furnishes a concrete example of
the use scenario formulated by the ethnographer and designer with regards to
supporting searching’s work in the library.
Extract from library use scenario
On executing a keyword search, the OPAC system will return a potentially large
number of matches or ‘hits’. The prototype is configured to group hits in the
information view according to their classmark (which the system should be able to
expand into more meaningful identifiers). Common groups of data (those with the
same classmark) are represented as solid ‘clouds’ whenever the number of matches
reaches a certain threshold (which is possibly user configurable and may also
depend on system performance). In this example the threshold is passed and the
system starts creating various clouds for ‘Dada’, such as ‘history’, ‘art’ and
‘philosophy’ for example.
Figure 18. Clouding by classmark conversion.
The categorisation used to form the clouds is user configurable (not necessarily by
classmark). Thus a user may select some general attributes of the resulting hits (like
classmark or author etc.) or some other available metrics may be employed, like
popularity (how many times have certain books been accessed before). In Figure 18
the clouds are defined using converted classmark-topic categories forming several
areas, including art, philosophy and history – all of which contain books on Dada.
The user chooses one of the clouds, history say, which contains a number of books
within the cloud threshold value, and flies into it. The system presents the books (or
objects) in the space (shown in Figure 19), and arranges them in three dimensions
based upon some appropropriate Q-pit like criteria. For example, the popularity of
use insofar as the object has been marked as (potentially) suitable by users.
100
Figure 19. Presenting objects in the cloud.

Once within the cloud, the user flies into several of the books, identifying two
potentially suitable matches for their Dada search, and marks them for later
physical retrieval from the library itself. These marked books are added to a session
bookmark or shopping list which can be printed out by the user at the end of
session.
It should be remembered that this is only a snippet from the overall use
scenario. Nonetheless, the extract hopefully makes it apparent how the requirements
problem may be addressed through the organized use of work studies. Cooperative
analysis of patterns of cooperative work in the library resulted in the intermediary
layer story, which has been worked up in the use scenario to lay out a sequence of
actions that design solutions be may be modelled to support.22
As noted above, use scenarios are developed hand in hand with mockups and-
or prototypes. Describing sequences of action to be supported by technological
solutions, use scenarios provide concrete resources for configuring working
prototypes. This configuring work draws contingently upon a host of different
competences to hand, such as knowledge of legacy systems, database configuration,
object-oriented design methods, and more, all of which are directed towards
implementing technical solutions supporting the sequences of action articulated in
the use scenarios. The configuration of mock-ups and working prototypes is often
conducted at whiteboards and with ethnographers and other relevant parties in order
to ensure that technical solutions address the problem-situation. Notably, it is in the
course of this work that formal designs are sketched out (as portrayed in Figure 20,
for example). Mutual understandings of the problem-situation and formal design
sketches in hand, the designers may deploy formal methods to implement the
solution, employing CASE tools, graphical notations, and whatever else is
necessary to configure a working prototype.23
___________
22
The co-construction of use-scenarios is an iterative exercise in which documents
are worked up, elaborated and refined by the ethnographer and designers over a
series of turns in an ongoing course of dialogue.
23
Formal design work at whiteboards in design meetings is one area of cooperative
work in design not considered in detail here. It is an important area of research in its
101
The work involved in using formal methods is not considered here. Attention
has instead been paid to the ‘seen but unnoticed’ or taken for granted and ignored
work involved in design, particularly the appeal to typificatory structures (i.e.,
patterns of action), the nature and role of story-telling, and its relation to the co-
construction of use scenarios, all of which presuppose the deployment of formal
methods. Use scenario(s) in hand, a suitable architecture may be sketched out and
formal methods deployed in the design of a technology that may be used to support,
in this case, searching’s work. In this case, the proposed design-solution consisted
of developing a 3D visualization that reflected the core elements of the use
scenario, and which interfaced to the library’s catalogue system. This configuration
allowed users to access real world data through the 3D environment and to use the
visualization of data structures to accomplish search activities. The core elements of
the working prototype are presented below prior to considering the role of end-user
evaluation in the design of collaborative systems .
Figure 20. Configuring scenario-based prototypes.

___________
own right and, indeed, has received attention elsewhere in the design literature (e.g.
Pedersen et al. 1993). Its description and analysis requires a vulgar competence in
formal design methods (which the author does not possess, hence the absence of a
detailed account). Nonetheless, it is at this site that the “formal” and “informal”
often meet. The ethnographer need not be unduly concerned by this work however,
as the implications of the work studies have already been articulated ni an
intelligible and digestible fashion to designers in the use scenarios. As noted above,
the work here is, amongst other things, concerned with meeting the constraints of
the use scenarios and the ethnographer’s role is an auxiliary one of clarifying the
use situation as and when particular problems emerge in the design dialogue.
102
The working prototype exploits Q-pit technologies (Mariani et al. 1995)

running in DIVE (Carlsson and Hagsand 1993) and DEVA (Pettifer et al. 2000)
environments. These technologies allow multiple users to simultaneously inhabit a
shared 3D environment and have, as such, tended to be seen as social spaces where
the purpose is to allow users to meet each other and interact together within
‘cyberspace’. The notion that collaboration and cooperation should take place
within the virtual environment is a prevalent one, guiding a great deal of research in
the design of Collaborative Virtual Environments (CVEs). However, studies of
CVE usage point out that workaday activities are achieved by a combination of
collaborative actions taking place in the virtual environment and in the real world
(Bowers et al. 1996). In light of this it is suggested that
when it is claimed that CVEs can in principle support cooperative work in
ways difficult to achieve with alternative technologies, we take this as a claim
most appropriately assessed in light of all the work both within and without
the virtual environment narrowly considered. CVEs should not be criticised
(nor prematurely celebrated) on the basis of only what can be designed into the
virtual environments or occurs within them. This argument, then, suggests that
there is an opportunity to rethink the design challenges in CVE research: one
should be designing for two worlds not just one. (Bowers et al. 1996)
Comments such as these suggested that the design of CVEs should be ext ended to
provide support for the cooperative work that takes place outside the virtual
environment in the real world. In attending to the external world of work, more
recent developments have seen emphasis placed on augmenting the material
resources in and through the use of which cooperative work gets done (resources
such as OPAC, for example). As Büscher et al. (2000) put it,
CVE researchers have experimented with different ways of mediating
awareness and formation of groups and meetings in virtual environments.
However, the artefacts related to the work of users have received less attention
... This is a serious barrier for bringing CVEs out of entertainment or research
to real world work tasks.
Taking the material demands of cooperative work in the real world seriously
suggests that the major challenge in the development of CVEs is not so much to
focus on what can be done cooperatively within the environment, but to support
cooperation in the real world through the augmentation of material resources. The
point was taken seriously in configuring the library prototype, and emphasis was
accordingly placed not on what should or could be done cooperatively within the
virtual environment, but on providing support for real world patterns of cooperative
work. Putting novel technologies to work by situating them within real world
patterns of cooperative work was taken to be the major design challenge and the
working prototype was therefore configured to support work as it is, rather than a
priori concepts of what CVE technologies should do. In that respect, it was noted
that the library catalogue is accessed through public terminals which people cluster
around in various constellations of cooperation and assistance. This shoulder-to-
103
shoulder interaction is central to how OPAC users conduct their work together and
the prototype was configured to be shared in this shoulder-to-shoulder manner
rather than remotely and through the use of avatars.
In contrast to OPAC, which provides a number of fixed entry categories to
input a search term, users issue searches via the developed prototype through a
single keyword entry window. This reflects the topic-based character of searching
and provides the basis for the generation of the virtual environment. In order to
issue a search the user simply fills in the keyword slot. Items are returned according
to default search criteria or ‘weighting’. The user may change this weighting so that
items are grouped by similarity according to author, title, publication type, or date,
publisher, ISBN, or any combination of these criteria and by any other criteria that
may be added to bibliographic items in the future (e.g. via HTML Metatags). The
user may also adjust the degree of exactness by which similarity weightings are
applied (from a range of high to low) and the default threshold which determines
the numeric level at which grouping takes place such that if only ten items are
returned, say, then they are simply presented to the user as atomic objects, whereas
if seventy items are returned, then they are grouped according to the similarity
criteria specified.
Keyword
window
Weightings Exactness
Figure 21. The Q-pit Library Interface.

© 2000 Steve Pettifer (AIG, The University of Manchester). Included here by permission.
104
Once a keyword has been provided the search may be executed within the
OPAC catalogue. The results are then used to populate the environment. The final
stage of the query and retrieval process consists of the construction of the
intermediary layer suggested in the design meeting through formation of links and
clouds in the space. The clouds display at-a-glance groupings of similar items
(similar in respect of the weightings applied to the search) and the links indicate
interconnections between clouds and items therein. Each object within the space has
a partial title attached to it. As clouds of similar objects form, users can view object
titles and see at-a-glance just what each cloud contains as a topical space. In issuing
a keyword search on ‘java’, for example, the user can see by viewing the titles of
the objects being pulled into the clouds that one of the clouds contains items on java
software engineering. This may contrast with the objects in an interconnected cloud
whose titles indicate that objects on java software testing are contained within it. As
the search engine pulls all items with a similar keyword into the space, objects
about java the island may be pulled into the space as well and would be pulled
together in a separate, unlinked cloud, although that cloud may be linked to other
java-the-island topics. The grouping of related items contrasts with the OPAC
interface, which groups everything together in a randomly organized list.
Selected object
Bibliographic
details
Shopping list
Figure 22. The Q-pit Library Interface.

© 2000 Steve Pettifer (AIG, The University of Manchester). Included here by permission.
105
Once the space has been generated, users are free to interact with and navigate
the display. A key aspect of the environment is that users have an object centric
view of the space. In other words, navigating or searching the space is constrained
in terms of specific objects and the relationships that hold between them. In contrast
to other virtual environments where full 3D navigation is provided and often found
problematic, the real world nature of the application suggested the need to support a
constrained form of navigation in order to avoid the overhead of managing
movement in a virtual environment, which is notoriously difficult to support; users
are constantly getting lost in unconstrained environments, for example.
Consequently, an object-based approach to searching the space was exploited with
explorations centring on a selected object. In this respect, the navigation vehicle
developed supports two modes of interaction: 1) browse, and 2) point and click. In
the browse mode, mouse movements allow the user to orbit the clouds in the space
and see the various constellations of topics and their interconnections. Users may
examine particular objects by centring the object in the cross-hairs to see
bibliographic details. Over the course of interacting with the space, the user can
also assemble a shopping list of items that are of potential relevance or interest. The
list may be printed off and used in the course of locating objects in the physical
library. The shopping list persists across different searches and is, as such, session-
oriented, providing support for categorisation work at the help desk in times of
trouble, which trades on the user’s search history. Each search space may be
reordered or re-generated by simply altering the weightings to display different
relations of similarity between the displayed search items. From this point,
regeneration continues much as for the original generation of the space (Crabtree et
al. 2002b).
Developing a scenario-based prototype is by no means all that there is to the
formulation of design solutions. In many respects, this might be said to be just the
beginning of the enterprise, as the developed environment articulated above is but
the first incarnation or version of the design solution supporting searching’s work.
The point of describing the work involved in the production of this early and
incomplete prototype has been to illustrate how ethnography might support analysis
of the design space and shape the formulation of design solutions. The production
of patterns, working up of stories, and the co-construction of use scenarios
illustrates practical ways in which ethnography may be deployed to inform design
reasoning and the production of design solutions.
In a design context, the disciplinary concerns of social science are left behind,
which is likely to be a great disappointment to social scientists who see design as a
promising new site in which to pursue their agendas. In that respect, the work
articulated here should serve as a caveat to designers and social scientists alike.
Designers have unique problems of their own and there is no need to suppose that
they are identical to those that beset the agendas at work in the social sciences. On
the contrary, design is not interested in social science but in developing methods for
analysing the sociality of work in the wild, in its natural habitat, in contrast to in
social science theory. This chapter has articulated several ways in which the
development effort may be constructively informed through ethnographic studies of
work. This is not to say that the approach advocated here is the only way in which
the social sciences in general, and ethnography in particular, may enter design
106
reasoning - it is but one way and one that complements existing design practices
which presuppose the deployment of formal methods and rely on ordinary
competences (and so require no long-term specialized training). The purpose of the
next chapter is to consider what more there is to the ethnographer’s role as a
bricoleur in design practice by addressing what more there is to the formulation of
design solutions supporting cooperative work.
107
An alternative approach to traditional require-
ments specification relies on ethnographic
studies and-or user participation throughout the
design process to minimise the mismatch
between the computer system and conditions of
use. How and in what ways ethnography and
techniques of user participation can be
effectively developed is a major research area
within CSCW.
Liam Bannon & John Hughes
4. Evaluating Systems Support for
Cooperative Work
The previous chapter addressed the design of an early and incomplete prototype
supporting searching’s work in the library. The incomplete character of the working
prototype was intentional. It represents an initial first guess as to what might
constitute a realistic design solution. That is, an informed guess that might be
evaluated, elaborated, amended and-or refined by consulting end-users, and built
upon in light of users hands on experiences in an evolutionary process of
development. Evolutionary prototyping is central to the notion of evaluation
advocated here. Having a long pedigree in design, evolutionary prototyping
emerged as a viable alternative to the Waterfall Model in providing a ground-up,
process driven approach to the development of collaborative systems (Bally et al.
1977; Naumann and Jenkins 1982).
Thus, for example, there have been incremental models, such as that
developed by the Boeing Corporation which abandons the idea of a complete
system of requirements, and starts with general objectives into requirements
and proceeds by translating some of those objectives into requirements and
then implementing them. The cycle then repeats. Starting the development
process with general objectives rather than a complete set of requirements is
important because it allows requirements to adjust to changing conditions.
(COMIC D2.1) 24
The motivation for evolutionary prototyping emerged from designers’ working
experiences in which they found that in practice, as opposed to text -book theory,
they only knew how to build the right system after the fact. Building versions was
thus construed of as a very good way of addressing the requirements problem and
formulating appropriate design-solutions (Floyd 1984).
Prototyping is a vehicle for learning what the target system should be like and
thereby furnishes a concrete answer to the question of just what should be built? In
this respect prototyping takes on a very different character in collaborative systems
design than it does in manufacturing. In the case of the latter, and as the notion
___________
24
Evolutionary prototyping provides a counter-balance to the excesses of top-down
approaches which front-load requirements specification. Such practices, while
supporting planning, may hinder the design of collaborative systems if applied too
stringently. As Button and Sharrock (1994) remind us,
Capturing a requirement is like capturing a butterfly, once it’s pinned down
it’s no longer what you chased, it’s dead. User requirements are contextually
organized matters, and their intelligibility resides in understanding their
relationship to a whole range of other work and Organizational matters. They
gain life and animation within this context. Requirements analysis rips them
from out of this life-giving context and in the process they lose their very
substance as known to users.
108
Evaluating Systems Support for Cooperative Work
might be commonly understood, the term is often taken to refer to the first of a type.
Thus, prototyping refers to a well-defined phase in the production process in which
a model exhibiting all the essential features of the product is constructed in advance
and used to guide the design of the final product. In a design context, however, and
as Floyd (1984) puts it,
Software development differs from ... manufacturing in several ways: it takes
place in the context of an overall system development process; this
development process normally leads to one single product and the desired
characteristics of this product are not well-defined in advance. Thus, no
relevant notion of ‘type’ is available for software, and it is not clear what is
meant by ‘first’, i.e. how the prototype should relate to the final product.
The problem, as stated above, is one of figuring out what to build, what the final
product will be? Rather than predetermine an answer, the point is taken seriously,
and constitutes a modus operandi, that any answer will be the outcome of doing
prototyping work. Prototyping in a systems design context is not so much one of
modelling the final product, then, but of finding out what an appropriate solution
might look like concretely. Thus, prototyping is a software development
methodology that introduces a foundational element of communication with and
feedback from the use practice into the design process (pace Floyd 1987). That
methodology is expressly concerned with analysing the design space from the
various points of view of users and with determining the adequacy of proposed
solutions in their capacity as tools that support human users in their work.
Prototyping Methodology
Prototyping methodology consists of four discrete steps. 1) Functional selection,
which refers to the range of work activities and software functionality the prototype
should support and exhibit (see the previous chapter for work implicated in that
accomplishment). 2) Construction, which refers to the production of the prototype
and its availability for demonstration. Naturally, as a version, the prototype need
not be complete. Nor need it be particularly stable, reliable, or secure, unless these
are features of the future system that are being prototyped. 3) Evaluation, which
provides feedback from the use practice. Evaluation is the decisive step in
prototyping as feedback shapes subsequent development work. The prototype
should, therefore, be constructed with an eye towards enabling users to reason about
the work activities the prototype is intended to support. The prototype should, in
other words, be intelligible to users and the ways in which it proposes to support
their work should be made transparent in the course of articulating its potential use,
thus promoting mutual analysis and learning. 4) Iteration, which refers to the
development of the prototype in light of the evaluation exercise.
Iterative development of the prototype may take one of three interrelated
forms. 1) Exploration: Emphasis here is placed on eliciting appropriate ideas for
design. Exploration occurs early in the design process and is concerned to involve
end-users in a mutual and open-ended process of analysis whereby designers may
come to develop an understanding of the application domain and users may come to
develop a tangible sense of potential design solutions. Exploratory prototypes may
109
usefully be informed by ethnographic studies of work. These prototypes are

incomplete, lacking a great deal of functionality even, and are intended to serve as
catalysts fostering cooperation between designers and end-users. Exploratory
prototypes are usually thrown away, although certain features may be retained and
redesigned in subsequent iterations. 2) Experimentation: Emphasis here is placed
on refining and enhancing exploratory specifications. Experimentation occurs after
early work in the design process and is concerned to build on, demonstrate, add to,
and refine the specifications previously identified as useful. Again, users are
actively involved in experimental work, although it should be stressed that
experimental does not refer to lab-based experiments. Scientific notions of
experiment have no place in this process. It is experimental in the sense of trying
out ideas, building on and stabilizing the good ones and throwing the bad ones
away: a very pragmatic exercise. Ethnographic studies of problematic areas of work
may be undertaken to support experimental prototyping, providing valuable insights
into unexplored areas of work or work activities that users find it difficult to
articulate. 3) Evolution: Emphasis here is placed on the development and
implementation of a stable prototype that supports the work activities of the target
domain. Although iteration of the system may well continue after implementation,
this stage of the design process marks the evolution of the prototype into a concrete
product situated in the use practice. The prototype may, as such, be handed over to
implementation teams whose task it is to devise a production version delivering the
functionality specified by the prototype.
Evolutionary prototyping does not, in itself, guarantee that an operational
system satisfying the needs of the use practice will be delivered. As Floyd (1984)
puts it,
Like any other procedure, it may be misused to manipulate users into
cooperating in what amounts to job obsolescence or the downgrading of their
own work. By presenting prospective users with new technical gadgets ‘to
play with’, prototyping may conceal the fact this type of user involvement can
be a sophisticated way of tuning the system contrary to the users’ interest.
Evolutionary prototyping is a neutral procedure and should not be seen as a panacea
to the ‘wicked’ problems that beset design (DeGrace and Stahl 1990). Rather, the
effectiveness of the approach relies on its combination with other approaches and,
importantly, in its deployment in conjunction with a specific development strategy.
This overall strategy will have more impact on the outcome of software
development than the prototyping procedure in itself. (Floyd 1984)
What might such a strategy look like with regards to the evaluation and iterative
design of collaborative systems? What competences might it consist of? What
might it contribute to the bricolage of expertise? And how might ethnography be
related to it?
Participatory Design
Participatory Design (PD) is an approach to systems design that emerged from
Scandinavia in the early 1970s. Its primary strategy consists of a commitment to
110
workplace democracy, which translates into the direct and active participation of
workers in the design process in the effort to enhance rather than destroy their
skills, autonomy, and quality of life. As a result of this vision for the future, one
largely fuelled by Braverman’s (1974) analysis of capital organization and
deskilling, an action-based research programme was initiated in 1971 by designers
in cooperation with the Norwegian Iron and Metal Workers’ Union (Nygaard
1979). The objective of the project was to develop a plan for action that would
enable the widespread application of workers’ knowledge to the design and
introduction of new technology into the workplace (thus countering, it was hoped,
the tendency towards deskilling). The project was a modest success, fostering
further action-based research in cooperation with various trade unions (Carlsson et
al. 1978; DUE Project Group 1979). Together, these projects resulted in the
implementation of legal statutes across Scandinavia, which today regulate the
design and implementation of new technologies in the workplace by requiring
consultation with workers. They also resulted in the recognition that the formulation
of legal agreements was not sufficient to increase workers influence on technology
design; recognition that spawned a second generation of Participatory Design
research projects directed towards devising new means of involving workers (end-
users) in the creation of novel technological support for work.
Initiated in the early 1980s, the UTOPIA Project saw the emergence of the
notion of ‘design by doing’ (Bødker 1987). Greenbaum and Kyng (1991) articulate
the notion as follows.
‘Doing’ was a central concept for us, embodying the idea that there needs to
be active involvement of users and designers working together at activities
that actually ‘do’ something … learners shouldn’t be ‘spectators’ or passive
participants in the learning process. Designing and using a system is certainly
a learning process for all groups involved, requiring that we all do something
about it. But at the same time … As we began to discus it, the original clarity
quickly evaporated. “In what sense isn’t traditional system development
‘doing’?” and “How do intellectuals ‘do’?” were some of the questions raised
... Perhaps in our eagerness to get ‘doing’ back into the picture, we were not
just balancing the scales, but introducing a new, false dichotomy between
doing and reflecting?
So midway through our writing process we shifted our focus slightly to
acknowledge that what we were actually doing was showing ways to reflect
on work practice and how to give that practice a central position in the design
process.
The UTOPIA project was concerned to develop technology for skilled workers in
the newspaper industry. The initial approach to design saw the use of formal
methods to describe system requirements. Not unsurprisingly, such descriptions did
not engage the print workers. Thus, the designers attempted to engage them through
the co-production of mock-ups (Ehn and Kyng 1991). As with prototypes, mock-
ups have a long history in manufacturing where they are used to engender a
concrete sense of what a future product will look like. Again, as with the use of
prototypes in a design context, mock-ups are intended to facilitate the learning
process in design. As Ehn and Kyng (ibid.) put it,
111
our focus is on setting up design games for envisionment of future work

process. In contrast to industrial designers, we focus more on hardware and
software functionality of the future artefacts … Industrial designers often
make very elaborate aesthetic and ergonomic designs … [but] no functionality
is simulated or mocked up … If the future users also actively participate in
design, the mock-ups may be truly useful and a proper move toward a changed
reality.
Thus, and for example, the designers and workers involved in the UTOPIA project
used diagrams and cardboard boxes to represent and articulate the functionality of
computers, screen layouts, laser printers, and other devices. These mock-ups served
to articulate requirements for a prototype of a text and image processing system that
supported the work practices elaborated by the workers in the course of producing
the mock-ups, and that is the real purchase of mocking-it-up for Ehn and Kyng. In
other words, the purpose of mocking-it-up is not so much the design of a product
but learning about the work practice and potential relationship of technology to that
practice. Mocking-it-up allows users to develop a concrete sense of what future
technologies may do for their work. At the time of the UTOPIA Project, for
example, desktop laser printers only existed in advanced research labs and the
possibilities presented to workers by that technology were ‘unreal’ though very
tangible nonetheless. In other words, mock-ups allow users to experience what the
future might consist of concretely, and to make technological possibilities fit their
needs. Mocking-it-up thus promotes cooperative analysis of the design space by
end-users and designers and may be easily migrated to working prototypes.
The co-production of mock-ups and-or working prototypes is underpinned by
the notion of a ‘language game’ (Ehn and Kyng 1991). Drawing on the philosophy
of the later Wittgenstein (1992), Ehn (1988) takes it that an essential feature of
human practice is language. As different practices are marked or made observable
by different ways of talking - consider military, medical, legal, and domestic talk,
for example - different practices might be said to employ distinct ‘grammars’.
Wittgenstein described these distinct grammars as language games, a notion which
“is meant to bring into prominence the fact that the speaking of a language is part of
an activity, or form of life” (Wittgenstein 1992, PI 23). In other words, our
language is tied to, and makes observable in its use, commonplace organizations of
practical action: the workplace, the home, the school, etc. Consider the following,
for examp le:
Let us imagine a language … meant to serve for communication between a
builder A and assistant B. A is building with building-stones: these are blocks,
pillars, slabs and beams. B has to pass the stones, and that in the order in
which A needs them. For this purpose they use a language consisting of the
words ‘block’, ‘pillar’, ‘slab’, ‘beam’. A calls them out; - B brings the stone
which he has learnt to bring at such-and-such a call. – Conceive this as a
complete primitive language-game. (Wittgenstein 1992, PI 2)
The example makes it perspicuous that the form of life described above – the
imaginary job of work (building) - is organized 1) through the concepts constituting
the grammar of the language-game (blocks, pillars, slabs and beams), and 2)
112
through the practiced application of those concepts in accomplishing the activities

to hand (bringing a slab, not a beam, when slab is called out, etc.). Thus, and to
make a general point on the basis of this example, the language-game whereby a
particular form of life is organized consists, in the first instance, of a grammatical
web of interlocking concepts and discrete activities tied together through
cooperative work practices (Crabtree 2000a). The concepts of a language-game (the
grammatical web) gain their sense from the activities to which they are tied, and
more specifically, from the work practices through which they are tied
(Wittgenstein 1992, PI 6). There is, then, a distinct situated sense to particular
concepts – to the concept of printing (for example) in ‘this’ form of life (a
newspaper print shop, say). A situated sense that may be very different to the one
the same concept has in another form of life (such as a T-shirt print shop). There
may, of course, be some similarities between the two, something of a ‘family
resemblance’ (PI 66).
The notion of a language game and family resemblances provides Ehn with the
means of elaborating work practice and analysing the design space. The challenge
is to create a design language game in which users can actively and constructively
participate; a design language game predicated on and resembling the language
game of the use practice (or form of life) that is the target of design.
For example, if Pelle, a designer, points at the cardboard box with the sign
‘desktop laser printer,’ and says to Jon, a typographer, “Could you take a look
at the proof coming out from the desktop laser printer,” John does not reply
“There is no desktop laser printer! You are pointing at an empty cardboard
box, stupid!” Rather, he would go to the cardboard box, pick up a blank paper
from a paper stack beside the box, turn toward Pelle, look at the paper, and say
“Well, here we have a problem. There is too much text for a 48 point three
column headline and that picture of the president. I think we will have to crop
the picture, or the headline has to be rewritten.” (Ehn and Kyng 1991)
As the example makes clear, cooperative analysis of the design space with end-
users is not couched in difficult technical terminology here, but in terms of the
concepts of the language game of the use practice. Thus, talk of the uses of the
desktop laser printer is organized in terms of columns, headlines, pictures,
cropping, and so on. That is, in terms that make sense to the practitioners whose
work the designers are seeking to support and in terms that therefore enable users to
envision future uses of new technologies in context. As Ehn and Kyng put it,
The reason that Jon, Pelle, and the other participants can use the mock-up in a
proper way is because this design language game has a family resemblance
with other language games they know how to play. The language game in
which the cardboard box is used has a family resemblance with the use of a
traditional proof machine in the professional typographical language game
which Jon knew very well … In these games mock-ups play an important role
… as a reminder pointing back to experience from using the mock-up.
It might otherwise be said that mocking-it-up elaborates experiences in the
workplace (hence the family resemblance), and it is in this respect that ethnography
may be of particular utility. Mocking-it-up or developing exploratory prototypes
113
may be usefully supported through quick and dirty ethnographic studies running
prior to or concurrently with mock up exercises. Quick and dirty studies may be
used to explicate the grammatical web of interlocking concepts that constitute the
language game in question through the assembly of instances of work and
production of patterns, thereby mapping and conveying the grammar of the
language game in details of work’s real world, real time social organization
(Crabtree 2000a). At the same time, mock-up exercises may usefully inform
ethnographic work, directing that work in order to address particular problems that
emerge in consideration of users experiences that emerge in mock-up or
prototyping workshops.
Cooperative Design
Design by doing soon led to the development of other techniques for involving
users in the design process in order that their work practices might assume a central,
shaping role in design. As noted above, mock-ups may be easily migrated to
prototypes and the emergence of a third (and current) generation of Participatory
Design techniques is marked by the development of distinct prototyping methods.
In the mid 1980’s prototypes were largely used to supplement traditional methods
of formulating design solutions. Prototypes were particularly employed to
demonstrate system features to potential users, rather than to enable users to get
hands on the future and thereby elaborate design solutions (Grønbæk 1989).
To experience is not to read a description of the computer application, nor is it
to watch a demonstration. (Bødker and Grønbæk 1991)
For members of the Participatory Design community, the point and purpose of
prototyping was not and is not to demonstrate potential systems to users but to
actively involve them in the design process in order that systems may be developed
that are tailored to user needs and thus improve the quality of working life. The
tailoring of systems in this context was not and is not something that occurs after
the design of a system (syntactic sugar as it were) but an essential starting point for
the design of socio-technical systems of work (CSCW systems). Just what work a
future system is to be tailored to support, and just how, are guiding questions to be
asked in doing prototyping then? Employing workplace studies and various
scenarios (use scenarios, technical scenarios, etc.), exploratory prototypes may be
constructed in the effort to produce and elaborate answers to these questions.
The aim [here] is to make ‘quick and dirty’ sketches of the computer
application in order to clarify requirements for a new computer system … The
prototypes .. serve mainly as substitute specifications for the application and
to propagate ideas into detailed design activities. (ibid.)
The production of quick and dirty prototypes and their iterative development and
evolution into more stable applications through active user involvement soon earnt
a dis tinct label: Cooperative Prototyping or Cooperative Design. The approach has
its roots in both the process-oriented and evolutionary traditions. It is specifically
concerned to
114
establish a design process where both users and designers are participating
actively and creatively, drawing on their different qualifications [or
competences]. To facilitate such a process, the designers must somehow let
the users experience a fluent work-like situation with a future computer
application; that is, user’s current skills must be brought into contact with new
technological possibilities. This can be done in a simulated future work
situation … or, even better, in a real use situation. When breakdowns occur in
the .. use situation, users and designers can analyse the situation and discuss
whether the breakdown occurred because of the need for training, a bad or
incomplete design solution, or for some other reason. Breakdowns caused by
bad or incomplete design solutions [may] be rapidly turned into improved
designs, re-establishing the fluent work-like situation. (ibid.)
As Bødker and Grønbæk make clear, the rationale for Cooperative Design is to
develop computer systems from the ground-up in close contact with the practical
circumstances of their actual use. Cooperative Prototyping is therefore oriented
towards explicating just what the practical circumstances of systems usage consist
of concretely and to use that knowledge as a basis for design. Thus, users are
confronted with envisionments of the future (prototypes). The adequacy of those
visions is determined by users in their efforts to undertake their work tasks, and
visions are amended accordingly through further iteration and further work study if
necessary.
This orientation to prototyping – an orientation that seeks to explore the
practical accomplishment of work - is unique and contrasts with much prototyping
work in which designers are preoccupied with the novelty of technical solutions
rather than the practical adequacy of solutions-in-use. Indeed, designers often argue
against active early user involvement insofar as users are perceived to only know
about what is possible now. Designers, on the other hand, are in the business of
creating innovative futures. A fortiori, the user has little, if anything, of constructive
use to say until that the future has been constructed by the designer (Grint and
Woolgar 1997). Of course, it might be argued that the novelty of computers will not
last, that at some point designers must face up to the practicalities of everyday life if
computers are to be effectively incorporated into the milieu of ordinary activities
that constitute our workaday worlds, but then that is taken for granted by many
CSCW practitioners and employed as a modus operandi in Cooperative Design. As
Bødker and Grønbæk (1991) put it,
Users are not there to annoy the designers or to spoil their ‘wonderful’
designs, but to guide them, because they know the relevant work tasks.
‘Users’ – i.e., practitioners: skilful, competent doers of activities – are the real
experts in work’s accomplishment, even in the face of change, and no-one, not
ethnographers, HCI specialists, business strategists, nor designers no matter how
visionary, know the practicalities of work’s accomplishment better than they. Users
are not a homogenous group but rather, diverse groups of people who have
competence in their work practices. Users are, then, the appropriate parties to
consult in undertaking design, and to assess, evaluate, and recommend changes to
design, particularly where support specifications (just what) and usability (just how)
115
are concerned.25 The Cooperative Design of computer systems brings users

(including workers, administrators, managers, and other stakeholders), designers,
work analysts, and others (e.g. business strategists) together in the evolutionary
design of prototypes that support the practical activities that comprise the day’s
work in a particular setting, large or small (Christensen et al. 1998). This is not say
that Cooperative Design is a global panacea to the wild and wicked problems that
beset design, only that active user involvement in the design process enhances the
possibility of designing ‘acceptable’ socio-technical systems of work (i.e.,
collaborative systems that are used not circumvented or worked around).
As a prototyping activity, Cooperative Design has its own unique problems to
contend with.
Prototyping naturally leads to a technical focus on the computer application …
There is a danger that the designer gets more focused on ‘hacking’ than on
discussing problems related to the use situation. Discussion in a prototyping
session often focuses on the interaction with the computer more than on how
work is organized around the computer … To avoid a too technical focus it is
important … to shift back and forth to techniques that have different foci.
(Bødker and Grønbæk 1991)
The danger that Bødker and Grønbæk allude to is more widely recognised as the
‘problem of tunnel vision’ (Sol 1984). Mogensen (1994) articulates the problem as
follows.
In the strategy of successive prototypes lies a danger of blindness (‘tunnel
vision’ [or] ‘model effect’). Once the process of development of successive
prototypes has started, the danger arises that one is led to elaborate the details
of the current prototype instead of questioning its underlying premises. In the
process, what was initially questioned becomes more and more taken for
granted, and it becomes more and more difficult to consider radical changes.
To what extent this is a danger to be avoided naturally depends on whether
one is on the ‘right’ track or not, which again underscores the importance of
the initial ‘guesses’.
Mogensen has devised a particular prototyping technique - provotyping - for
managing the problem of tunnel vision. Unlike many approaches to prototyping,
which are oriented to the design of a future application, provotyping pays analytic
attention to current practice, supporting the formulation of initial guesses for
technical innovation through examination of work practice in the here and now.
Provotyping is an approach to the analysis of the design space and cooperative
formulation of design solutions. It is expressly concerned with the general
contradiction that obtains between tradition and transcendence (Ehn 1988). -
___________
25
There is, of course, nothing new in that recognition – after all, scientific
management is predicated on it, albeit with very different intent (i.e., rationalization
and control).
116
[In design] one can focus on tradition or transcendence in the artefacts to be

used. Should a word processor be designed as a traditional typewriter or as
something totally new? Another dimension is professional competence.
Should the ‘old’ skills of typographers be what is designed for or should ‘new’
knowledge replace these skills in the future? Along the same dimension is the
division of labour and cooperation. Should the new design support the
traditional organization in a composing room or suggest new ways of
cooperation between typographers and journalists? There is also the
contradiction between tradition and transcendence in the objects or use values
to be produced. Should the design support the traditional services a library has
produced or should it support completely new services and even new clients?
Tradition or transcendence, that is the question in design.
As Mogensen observes, one may focus on either tradition or transcendence but that
would be to miss the point. The point, in design, is always one of tradition and
transcendence, as design is always bound by tradition (current work practice) and,
at the same time, committed to transcending tradition in order to add value. In order
to find out what to build in an effective manner, design is therefore obliged to
investigate current practice in order to devise new technologies supporting new
Organizations of Work. Provotyping uses prototypes (and prototyping techniques,
including work studies) to find out what current work practice consists of
concretely and to subject it to cooperative analysis by end-users in the effort to
design solutions that support work (of searching in the library, say) yet transcend
current constraining social and technological orders of work (Mogensen 1992).
The purpose of cooperative analysis here is to engage practitioners in a process
of Cooperative Design, not by focusing on a future application but by turning
design upside down and using prototypes as vehicles for the analysis of current
practice with an eye towards formulating acceptable changes, which may then be
built upon and elaborated in an iterative fashion. Prototypes are employed to
challenge practice then in the effort to formulate with users appropriate
technological solutions (Mogensen 1994). Employed to challenge practice, to ‘call
forth the taken for granted’ and make it available for consideration in design,
prototypes come to assume the character of triggering artefacts (Mogensen and
Trigg 1992). That is, artefacts that trigger analysis of current practice by
practitioners for purposes of change. Several interrelated features of the triggering
process are worthy of consideration.
1. Seeing the Sense of the Artefact

On encountering a prototype, practitioners can rarely see the sense of it. It is not, at
first glance, intelligible to them and its potential use must therefore be explained.
‘Explained’ is here a gloss on the work involved in coming to see the sense of the
prototype, in coming to see it as an instrument that may support workaday activities
and concrete arrangements of cooperative work. That work involves guiding users
through the prototype’s functionality. ‘Guiding’ does not mean demonstrating the
prototype’s technical features but walking practitioners through the functionality in
order to show them just how the prototype may be used as a tool in the
accomplishment of the real world activities of work it is intended to support.
117
2. Recognising the Relevance of the Artefact

That practitioners may see the sense of the prototype does not mean that they will
recognise it as relevant to their work. Practitioners quite obviously need to be able
to recognise the relevance of the prototype to their work if they are to engage in any
meaningful analysis of its potential utility and elaboration. Recognition of relevance
may be engendered by employing use scenarios to embed the prototype in a specific
use context (searching in the library, say), thereby making that context and the
prototype’s relative utility amenable to cooperative analysis. As with the dialogue
that occurs between ethnographers and designers, cooperative analysis between
practitioners and designers is characterised by story-telling concerning particular
aspects of the work and the prototype’s adequacy with respect to that work. Like
the ethnographer’s stories, practitioners’ stories become design objects, shaping
iteration and prompting further ethnographic investigation of current work practice.
3. Appropriation of the Artefact

A prototype that is recognised as relevant to some community of practitioners’
work may be appropriated by that community. That is to say that the practitioners
may call for its development for and implementation in their work. Appropriation
involves preliminary acceptance of the prototype as a viable socio-technical system
of work, changes and refinements withstanding. Appropriation provides a concrete
basis for the development of evolutionary prototypes, then, and thus for the co-
construction of experimental prototypes which transform early prototypes (or
provotypes in Mogensen’s terminology) into stable arrangements of technical
support through incremental refinement.
Taken together, points one to three provide criteria for evaluating prototypes of
cooperative systems within an evolutionary development framework (Mogensen
1994).
Beyond Political Rhetoric

Participatory Design has been subject to fierce criticism from alternative
perspectives in design and from within its own ranks. External critiques often offer
little more than crass intellectualisations.
[PD] motivates the developer to seek cooperation with labour and their
representatives. It advocates a participative approach but only with one party –
labour. Only system objectives that evolve from the cooperation between
labour and the developer are considered legitimate. (Hirschheim and Klein
1989)
True, in its origins PD motivated designers to cooperate with labour but only to
redress the balance. Up until that point systems were largely designed in
cooperation with senior managers who, having little or no contact with real world
work practice, offered but a one-sided diet of examples inevitably resulting in poor
designs. That is, designs that failed to support the practicalities of work’s
accomplishment and were detrimental to the quality of working life. Thus,
inflexible systems if not failures were produced (see Page et al. 1993, for prime
118
example). Today, the rationale for the involvement of workers in design is not one
of making a political gesture but of responding in an effective manner to the needs
of the actual users of future systems of work. Users include not only ‘shopfloor’
workers but a host of others whose daily activities make up the working division of
labour. Under the auspices of Cooperative Design, PD has become a pragmatic
exercise in design then. One that seeks to involve users in the design process in
order that the efficacy and quality of work may be improved through the design of
collaborative systems that support the real world, real time needs of all its users,
and not only the needs of a select few. This orientation to design is predicated on
recognition of the fact that work is a collaborative achievement, the product of the
concerted daily efforts of a wide range of users. Cooperative Design seeks to
support that concerted accomplishment – i.e., cooperative work - through the active
participation of relevant parties to the design process: workers, managers, business
strategists, and the rest.
The pragmatic turn in PD has not passed without remark from practitioners in
the field. Bjerknes and Bratteteig (1994) argue, for example, that under the auspices
of Cooperative Design, a concern with workplace democracy has been replaced by
a concern with the quality of work:
Greenbaum and Kyng argue for participation emphasising usefulness and
quality of the product, i.e., influence on the work situation, not workplace
democracy … Cooperative Design certainly supports user participation. But
the focus on process, action, and situatedness tends to disconnect the design
process from the larger organizational context in which power is enacted.
Such arguments of course reflect a commitment to a certain political ideology,
which might accurately be described as Marxist in character. As noted in Chapter 2,
the adequacy of such a position presupposes the adequacy of Marxist formulations
of the labour process, formulations that are general and theoretical and in such
detail wholly inadequate when it comes to understanding any particular practice
(and all practices are particular). What is often overlooked by ideological
champions is that Marx’s work was as much a moral critique of capital society as a
scientific thesis and needs no other justification than that. Understood as a moral
argument against the excesses of a capital social order, Cooperative Design might
well be understood to be promoting workplace democracy by including relevant
parties (stakeholders) – parties who were not previously consulted – in the design of
socio-technical systems that promote the quality of working life in being tailored
from the outset for the practical circumstances of their actual use: an achievement
which is good for users and for the accomplishment of Organizational business.
That Cooperative Design practices are not as radical as some would wish can hardly
be taken as a serious critique of their efficacy in the design of acceptable
collaborative systems.
More seriously, perhaps, Cooperative Design (or the Collective Resources
Approach as it is sometimes referred to along with other PD practices) has been
subject to severe criticism with respect to its ability to include users in the design
process. Cooperative Design has been charged with inflating the successes of
action-based research and design by doing.
119
The Collective Resources Approach (CRA) has not been accepted by workers
and unions nor affected in a major way the day-to-day practice in
Scandinavian work places … [it] seems even less likely to serve as a useful
model for the United States. (Kraft and Bansler 1994)
Kraft and Bansler argue that the prized achievement of formal consultation in
Scandinavia, for example, is effectively a sham. ‘Consultation’ only means that
employers are obliged to notify employees and unions of pending changes and to
hear their responses. Within the bounds of the law, employers may introduce any
technology they choose and manage its implementation and use as they see fit.
Furthermore, Kraft and Bansler argue that the trade unions have developed close
working relations with employers and are reluctant to challenge management
decisions in radical ways lest their positions be damaged. Consequently, Kraft and
Bansler suggest that
there is no team work except on management’s terms … [and] it seems
unlikely that CRA will find much success unless it also succeeds in changing
this century-old system of industrial relations.
Kyng (1994) argues that Kraft and Bansler grossly misrepresent the Collective
Resources Approach, treating it as “some overoptimistic boyscout-like approach”
so naive and simple-minded it cannot but fail. Of particular concern to Kyng are
Kraft and Bansler’s criterion of success.
First, I would have worried had CRA been widely accepted by employers.
Secondly, I can’t think of any sane person who would consider the question of
whether or not CRA “On the whole … has been widely accepted by … the
national unions” as important for its success.
Kyng suggests that what is really at issue here is the old political agenda, which
sought, pace Marx, to bring about the radical reorganization of the workplace and
society at large. In other words, Kraft and Bansler’s critique is based on a
‘puritanical’ political ideology which argues that as Cooperative Design has not
resulted in the radical reorganization of the workplace it has, therefore, failed! As
Kyng reminds us,
A basic concern of CRA is to increase worker influence on technology. The
major instruments are: 1) action oriented and trade union based strategies and
2) cooperative design. Kraft and Bansler .. focus on the first, whereas ‘Design
at Work’ [Greenbaum and Kyng 1991] develops the latter – without much
explicit reference to trade unions. One of the things we hoped to achieve in
this way was exactly to make the work more accessible to ‘non-
Scandinavians’.
Trade union involvement constituted, in part, the context of original work in
Participatory Design but that was and is a local context, not a universal one, one
that is endemic to Scandinavian culture and not others, and not essential in any way
to Cooperative Design. Kraft and Bansler overlook the locality of context and with
it, miss the significance of the inclusion of workers in design practice; namely, that
their inclusion promotes a better understanding of real world work practice in
120
design and thus enhances the possibility of developing acceptable collaborative

systems of work: systems, that is, that are actually used and not detrimental to the
quality of working life. With the recognition of the practical relevance of active
user involvement to design, it becomes apparent that criteria of employer take-up
are irrelevant as well. Cooperative Design is not an employer’s prerogative –
although, as with ethnography, they may elect to deploy the approach as part of
their strategic thinking in undertaking reorganization through the development of IT
solutions – but a designer’s. The success of Cooperative Design practices is to be
evaluated, then, in relation to their efficacy as a means of getting the job of design
done and not by puritanical or any other extraneous criteria.
Evaluation of Prototypes
Having an abiding practical concern with the real world, real time character of work
practice, Cooperative Design has a strong relationship to ethnography (Wynn 1991;
Simonsen and Kensing 1994; Crabtree 1998). Ethnography is a valuable resource in
Cooperative Design, grounding prototyping activities in corrigible accounts of the
social organization of workaday activities, but what more may ethnography
contribute to the design process? Evolutionary prototyping draws our attention to
the evaluation of prototypes, a notion that has been transformed in its use in a
Cooperative Design context. Here, evaluation is not a discrete activity which occurs
late in the design process and is concerned with testing and proving potential
design-solutions, but an ongoing activity engaged early in design and concerned
with involving users in the design of an instrument to support their workaday
activities. It is with respect to this latter achievement that ethnography has more to
offer the design process. First, however, conventional HCI notions of evaluation
will be briefly considered in order that the reader might better appreciate the
purchase of an ethnographic contribution to the evaluation of collaborative systems.
The HCI Tradition

There are many competing definitions as to what constitutes evaluation in design.
Nevertheless, from an HCI perspective,
Evaluation is concerned with gathering data about the usability of a design or
product by a specified group of users for a particular activity within a
specified environment or work context … [HCI views] evaluation within the
framework of people, their work, the environment in which they work and the
technology that they use to do their work. (Preece et al. 1999)
The HCI view of evaluation does not rule out other views on evaluation but defines
its own concern with the problem. Evaluation should be seen as a multi-purpose
endeavour then, one concerned with establishing the adequacy of a host of various
factors ranging from hardware and marketing issues, for example, to usability
issues. The purpose of evaluation in HCI is one of checking that designers’ ideas fit
users real workaday needs. Evaluation assumes a formative character for HCI then,
which is to say that it is concerned to inform the design of systems that meet the
workaday needs of users.
121
With this aim in mind HCI employs a number of methods ranging from the
observation and monitoring of systems usage to more formal survey and
experimental methods. The term experimental is used in the context of HCI in its
scientific sense and consists of an effort to confirm hypotheses in laboratory
settings. As Twidale et al. (1994) note,
It would appear that controlled experiments are generally perceived to be more
objective and to offer the potential of reproducibility. (Strangely, however,
unlike in the natural sciences, it seems that evaluation experiments are rarely
reproduced).
Scientific methods rarely deliver on their promise in design, as the history (in
contrast to the hype) of HCI stands testimony to (Pycock 1999). Such methods are
inadequate as they severely limit the possibility to evaluate the usability of a system
with reference to the real world context of its use. The situation is further
compounded as evaluation in a scientific vein constructs users as objects of study
rather than as active participants in the design process. This is not to make a
political point but a pragmatic one. As Mogensen (1994) puts it,
In analysis in systems development, and cultural anthropology as well, the
‘object’ of analysis is to a large extent human beings and their entanglement in
their everyday lives. In contrast to an analysis of, say, the being of a hammer
or the validity of a proposition, analysis in systems development has an
‘object’ of analysis who has the ability to comment, deny, or agree on the
analyst’s .. understandings.
Scientific methods remove users voices from the design process and put in their
place the analyst’s account. This assumes that the analyst speaks for the user in an
adequate fashion, that the HCI specialist is a user champion (Shneiderman 1987).
Such posturing, which is common in the literature, says more about HCI’s need to
assert its legitimacy in design than it does about its ability to actually promote user
interests and to articulate their needs. Its ability, that is, to speak on behalf of users
and their work and say just what is right or wrong about a system and what could or
should be done to improve it.
Efforts to get in touch with users and the real world of work have seen the use
of rather more informal methods of observation and monitoring in HCI.
Specifically, video-based observation of users doing both specially devised tasks
and their normal work.
Video logging provides an alternate to direct observation … Sometimes the
video recording may be synchronized with some form of automatic keystroke
or interaction logging, which is built into the system software. Collecting
several kinds of data obviously has the potential for providing a very complete
picture of the HCI being evaluated … In many studies several aspects of user
activity are monitored by different video cameras. For example, one camera
may be focused on the keyboard and screen while another is directed at the
user. The second camera can record where the user is looking at the computer
screen and her use of secondary material such as manuals. Users’ body
122
language can provide useful clues about the way they are feeling about using
the system. (Preece et al. 1999)
This quote makes it clear that the focus of observational methods in HCI evaluation
is human-computer interaction. It might be argued, however, that the focus on the
interaction that takes place between the user and the computer overlooks the
relationship of the computer to the day-to-day work practices of users (Bannon
1991); many of which extend beyond interaction with the machine (such as in the
articulation of information requirement categories in the library) but may,
nevertheless, be supported through appropriate design and evaluation. This is not to
say that analytic attention to computer use is not warranted, only that such attention
should be extended to address use in relation to work practice (to the socio-
technical context of use) and not human-computer interaction alone, which is too
narrow a focus (Twidale et al. 1994). It is also a focus that, in analysis, comes to
gloss work practice insofar as it is underpinned by methods such as task analysis,
which guarantee the loss of real world work practice in decomposing activities into
prefigured categorical hierarchies of tasks and sub-tasks, etc. Performance analysis
compounds the problem even further in concentrating on other measurements such
as the frequency of task completion, frequency of errors, task timing, and so on. Of
course, social science modes of analysis may be deployed here, such as
Conversation or Interaction Analysis, but the problem of constructive analysis
remains a significant problem to be reckoned with.
No doubt the notion of science will be invoked by HCI practitioners to justify
their treatment of users and their work, and the necessity of grounding evaluation in
scientific methodologies. There is no compelling reason why such accounts should
be accepted in design, however.
Amongst the numerous evaluation techniques, it is clear that the scientific
paradigm influenced many of them. The influence of the paradigm is apparent
in the tendency to regard formal techniques [such as task analysis] as
somehow more ‘proper’ because the ‘proving’ of the system renders it
‘complete’ … within the engineering paradigm [however], and unlike in
science, proof by construction is permissible. Thus, the historical relationship
between engineering approaches and ‘scientific’ evaluation is not a necessary
one. (Twidale et al. 1994)
Science demands certain methods of proof but design is not, nor has it ever been, a
science. Rather, design is a practical activity occasionally informed by science,
engineering, marketing, management, art, and host of other practical crafts. There
is, therefore, no necessary relationship – and thus, no compelling reason – for the
use of scientific evaluation methodologies in design. On the contrary, as a branch of
engineering, evaluation in design might proceed with good reason through proof by
construction (good reason being the irremediably ‘wicked’ character of design).
And that, of course, is just what Cooperative Design proposes in the construction of
evolutionary prototypes in collaboration with users, ethnographers, and others.
123
Alternates to HCI
It is with respect to assessing a system’s practical relationship to users cooperative
work that ethnography may add value to the evaluation of collaborative systems,
particularly where early and incomplete prototypes supporting and changing the
social organization of work are concerned. As Twidale et al. (1994) put it,
This shift in emphasis away from the system as a technical artefact towards
the system at work has a number of important implications for the evaluation
process, implications which place ethnographic insights … at its centre, at
least if system ‘validity’ or ‘acceptance’ is the problem being addressed.
And again,
the idea that evaluation should occur late in the development process, should
be concerned with machine or software functionality, and should concern
itself with ‘objective’ results sits strangely with the concern for the social
organization of work that characterises CSCW. We [are] led to question
whether systems for use in cooperative work environments can indeed be
evaluated for validity in isolation from the work.
The use of ethnographic insights in addressing the potential validity and
acceptability of prototypes is characterised as Situated Evaluation. It consists 1) of
the re-use of work studies to assess the prototype’s work-ability, which may be
assessed by ethnographers working through existing functionality in cooperation
with designers with an eye towards establishing whether or not the prototype
supports known patterns of cooperative work. 2) Work studies may also be
conducted to evaluate the results of Cooperative Prototyping sessions. There is, of
course, nothing new in taking a pragmatic approach to evaluation – prototyping
sessions have long been treated as sites of work that may be studied to inform
design. In such cases, however, analytic attention is usually accorded exclusively to
the user (Grint and Woolgar 1997). In conducting Situated Evaluation of
Cooperative Design sessions, analytic attention is accorded to the work that makes
the technology work in situ, and that includes the work that takes place between
users and designers. This work is often ignored in Cooperative Design sessions,
discounted as dealing with ‘bugs’ and the like. However, it is through repairing
glitches, breakdowns, troubles, and the rest, that users and designers put the
technology to work and there is, then, much to be learnt from the interactions and
collaborations of users and designers in their concerted efforts to make the
technology work.
The library prototype, for example, was made available to end-users in a
variety of settings ranging from public exhibitions to small workshops involving
academics, students, and administrative staff who needed as part of their day’s work
to search the library in order to find particular resources. When evaluating the
prototype we were not particularly concerned with various categories of user (as in
HCI) but to establish whether or not the prototype supported current work practice
regardless of category (as all categories must engage in categorisation work).
Assessing a prototype’s work-ability proceeds by treating prototyping sessions as
sites of work that are amenable to work study. Attention is paid to all the work -
124
including the work done by developers in setting the scene and handling
contingencies - that goes on during prototyping sessions, and not just to users
interactions with the machine as in HCI. Prototyping sessions, usability trials,
workshops and the rest are cooperative accomplishments in which developers play
an instrumental role in putting the technology to work, yet this fact is routinely
ignored and with it, a host of issues relevant to the design of collaborative systems
are passed by. Situated evaluation redresses this imbalance in paying analytic
attention to the cooperative work that the site’s staff – users and developers –
together engage in, in the effort to make the tool respond to the pragmatic demands
of particular work activities (Crabtree et al. 2002b). Twidale et al. (1994) elaborate
the rationale at work here in pointing out that
If the subjects are asked to perform tasks which relate to their particular
concerns, the tool will be directly challenged as to whether it can support
those tasks.
When the tool is challenged, designers are challenged, especially in terms of
unexpected consequences of user actions. The prototype may crash, for example, it
may not support the doing of particular tasks as users would want it to, it may have
missed important areas of functionality, and in so many contingent ways it may
elaborate needs that the designers must work round and manage in situ; needs that it
is important to take into account in future iterations of the prototype. Thus, the
prototype is treated as a triggering artefact, challenging practice, provoking insights
into the technical nature of change and the limits of the current prototype, and so
acts as a catalyst for further investigation and iteration in design.
As prototyping sessions are usually conducted with only a small number of
users then so too Situated Evaluation is evaluation of the work of a small number of
users, and developers. Although iteration may proceed quite effectively through the
involvement of many small groups of users, globally distributed ones even, those
committed to traditional HCI practices are likely to find Situated Evaluation far
from satisfactory. As Twidale et al. (1994) put it, for example,
a possible objection .. would be that the small number of end-users is
unrepresentative. However, in one sense, no end-user is unrepresentative in
that all end-users’ viewpoints and requirements reflect a context in which the
system may have to function and, in the first instance, we [are] concerned to
identify some and not all ways in which the system might under-perform or
cause problems.
What is being suggested here is that small user groups are representative, not in
terms of broad categories of different users but in terms of the work members of
small groups are required to perform. As Sacks (1984) pointed out, “Tap into
whomsoever, wheresoever, and we get much the same things”. We get much the
same things because activities of work are not tied to broad categories of users. On
the contrary, broad categories of users are tied to workaday activities, which are
tied to particular settings. Thus, consulting but a small number of competent
practitioners – i.e., skilful doers of workaday activities - can elaborate much about
the general character of support for workaday activities even in large Organizations
of Work (Christensen et al. 1998).
125
Cooperative Design and Situated Evaluation respecify the notion of evaluation

in design, moving it away from a concern with science, formal methodologies, and
human-computer interaction, to a concern with the practical relationship of
potential design-solutions to cooperative work in the real world. Thus, insofar as
CSCW systems are concerned,
evaluation work will have to be conceived of not as something separate from
other stages in the design process but as a necessary feature of all design work
(Twidale et al. 1994)
Indeed, evaluation becomes the driving force in the design of collaborative systems
following initial analysis of the design space and prototyping work, propelling the
elaboration of use cases and refinement of design solutions.
Cooperative Design in Action

The following section consults a perspicuous setting in order to provide a concrete
example of Cooperative Design and the role of Situated Evaluation therein. The
example may be read not only as description of design in action but also, in an
instructional way, which informs the reader as to how Cooperative Design and
Situated Evaluation may be accomplished. In other words, the account provided
below is a praxiological account that displays some significant aspects of the work
involved in doing Cooperative Design and Situated Evaluation. That work may be
undertaken in alternate settings of design.
Situated Evaluation (Formulating Design Solutions 3) 26

As with the study of cooperative work in general, Situated Evaluation may be
accomplished by explicating members’ conversational formulations and relevant
non-vocal practical actions. Formulations display the interaction being engaged in
by the parties to the talk and so make the work of prototyping sessions available to
report and analysis. As that work is work organized around the use of a prototype to
accomplish some given job, it follows that the work made visible by members’
formulations will serve to make the use of the technology visible. The following
edited sequence of talk was preceded by an introduction by the ethnographer
(Andy) telling the users (Tina, Claire, Simon, and Vince) about the studies of
searching’s work in the library and the intended relationship of the prototype to that
work. The ethnographic studies were used to elaborate a practical context for the
prototype’s use. The users were all familiar with the library in workaday ways: as
graduate students, lecturers, and academic support staff. Each was asked to come
along to the session with a topic-based search query in mind. The users were then
informed that Jonathan (one of the designers and the demonstrator on this occasion)
would first do a pre-engagement walkthrough showing the users how the prototype
worked and would then invite each user to have a go with his support. Help desk
staff were not invited as the purpose in this trial was to establish whether or not the
___________
26
Once again, the study reported her is not intended to be exhaustive but
illustrative. See Crabtree (1999) for further details.
126
prototype would support mediation between library users and the catalogue in its
use. This is not to suggest that the prototype seeks to automate help desk work,
work studies indicate it is far to simplistic a device for that. Nor does it seek to
replace OPAC, which works well in many search situations. Rather, the prototype
should be seen as augmenting OPAC and intermediation in novel ways, providing a
new interface at a point where troubles routinely occur in the course of searching’s
work. Predicated on studies of cooperative work involved in resolving search
troubles, the prototype furnishes users with novel categorisation resources to
negotiate the library catalogue and provides help desk staff with historical resources
to perform categorisation work with users in times of trouble.
Pre-engagement Walkthrough
Jonathan: Okay, what we’ve tried to do is, when you normally do an OPAC search
you’ll normally get back say up to five hundred results on a particular keyword you
type, and they’re not organized in any particular way - just a great long list which is
obviously a bit of a pain if you have to browse through that.
Claire: uh uh
Jonathan: And what we’ve tried to do in this 3D visualization is to take those results
that come back from an OPAC search and group them according to how similar
they are to each other. So, if you get lots of things in the same classmark, it might
be interesting to see all the books that are in one classmark ‘cause they’re obviously
related to each other in some way in the library.
Claire: uh uh
Tina: uh uh
Figure 23. Introducing users to the machine.
127
Jonathan: Or you might want to see all the books of that keyword of a certain
author, or authors put together. So the idea is that when we put these things into the
3D landscape they form clouds or blobs of similar books and things that come back
from the search. You can change how important certain factors are for how they
cloud together and then once it’s visualized in front of you, you can browse those
results to get out information as you would do in a normal OPAC.
Tina: Brilliant.
Jonathan: Okay?
Tina: uh uh
Jonathan: So, if I start talking gobbledegook somebody tell me and that will help
okay?
Jonathan: So what I’ve done initially here, we have a search that’s visualized on
this display here on ‘Mariani’ as a keyword. Obviously you’d sort of expect that to
come back with authors Mariani, and anything else that happens to be categorised
with the keyword Mariani. The circles in the landscape represent the books that
have come back okay, and the links between these circles indicate that there is some
connection between them (Jonathan points to circles and links respectively).
Claire: uh uh
Jonathan: And when the connection is very high, they get grouped into these
coloured regions (points to clouds).
Claire: umm
Jonathan: So obviously these books here, here, here, (pointing at objects in the
landscape) and there’s one just behind there, are all very similar according to some
categorisation which we’ve applied.
Jonathan: So if we look at this - just by clicking on the button here (clicks on
bibliographic display) - it tells us more information in one of the windows and you
can also see some more information on the display, which can be a bit hard to read.
Figure 24. Articulating core features of the machine.

128
Jonathan: So if we just click on a few of these. They’ve all got a very similar
classmark which is VKI, VBI, and VCN, so these are probably very close to each
other within the library.
Claire: umm
Jonathan: These outriding things here have PR which is classmark, XMLA which
has no other connections, and so on. These are weighted strongly according to
classmark. If we chose to change the weighting so we’re not very interested in
classmarks anymore but we’re interested in the type of publication - that’s CD-
ROM or book or something like that - so we’d like to see all the CD-ROMs
together, then we can turn up the importance of CD-ROM - of the type of
publication (Jonathan points to and changes the weighting). Then what it does is it
reorganizes the space – er, not very well in this case - so that the green ones here
are over-size pamphlets it looks like - you can see here and here - and the red ones
are over-size books. So it’s trying to draw together the similar things in the search
that was issued.
Jonathan: So that’s a very small search. If I do a bigger search, on ‘java’, when you
do a search it starts pulling them back from the OPAC system then it populates the
space by sort of spitting them out at you (Jonathan issues search on ‘java’). Okay,
so it’s put them all into the space and now it’s arranging them according to
classmark which is the default arrangement. You can see that there’s a lot of yellow
blobs in the middle here which have got a very similar classmark apparently.
Claire: um
Jonathan: They’re all congealing together. You’ve got some green ones going off
up here, and eventually they’ll sort of stabilise to an arrangement you can browse.
Okay it’s drawing all the links. So all of these yellow ones here (points to cloud on
screen) have a classmark which is AZKF, which is the programming section in the
library. We’ve got seventy-five results but it’s clustered together all of these. If you
were interested in java programming then obviously these books are going to be
very interesting to you. These outlying ones (i.e. clouds) will be things like – er,
what’s that one on - designing web applications, yeah, aesthetic tradition and
artistic transition in java that is, which is obviously about the place java rather than
the language java (all the users ‘uh uh’ in concert).
Jonathan: In OPAC they come back together and they’re grouped together. Here it
separates them out based upon classmark in this example.
Claire: uh uh
Jonathan: So, one way of moving round the space and browsing these things is to
use the forwards and backwards buttons (Jonathan points to keys), the keypad
which turns you and moves you backwards and forwards.
Claire: um
Jonathan: You can click on objects to centre them (Jonathan clicks on an object
using the mouse).
Claire: um
Jonathan: And you can zoom in to get more information (Jonathan uses keys to
zoom in). That will come up here (points to text on 3D display). You can also move
around the space just by pointing things into the view. So here I’m navigating just
129
by putting anything into the cross hairs (using mouse; clicks on mouse – object
information comes up in text box).
Figure 25. Articulating basic machine operations and controls.

Jonathan: Right, so does everybody sort of understand what it’s all about now?
Claire: um
Tina: um
Jonathan: Is that um yes or an um not quite?
Claire: I think so, yeah.
Tina: Yeah.
Simon: I was thinking, how do you zoom in and out? Just click on what you want?
Jonathan: You can click on each one to centre and that puts it in the middle, and the
zoom is just the forwards and backwards buttons.
Simon: Oh yeah.
Jonathan: So that’s fairly simple.
Simon: That’s pretty good.
Jonathan: Then you hit the space bar to move between what this view is - the one
that sort of turns you and you can look anywhere
Simon: Yeah.
Jonathan: Then you hit the space bar again and you’re just on the normal
Simon: Oh, okay.
Jonathan: Backwards and forwards, and again, you can just click on whichever
Simon: Right.
Jonathan: Particular thing you want to look at, like that.
Simon: Right, okay.
130
Praxiological Points
The pre-engagement walkthrough was explicitly intended to introduce users to the
machine and familiarise them with its core features, basic operations, and controls
in order to engender amongst users a concrete sense of just what the machine is all
about and how to go about using it. Seeing the sense of the machine is crucial to
Cooperative Prototyping and may, as above, be engendered by employing use
scenarios to articulate sequential orders of work and machine interaction. Thus, the
sense of the machine is made practically available to users, as expressed in
formulations of mutual understanding produced as the walkthrough unfolds, which
are confirmed quite explicitly as the walkthrough is brought to a close and
problematic issues are clarified.
Jonathan: Right, so does everybody sort of understand what it’s all about
now?
Claire: um
Tina: um
Jonathan: Is that an um yes or an um not quite?
Claire: I think so, yeah.
Tina: Yeah.
Simon: I was thinking, how do you zoom in and out? Just click on what you
want?
Engendering a shared sense of the machine is not the only practical purpose of the
pre-engagement walkthrough. Attention to the formulations in and through which
the work is constructed and conducted inform us that the walkthrough is also
intended to provide an unfolding course of instruction and training sufficient for
users to initiate hands on interaction and to experience the machine for themselves.
This course of training is not meant to be exhaustive but only intended to furnish
enough information about the machine so as to provide for the undertaking of
engagement. It is a sequentially ordered course of contextualisation consisting of
the following praxiological features.
q Patterns of cooperative work elaborated by ethnographic studies of work are
employed in order to embed the machine in a use context, articulating the
purpose of the machine (e.g. to support searching in the library) and the work
it is intended to support (e.g. categorisation work).
q Use scenarios are employed in order to articulate what the machine is (e.g. a
3D visualization and interrogation device) and how it supports the work of the
site (e.g. it groups search objects into distinct yet connected regions on the
basis of user definable similarity criteria). Use scenarios are further employed
to elaborate sequential orders of work and interaction (e.g. that searches are
issued by entering a search term in the keyword box, that the search criteria
whereby objects are grouped may be changed in the weightings box, that the
machine groups objects together in clouds and links related objects and clouds
together; that users may interrogate clouds by pointing and clicking the
mouse, that bibliographic details are displayed on selecting an object, and so
on).
q Underpinning the employment of use scenarios is an ordinary pedagogical
method of demonstration by ‘showing and doing’ which serves to ostensively
131
define the prototype’s functionality (that searches may be issued by entering a

topic-related keyword; that similarity criteria may be altered using the
weightings mechanism; that user may navigate the space using either the keys
or the mouse; that bibliographic information is displayed by using the mouse
to select an object, etc.). In working up, and through, this distinct course of
instruction, novice users are informed as to what the prototype is all about and
how to go about undertaking use.
Thus, the pre-engagement walkthrough provides for the intelligibility of the system
and furnishes a course of training for the initiation of user engagement with the
machine.27 Praxiological aspects of user engagement are considered below. The
numbered headings indicate practical issues of relevance to design made visible in
users and developers formulations.
Drive One
Jonathan: So, does anybody want to have a first drive?
Tina: Aye, I’ll have a do. So this is what I would be greeted with in the library then,
yeah, that type of thing?
Jonathan: Yeah. So what you’d normally do is
Tina: How I usually do it is to type in either an author that I’m interested in or, as it
stands at the moment, certain keywords that I’d be interested in.
Jonathan: Okay.
Tina: Alright? (Tina types ‘retail’ into the keyword box and issues the search).
Jonathan: This isn’t going to work actually – ‘cause retail is a bit too big (the
prototype crashes).
Jonathan: We need a bit more of a specific search.
1. Crash and Repair
Jonathan: Okay. I’ll have to clear a few things off now I’m afraid, since it didn’t
enjoy that very much.
Tina: Well it’s not good enough - that’s what I want to know (everyone laughs and
Tina sighs in mock resignation).
Claire: You’ve messed it up.
Jonathan: We’ll just cheat to find out how many hits we’ll get and then I can
guarantee if it will work or not (Jonathan runs an ordinary webOPAC search to
establish a search of manageable size – a search that will not crash the prototype:
less than 100 hits).
Jonathan: Okay (prototype running again). I’m doing title (search criteria on
webOPAC).
___________
27
The significance of this course of training for design is that it is a course of
training that may eventually be supported through the machine itself thus promoting
its usability in real world settings (settings in which users are left to their own
devices). Naturally, that course of training will alter as the prototype evolves but as
prototypes stabilize so too do the courses of training involved in their use. There is,
then, much of relevance to design to be learnt from attending to the praxiological
features of the work developers and users together engage in to make the
technology work in user trials, however they are conceived.
132
Tina: Shops and shopping.

Jonathan: Thirty (hits). Is that a vaguely interesting keyword that you could
possibly search on?
Tina: Yeah, yeah.
Jonathan: Well let’s have a go for that one and see how we go. So, off you go.
Tina types in ‘shops’ and issues the search.
Resuming the Drive
Jonathan: It should be spitting them in soon. So what happens now is the system’s
gone off and it’s put them into its database and now it’s going actually put them
into the space.
2. Locating Returned Objects
Tina: Will I get all those little starburst things?
Jonathan: Yes, you should.
Tina: How nice!
Jonathan: Well you are doing but it’s hiding them from you. (Jonathan uses
navigation keys to bring objects into view). Okay.
Resuming the Drive
Tina: Victorian (talking about an object on screen). Right. The colours are similar?
Jonathan: They’re the ones that have been said to be very similar to each other.
Tina: Okay.
Jonathan: If it has more than two in a region it actually draws a little shape around it
like this (points to area on screen).
Claire: um
Jonathan: But if it’s only two it doesn’t draw a shape, it just connects them with the
same colours.
Tina: So I want to look at ‘specialist’. So I just whizz in and click on that yeah?
Jonathan: Yeah.
3. Selecting Objects for Viewing
Tina: Twice?
Jonathan: I think it’s because it’s actually under here. Try this one first, then this
one second.
Tina: Why would I do that?
Jonathan: You shouldn’t have to, it should just be one click.
Tina: Okay.
4. Seeing Full Title
Tina: How would I make the title bigger?
Jonathan: To see more of it?
Tina: Yeah.
Jonathan: You can’t at the moment.
Tina: So how would you get to know - I mean, that’s one of the things we’re
looking at. Normally I go by - whether I think something is going to be interesting
or not - is by the title, you know, if it’s an area I don’t know anything about.
Jonathan: Yeah.
Tina: You think, oh well, that’ll do - you know what I mean? And if there’s any sort
of disputing the matter I go and have a look at the book itself.
Jonathan: Sure.
133
Tina: Right?
Jonathan: Sure.
Tina: So if this is just going to come up like that, depending on whether you’re tired
or not or whatever, you might think, oh well, fuck it!
Jonathan: Right, yeah.
Tina: So that’s a bit of a worry isn’t it?
Jonathan: Right, okay.
5. More Information
Vince: Do you use the keyword at all. I mean, it’s not on the window there. You
know, like on the bottom of OPAC it’ll have keywords often or subject. Things like
shops, and it’ll have like shopping, consumerism, stuff like that down at the bottom.
Jonathan: No, we don’t use that.
Vince: Oh, okay.
Jonathan: But that would be interesting I suppose. If you entered one keyword to
lead you to the other
Vince: Yeah, yeah.
Jonathan: Related keywords.
Claire: um
Ending the Drive
Tina: Should I let someone else have a go now? That’s how I would do it, okay?
Claire: um
Tina: That’s how - when I go and look for a book - if I don’t actually go to the
shelves themselves.
Jonathan: Yeah.
Tina: Which means that you’ve got some sort of fore knowledge of what you’re
looking for anyway.
Jonathan: um
Tina: I’ll go on, you know, title or something. I mean that’s the sort of basis of your
research isn’t it? Like the keyword or something. And of course we then start
getting frustrated when either too many come up or
Jonathan: Well it’s too many that’s generally the problem isn’t it? ‘Cause when it’s
only ten or something, you can sort them in your head (Simon, Claire and Vince
‘um’ agreement)
Tina: That’s how I would use it.
Jonathan: I mean, OPAC only gives you back a maximum of five hundred and
obviously we’d like to show you big searches of five hundred but with the current
restriction, as we’ve seen, it obviously doesn’t cope very well with much more than
a hundred.
Tina: Well who’d do it anyway, I’ve only to see a list and I start crying and wanting
to go home!
Praxiological Points
Each of the users performed a drive, and each encountered possibilities and
constraints that impacted upon their use of the machine. As in the library, users
worked together in an arrangement of shoulder-to-shoulder cooperation, assisting
each other in becoming users of the machine, formulating keywords together,
134
identifying potentially relevant items together, performing successful searches

even:
Figure 26. Supporting real world work practice.

Reprinted with permission from Crabtree (2002b)
Vince: How about ‘juvenile delinquency’? I’ve to find a video for the prison
tomorrow any way. (Vince issues a search query on ‘juvenile delinquency’).
Tina: (Looking at screen) That’s nice (talking about visual layout).
Vince: Yeah. Right - well let’s start. (Starts navigating clouds). Alright, so blue is -
book. Okay. Alright.
Claire: What’s green there?
Simon: Green and grey.
Vince: Pamphlet. OK, we’re doing fine.
Simon: Oh - you got reds up there.
Vince: Yeah. Okay. So that’s book. Okay. What have we got down here - pamphlet
Jonathan: Blues are pamphlets.
Vince: I think that’s all the colours, right?
Jonathan: White ones are the oddments that don’t go into anything else. They could
be like an individual CD-ROM. That’s a Lancaster dissertation.
Vince: Yeah. Okay. Er
Simon: Videos!
Vince: uh uh. There we go, ‘signs of the troubled aspects of delinquency’. I might
actually write that down (Vince writes classmark and title down on a notepad).
135
As the formulations make it plainly visible, users not only recognised the
relevance of the prototype to searching’s work - even Tina’s castigation of the
machine for its lack of title information trades on the recognition of the prototype’s
relevance to searching – they also appropriated the prototype for their workaday
purposes. Although the prototype was incomplete, users could see the sense and
relevance of the machine to the job of searching and could, quite demonstrably,
appropriate the machine for purposes of accomplishing searching’s work. Thus, the
prima facie work-ability of the prototype was established by users in their concerted
efforts with each other and the designer to get the technology to do a real job of
work. At the same, and as an observable feature of cooperative work in the
prototyping session, users interactions with the prototype triggered further analysis
of the design space and informed the ongoing formulation of the design solution.
Analysis of the design space was particularly pronounced when practical
troubles were encountered in the course of interacting with the prototype. Troubles
were encountered when the prototype ‘crashed’, for example. This was not simply a
technical failure but an interruption in the production of the workaday activity of
searching, which had to be repaired if the activity was to proceed. How crashes are
managed and repaired becomes a matter of some importance then. In the above
case, the crash was repaired through the use of the webOPAC to produce searches
of manageable proportion. Clearly, the formulation of large searches was something
that the prototype needed to support and the event raised the non-trivial issue of
designing an effective algorithm to handle the task. Having executed a manageable
search, users often found themselves confronted by a blank space. This perplexed
and disoriented users and brought to light the need for a default view onto the
space, which would automatically focus users onto the search results. A number of
practical troubles also emerged when users tried to interact with objects in the 3D
space. Some difficulty was experienced in discerning which side of the cloud an
object was on when objects were grouped into densely packed clouds, and users
consequently found it difficult to pick out particular objects as objects overlapped
and obscured one another making searching difficult. Although the problems here
were navigational ones, they were not ones concerning the navigation vehicle but
the spatial distribution of objects, again a non-trivial matter this time of designing
an effective placement algorithm.
Users encountered a number of practical difficulties when trying to select
objects for viewing. Firstly, there was the simple difficulty of clicking on an object.
Secondly, difficulties were experienced in clicking on objects on the far side of
clouds. And thirdly, users found that they could not click on objects within clouds -
although they could use the cross hairs to view objects within a cloud. The analytic
point to note here is that users preferred, and indeed displayed something of a
natural propensity in their interactions with the prototype, to use the mouse and
cursor as the primary means of navigation and difficulties were experienced when
the prototype failed to support this natural expectation. Further difficulties emerged
in the course of trying to relocate particular objects that had previously been
identified as potentially useful. The problem was resolved through the cooperative
efforts of the users in retracing the history of the search trail, work which might be
easily supported through the addition of a history function. The primary resource
that users employ in establishing an object’s potential relevance to their information
136
requirements is its title and sub-title, which suggest what the object is all about. The
prototype did not provide this information in full. Although a simple point, it is an
extremely important one from the point of view of users, and one that the work-
ability of the prototype ultimately trades upon. These and a host of other practical
troubles elaborated by users in their conversational formulations when interacting
with each other and the prototype, extended the analysis of the design space and
served to inform the ongoing elaboration of the design solution.
Encountering practical troubles was not (and is not) the only way in which
users may inform analysis and design, however. Their conversational formulations
also serve to illuminate new possibilities for design emerging from analysis of
current work practice and the affordances of the technology to hand. In the course
of interacting with the prototype it was suggested, for example, that it would be
desirable for the prototype to display keywords that are related to the search
keyword employed by the user. This would support the performance of searching in
furnishing related topics of and for inquiry. Users also wished to be able to browse
all the objects located within the same classmark when a particular object had been
identified as potentially suitable. The rationale here was that other objects located in
the same classmark might be of relevance to the search as they belong to the same
topical grouping of objects. Existing technologies in the library did not support this
and classmarks had to be searched by going to the physical place in the library.
From a user point of view, the new technology also afforded the possibility of
searching by a process of elimination, which is to say that the new technology
allowed users to narrow down the search not only by interrogating objects that
might satisfy their information requirements but also by interrogating objects that
obviously do not satisfy those requirements. Functionality could be added, then,
that allowed users to delete entire groups of objects from any current search and so
refine the search area.
The constraints and possibilities elaborated by users formulations in the course
of interacting with the prototype shaped the next iteration of the prototype.
Technical modifications were made that meant the prototype could handle a
thousand objects easily and meet the other requirements elaborated by users in the
previous prototyping session. With that work the prototype had been reliably scaled
up to handle large searches. Full titles supporting searching’s online work were
provided. Users could browse co-located items, search by elimination, retrace their
steps, and so on. The prototype was also adapted to support the standard protocol
used by most library OPAC systems, allowing users to search across a wide range
of library catalogues on the World Wide Web. Although the prototype was but an
academic research tool, in contrast to a commercial product, and is now defunct, its
construction was of broader value. On the one the hand its construction has
supported the exploration of the broad properties of abstract virtual environments or
3D environments that are not facsimiles of the real world and contributed to the
reshaping of research agendas in the design of virtual environments (Crabtree et al.
2002b). On the other hand, and of more relevance here, its construction has served
to elaborate methodological ways in which ethnography may be utilised in the
evaluation process and be married to existing design practices to further analyse the
design space and inform the ongoing formulation of design solutions that are
informed by and responsive to the social circumstances of their use. Situated
137
evaluation of cooperative prototyping sessions supports the design of future

systems -of-work that are thoroughly grounded in the day-to-day needs of users.
Constraints and possibilities elaborating contextually relevant user requirements
were - and may in other settings be - identified by attending to the observable and
reportable conversational formulations that make up the ‘prototyping session’ and
by explicating the sequential order of collaborative work and component
interactional events made visible and available to design reasoning by those
formulations.
138
“Methods” (whether avowedly scientific or not)
do not provide a priori guarantees, and the initial
requirement for an ethnomethodological invest-
igator is to find ways to elucidate methods from
within the relevant competence systems to
which they are bound.
Mike Lynch
Summary
The purpose of this book has hopefully been to sensitise the reader to a discrete
ensemble of practical strategies and methods for the study of work and the use of
ethnomethodologically-informed ethnography in the creative process of design. The
book took its departure from the requirements problem and the inadequacies of HCI
formats and methods for describing, analysing and representing the design space.
The suggestion here is that a professional preoccupation with generic analytic
formats and scientific methods ignores, to the detriment of design, the real world,
real time character of work. Rather than elaborate the organization of work in the
wild, as made available in the observable interactions and collaborations of parties
to work’s day-to-day accomplishment, HCI formats and methods offer the designer
second order abstractions that obscure the work practices whereby members’
actually order their work; work practices which systems will be embedded in,
change, and which new systems will inevitably be made answerable to by
practitioners. Having said that, it should not be thought that the rejection of HCI is a
rejection of science. On the contrary, rigour is certainly required in the study of
work. It is, however, to eschew the misappropriation of the methods of the natural
sciences, whose objects of study are of a very different order to those of the work
analyst. Unlocking the mysteries of the atom, the molecule, the gene, and the
workings of the universe more generally, stands in sharp contrast to the study of
grossly observable and reportable organizations of human work practice. If people
do work then the analyst can, in principle at least, go out and see work being done
and so report on how it was done. Unlike the mysteries of natural science, nothing
is hidden where the organization of work is concerned then, although much may be
missed through the use of inappropriate methods of description, analysis and
representation.
Alternate formats and methods guiding the description, analysis and
representation of work have been provided by CSCW. The format articulated herein
is practical rather than theoretical in character and is intended to orient the analyst
to important features of the workplace or factors to be taken into account when
observing and describing work and undertaking analysis of the design space. The
primary orientation here is to cooperative work. That is, to the ways in which
parties to work construct and coordinate their activities. Those ‘ways’ are often
accounted for in a normative fashion, through invoking rules, procedures, and other
formal analytic devices. Without dispensing with these notions, or undermining
their importance, emphasis is here placed on observing and analysing the real
world, real time work practices that an organizations staff devise so that formal
rules, procedures, objectives, requirements, etc., may be met time after time and day
after day as the most routine matter of fact. The key analytic focus here is
predicated on the observation that no matter how routine or repetitive work is, it
must always be constructed and coordinated anew. There is no time out from that
practical requirement, no possibility of evasion: if the job is to get done yet again
than it must be done yet again and so the analyst may observe directly the ‘ways’ in
which work is constructed and coordinated in reportable details of embodied work
practice.
139
Summary
Work practice may be observed through ethnographic study, where the analyst
develops first-hand knowledge of the work in question through immersion in the
work. The analyst’s task here is to explore the work and inspect it closely through
the gathering of materials from within the flow of the work and the assembly of
those materials into instances of workaday activities being done. Instances may be
constructed from the conversations that occur over the course of the work, from the
documents worked on, the artefacts used, from videos, etc. Instances constitute the
unit of analysis and, like the discrete activities they elaborate, they latch together to
articulate the working division of labour and the discrete assemblages of work
practices whereby that articulation gets done. That is to say that instances elaborate
the work activities that occur in a setting and how those activities are constructed
and coordinated in real time. Rather than employ some generic analytic format to
describe and analyse and so identify the work practices organizing the work
activities in question, constructive analytic methods are rejected and replaced with a
concern to produce thick descriptions. Analytic attention is thus directed to the
description of the conversational formulations that occur over the unfolding course
of work’s accomplishment as documented by the instance. This description
illuminates a sequential order of collaborative work, which may in turn be
described with an eye towards identifying the component events the sequence is
made up of. Each component may then be analysed to identify the discrete courses
of practical action or work practices whereby the component is assembled or
constructed by parties to the work.
The identification of sequential orders of cooperative work provides the
opportunity to relate the findings of ethnographic studies to the members of the
design team in a readily digestible way. That is in a way that requires no special
training or expertise. Sequential orders of cooperative work may be thought of as
patterns of practical action, which are routinely appealed to by designers when
analysing the design space for its generic features. Cooperative analysis of the
design space (that is analysis by the design team – designers, ethnographers, and
others) is conducted prior to the use of formal methods through the commonsense
method of typification. This ordinary method of analysis is concerned to identify
stable features of the design space. It is concerned with what typically goes on in
the design space, what information is typical used, how users typically work on
information, etc. In such a way, the method allows the design team to create a
shared sense of the design space and its needs and so formulate initial design
solutions. The method may be supported, and ethnographic studies thereby made
available to design reasoning, through the structuring of sequential orders of work
in terms of an adapted patterns framework. The framework highlights important
aspects of the work studied and outlines the unique work practices whereby
particular work activities are organized in real time by users. It is a presentation
framework that provides a common focus for analysis of the design space, drawing
the design team’s attention to the work activities that typically occur in a setting,
how those activities are socially organized, and the technologies used in the course
of the work. Discussion of these patterns of action serves to generate initial design
solutions, which may then be elaborated through well-established design practices
of scenario construction and the development of working prototypes.
140
Summary
That is not all there is to the analysis of the design space or to ethnography’s
utility in the design process. Working prototypes might be construed of as initial
guesses as to what an appropriate design solution might look like concretely. The
guess stands in need of validation and elaboration. Where the efficacy of the
prototype’s functionality or its work-ability is in question, validity may best be
established by end-users who are the real experts in work’s construction and
coordination and so are best equipped to assess the usability of the prototype in
relation to their work. End-user evaluation might proceed through Cooperative
Prototyping sessions, where users are encouraged to get hands-on the prototype in
order to try to accomplish their work, and through Situated Evaluation of the
cooperative work of these sessions. The validity of the prototype may be
established by attending to three assessment criteria. 1) Can the end-users see the
sense of the prototype from a practical point of view? 2) Can the end-users see the
relevance of the prototype to their work? And 3) do end-users wish to appropriate
the prototype to conduct their work with? Naturally, as with any initial guess
regarding complex matters of work, one would not expect the answer to be yes to
all these questions. They are targets to work towards and their elaboration serves to
propel analysis of the design space in conjunction with the real experts in work’s
accomplishment. Situated evaluation of the work of prototyping sessions supports
this ongoing process of analysis by identifying practical possibilities and constraints
encountered and elaborated in the unfolding flow of the session’s collaborative
work. Paying close and careful attention to the collaborative work that is involved
in putting the technology to work in prototyping sessions demonstrably serves to
elaborate proposed design solutions.
While tried and tested in a number of successful academic and commercial
development projects, both large and small, the practical strategies and methods for
the deployment and use of ethnography in collaborative systems design that have
been articulated here are not offered as a solution to the requirements problem. That
the projects have been successful testifies to the efficacy of multidisciplinary design
work, of which the strategies and methods described here were but a part.
Ethnography, however it is construed and deployed, is not a panacea to the
requirements problem. That problem is a practical problem through and through,
one encountered on each and every occasion of design and for which no silver
bullet exists. It is not an insurmountable problem, however, but one that may be
addressed, often successfully, through multidisciplinary design work. Insofar as
ethnography is a feature of that work, then the approach may be usefully employed
in the ways described here, whether in an evolutionary process of design or a rather
more classical order of work where working prototypes replace the requirements
specification document. Ultimately, the methods advocated here are not intended to
compete with or provide an alternative to formal design methods but to support
those methods in providing an informal method of description for describing,
analysing and representing the social characteristics of the design space. Their use
requires no special training, only a little practice and a commitment to go get your
hands and the seats of your pants dirty.
141
References
Agresti, W.W. (1986) “The conventional software life cycle model”, New Paradigms in
Software Development, pp. 2-5, Washington D.C.: IEEE Computer Society Press.
Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I. and Angel, S.
(1977) A Pattern Language: Towns, Buildings, Construction, New York: Oxford
University Press.
Alexander, C. (1979) A Timeless Way of Building, New York: Oxford University Press.
Armour, D.J. (1997) A Study of Colour: Wittgensteinian and Ethnomethodological
Investigations, Ph.D. Thesis, Lancaster University: Sociology Department.
Baccus, M.D. (1986) “Sociological indication and the visibility criterion of real world social
theorising”, Ethnomethodological Studies of Work (ed. Garfinkel, H.), pp. 1-19,
London: Routledge and Kegan Paul.
Bally, L., Brittan, J. and Wagner, K.H. (1977) “A prototype approach to information system
design and development”, Information and Management, vol. 1, pp. 21-26.
Bannon, L. (1991) “From human factors to human actors”, Design at Work: Cooperative
Design of Computer Systems (eds. Greenbaum, J. and Kyng, M.), pp. 25-44,
Hillsdale, New Jersey: Lawrence Erlbaum Associates.
Bannon, L. and Hughes, J.A. (1993) “The context of CSCW”, Developing CSCW Systems:
Design Concepts, Report of COST 14 “CoTech” WG-4, pp. 9-36, Denmark: Risø
National Laboratory.
Barber, P. (1988) Applied Cognitive Psychology, London: Methuen.
Bardram, J.E. (1996) “The role of workplace studies in the design of CSCW systems”,
Proceedings of IRIS 19, pp. 613-629, Gothenburg Studies of Informatics, Report 8,
June 1996.
Bayle, E., Bellamy, R., Casaday, G. and Erickson, T. (1998) “Putting it all together: towards
a pattern language for interaction design”, SIGCHI Bulletin, vol. 30 (1), pp. 17-23.
Bentley, R.M., Hughes, J.A., Randall, D., Rodden, T., Sawyer, P., Shapiro, D. and
Sommerville, I. (1992) “Ethnographically informed systems design for air traffic
control”, Proceedings of the 1992 Conference on Computer Supported Cooperative
Work, pp. 123-129, Toronto: ACM Press.
Bjerknes, G. and Bratteteig, T. (1994) “User participation: a strategy for work life
democracy”, Proceedings of 1994 Participatory Design Conference, pp. 3-11,
Chapel Hill, North Carolina: Computer Professionals for Social Responsibility.
Blau, P.M. (1964) The Dynamics of Bureaucracy: A Study of Interpersonal Relations in Two
Government Agencies, Chicago: University of Chicago Press.
Blomberg, J., Suchman, L. and Trigg, R. (1994) “Reflections on a work-oriented design
project”, Proceedings of the 1994 Participatory Design Conference, pp. 99-109,
Chapel Hill, North Carolina: Computer Professionals for Social Responsibility.
Blumer, H. (1969) “The methodological position of symbolic interactionism”, Symbolic
Interactionism: Perspective and Method, pp. 1-60, Berkeley: University of
California Press.
Bødker, S. (1987) “A UTOPIAN experience: on the design of powerful computer-based tools
for skilled graphical workers”, Computers and Democracy: A Scandinavian
Challenge (Bjerknes, G., Ehn, P. and Kyng, M.), pp. 251-278, Aldershot: Avebury.
Bødker, S. and Grønbæk, K. (1991) “Design in action: from prototyping by demonstration to
cooperative prototyping”, Design at Work: Cooperative Design of Computer
142
References
Systems (eds. Greenbaum, J. and Kyng, M.), pp. 197-218, Hillsdale, New Jersey:
Lawrence Erlbaum Associates.
Bødker, S., Christiansen, E. and Thüring, M. (1995) “A conceptual toolbox for designing
CSCW applications”, Proceedings of COOP 95, pp. 266-284, Juan-les-Pins,
France: ACM Press.
Boehm, B.W. (1988) “A spiral model of software development and enhancement”,
Computer, vol. 21, pp. 61-72.
Bowers, J. and Rodden, T. (1993) “Exploding the interface”, Proceedings of the 1993
INTERCHI Conference on Human Factors in Computing Systems, pp. 255-262,
Amsterdam: ACM Press.
Bowers, J., O’Brien, J. and Pycock, J. (1996) “Practically accomplishing immersion:
cooperation in and for virtual environments”, Proceedings of the 1996 ACM
Conference on Computer Supported Cooperative Work, pp. 380-389, Boston:
ACM Press.
Braverman, H. (1974) Labour and Monopoly Capital: The Degradation of Work in the
Twentieth Century, London: Monthly Review Press.
Brooks, F. P. (1987) “No silver bullet: essence and accidents of software engineering”, IEEE
Computer, vol. 4, pp. 10-19.
Bucciarelli, L.L. (1988) “An ethnographic perspective on engineering”, Design Studies, vol.
9 (3), pp. 159-168.
Budde, R., Kautz, K., Kuhlenkamp, K. and Züllighoven, H. (1992) Prototyping: An
Approach to Evolutionary System Development, Berlin: Springer Verlag.
Büscher, M., Christensen, M., Grønbæk, K., Krogh, P., Mogensen, P., Shapiro, D. and
Ørbæk, P. (2000) “Collaborative augmented reality environments”, Proceedings of
CVE 2000, pp. 47-56, San Francisco: ACM Press.
Button, G. (1991) “Introduction: ethnomethodology and the foundational respecification of
the human sciences”, Ethnomethodology and the Human Sciences (ed. Button, G.),
pp. 1-9, Cambridge: Cambridge University Press.
Button, G. and Sharrock, W.W. (1994) “Occasioned practices in the work of software
engineers”, Requirements Engineering: Social and Technical Issues (eds. Jirotka,
M. and Goguen, J.), pp. 217-240, London: Academic Press.
Button, G., Coulter, J., Lee, J.R.E. and Sharrock, W.W. (1995) Computers, Minds and
Conduct, Oxford: Polity Press.
Button, G. and Harper, R. (1996) “The relevance of ‘work-practice’ for design”, Computer
Supported Cooperative Work: The Journal of Collaborative Computing, vol. 4 (4),
pp. 263-280.
Buxton, J.N. (1978) Software Engineering Programming Methodology, Berlin: Springer-
Verlag.
Card, S.K., Moran, T.P. and Newell, A. (1983) The Psychology of Human-Computer
Interaction, Hillsdale, New Jersey: Lawrence Erlbaum Associates.
Carlsson, J., Ehn, P., Erlander, B., Perby, M.L., and Sandberg, A. (1978) “Planning and
control from the perspective of labour: a short presentation of the DEMOS
project”, Accounting, Organizations, and Society, vol. 3, pp. 249-260.
Carlsson, C. and Hagsand, O. (1993) “DIVE – a platform for multi-user virtual
environments”, Computers and Graphics, vol. 17 (6), pp. 663-669.
Carroll, J. (ed.) (1995) Scenario-Based Design: Envisioning Technology in Use, New York:
John Wiley.
Christensen, M., Crabtree, A., Damm, H.D., Hansen, K.M., Madsen, O.L., Marqvardsen, P.,
Mogensen, P., Sandvad, E., Sloth, L. and Thomsen, M. (1998) “The M.A.D.
143
References
experience: Multiperspective Application Development in evolutionary
prototyping”, Proceedings of the Twelfth European Conference on Object-Oriented
Programming, pp. 14-41, Brussels, Belgium: Springer.
Churchland, P.S. and Sejnowski, T.J. (1994) “Neural representation and neural
computation”, Mind and Cognition (ed. Lycan, W.G.), pp. 224-252, Oxford:
Blackwell Publishers.
COMIC Deliverable 2.1 (1994) “Panaceas and rhetorics in system design”, Informing CSCW
Requirements, pp. 21-76, Esprit Basic Research Project 6225, Lancaster
University: Computing Department.
Coser, L. (1975) “Two methods in search of a substance”, American Sociological Review,
vol. 40, pp. 691-700.
Coulter, J. (1990) Ethnomethodological Sociology, Aldershot: Edward Elgar.
Coulter, J. (1991) “Cognition: cognition in an ethnomethodological mode”,
Ethnomethodology and the Human Sciences (ed. Button, G.), pp. 176-195,
Cambridge: Cambridge University Press.
Coulter, J. (1999) “Discourse and Mind”, in Human Studies, vol. 22, pp. 163-181.
Crabtree, A., Twidale, M.B., O’Brien, J. and Nichols, D.M. (1997) “Talking in the library:
implications for the design of digital libraries”, Proceedings of the 2nd ACM
International Conference on Digital Libraries, pp. 221-228, Philadelphia,
Pennsylvania: ACM Press.
Crabtree, A. (1998) “Ethnography in participatory design”, Proceedings of the 1998
Participatory Design Conference, pp. 93-105, Seattle: Computer Professionals for
Social Responsibility.
Crabtree, A. (1999) “Situated evaluation of the demonstrator”, eSCAPE Deliverable 4.1 The
Library Abstract eSCAPE Demonstrator (eds. Mariani, J. and Rodden, T.), pp.
109-146, Esprit Long Term Research Project 25377, ISBN 1 86220 079 3.
Crabtree, A. (2000a) “Talking work: language-games, organizations and computer supported
cooperative work”, Computer Supported Cooperative Work: The Journal of
Collaborative Computing, vol. 9 (2), pp. 215-237.
Crabtree, A. (2000b) “The practical availability of work-practice to ethnomethodology and
conversation analysis”, paper presented at The 2nd Workplace Studies Conference,
27th October, Manchester, United Kingdom: British Sociological Association.
Crabtree, A., O’Brien, J., Nichols, D., Rouncefield, M. and Twidale, M. (2000a)
“Ethnomethodologically informed ethnography and information systems design”,
Journal of the American Society for Information Science and Technology, vol. 51
(7), pp. 666-682.
Crabtree, A., Pettifer, S. and Rouncefield, M. (2000b) “Designing virtual environments for
social interaction, Proceedings of Virtual Reality International Conferences 2000,
pp. 118-129, May 18th-21st, Laval, France: VR News.
Crabtree, A. (2001a) “On the practical availability of work-practice”, Ethnographic Studies
(eds. Francis, D., Hester, S., Hughes, J., and Sharrock, W.), Issue 7, Summer 2001.
Crabtree, A. (2001b) “Doing workplace studies: praxiological accounts – lebenswelt pairs”,
TeamEthno Online Journal, vol. 1 (1). www.teamethno-online.org/
Crabtree, A., Rouncefield, M., and Tolmie, P. (2001a) “‘There’s something else missing
here’ - BPR and the requirements process”, Knowledge and Process Management:
The Journal of Corporate Transformation, vol. 8 (3), pp. 164-174.
Crabtree, A., Hemmings, T. and Rodden, T. (2001b) “Domestic legacy and design”,
Proceedings of the 1st Equator Workshop on Ubiquitous Computing for Domestic
Environments, The University of Nottingham: ISBN 0-85358-100-2.
144
References
Crabtree, A. and Rodden, T. (2002) “Technology and the home”, Proceedings of the 2002
Conference on Human Factors in Computing Systems, CHI Workshop on
Technologies for Families, 20th-25th April, Minneapolis: ACM Press.
Crabtree, A., Hemmings, T. and Rodden, T. (2002a) “Patterns-based support for interactive
design in domestic settings”, Proceedings of the 2002 Symposium on Designing
Interactive Systems 2002, 25th-28th June, London: ACM Press.
Crabtree, A., Rodden, T. and Mariani, J. (2002b) “Designing virtual environments to support
cooperation in the real world”, Virtual Reality, vol. 6 (2), pp. 63-74.
Crabtree, A., Rodden, T. and Hemmings, T. (2002c) “Coordinate displays in the home”,
Proceedings of the 2002 ACM Conference on Computer Supported Cooperative
Work, CSCW Workshop on Public, Community and Situated Displays, 16th-20th
November, New Orleans: ACM Press.
Decker, K. (1996) “TAEMS: a framework for environment centred analysis and design of
coordination mechanisms”, Foundations of Distributed Artificial Intelligence (eds.
O’Hare, G. and Jennings, N.), pp. 429-448, New York: Wiley Inter-Science.
DeGrace, P. and Stahl. L.H. (1990) Wicked Problems and Righteous Solutions: A Catalogue
of Modern Software Engineering Paradigms, Englewood Cliffs, New Jersey:
Yourdon Press.
DeMarco, T. (1979) Structured Analysis and System Specification, Englewood Cliffs, New
Jersey: Yourdon Press.
DUE Project Group (1979) “Project DUE: democracy, development, and EDP”, Computers
Dividing Man and Work (ed. Sandberg, A.), Swedish Centre for Working Life:
Malmö.
Ehn, P. (1988) “Language-games: a Wittgensteinian alternative”, Work-Oriented Design of
Computer Artefacts, pp. 103-122, Stockholm, Sweden: Arbetslivscentrum.
Ehn, P. and Kyng, M. (1991) “Cardboard computers: mocking-it-up or hands-on the future”,
Design at Work: Cooperative Design of Computer Systems (eds. Greenbaum, J.
and Kyng, M.), pp. 169-195, Hillsdale, New Jersey: Lawrence Erlbaum Associates.
Erickson, T. (1996) Web version of “Design as storytelling”, published in Interactions, vol.
4. www.pliant.org/personal/Tom_Erickson/index.html
Erickson, T. (2000a) “Lingua francas for design: sacred places and pattern languages,
Proceedings of the 2000 Symposium on Designing Interactive Systems, pp 357-
368, Brooklyn, New York: ACM Press.
Erickson, T. (2000b) “Supporting interdisciplinary design: towards pattern languages for
workplaces”, Workplace Studies: Recovering Work Practice and Informing System
Design (eds. Luff, P., Hindmarsh, J. and Heath, C.), pp. 252-261, Cambridge:
Cambridge University Press.
Floyd, C. (1984) “A systematic look at prototyping”, Approaches to Prototyping, pp. 1-18,
Berlin: Springer Verlag.
Floyd, C. (1987) “Outline of a paradigm change in software engineering”, Computers and
Democracy: A Scandinavian Challenge (eds. Bjerknes, G., Ehn, P., and Kyng, M.),
pp. 191-208, Aldershot: Avebury.
Fowler, M. and Scott, K. (1997) UML Distilled: Applying the Standard Object Modelling
Language, New York: Addison-Wesley.
Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995) Design Patterns: Elements of
Reusable Object-Oriented Software, New York: Addison-Wesley.
Garfinkel, H (unpub. manu. 1) About the missed orderliness of ordinary activities, UCLA:
Department of Sociology and Anthropology.
145
References
Garfinkel, H. (unpub. manu. 2) A leading policy that was used in our studies of lectures,
UCLA: Department of Sociology and Anthropology.
Garfinkel (unpub. manu. 3) Lebenswelt mathematics, its discovery, its specification, and
some consequences, UCLA: Department of Sociology and Anthropology.
Garfinkel, H. (1967) Studies in Ethnomethodology, Englewood Cliffs, New Jersey: Prentice-
Hall.
Garfinkel, H. and Sacks, H. (1970) “On formal structures of practical action”, Theoretical
Sociology: Perspectives and Developments (eds. Mc Kinney, J.C. and Tiryakian,
E.), pp. 160-193, New York: Apple-Century-Crofts.
Garfinkel, H., Lynch, M. and Livingston, E. (1981) “The work of a discovering science
construed with materials from the optically discovered pulsar”, Philosophy of the
Social Sciences, vol. 11, pp. 131-158.
Garfinkel, H. (1991) “Respecification: evidence for locally produced, naturally accountable
phenomena of order”, Ethnomethodology and the Human Sciences (ed. Button, G.),
Garfinkel, H. and Wieder, D.L. (1992) “Two incommensurable, asymmetrically alternate
technologies of social analysis”, Text in Context: Contributions to
Ethnomethodology (eds. Watson, G. and Seiler, S.M.), pp.175-206, New York:
Sage.
Garfinkel, H. (1996) “Ethnomethodology’s programme”, Social Psychology Quarterly, vol.
59 (1), pp. 5-21.
Geertz, C. (1973) “Thick description: toward an interpretive theory of culture”, The
Interpretation of Cultures, pp. 3-30, New York: Basic Books.
Gerson, E. and Star, S.L. (1986) “Analysing due process in the workplace”, ACM
Transactions on Office Information Systems, vol. 4 (3), pp. 257-270.
Giddens, A. (1978) The New Rules of Sociological Method: A Positive Critique of
Interpretive Sociologies, London: Hutchinson.
Goguen, J. (1993) “Social issues in requirements engineering”, Proceedings of 1993 IEEE
International Symposium on Requirements Engineering, pp. 194-195, San Diego:
IEEE Press.
Greif, I. (1988) Computer Supported Cooperative Work: A Book of Readings, San Mateo:
Morgan Kaufmann Publishers.
Greenbaum, J. and Kyng, M. (1991) “Design by doing”, Design at Work: Cooperative
Design of Computer Systems (eds. Greenbaum, J. and Kyng, M.), pp. 269-279,
Hillsdale, New Jersey: Lawrence Erlbaum Associates.
Grint, K. and Woolgar, S. (1997) The Machine at Work, Oxford: Polity Press.
Grønbæk, K. (1989) “Rapid prototyping with fourth generation systems”, Office: Technology
and People, vol. 5 (2), pp. 105-125.
Grønbæk, K., Kyng, M. and Mogensen, P. (1997) “Toward a cooperative experimental
system development approach”, Computers and Design in Context (eds. Kyng, M.
and Mathiassen, L.), pp. 201-238, Cambridge, Massachusetts: MIT Press.
Grudin, J. (1990a) “Interface”, Proceedings of the 1990 ACM Conference on Computer
Supported Cooperative Work, pp. 269-278, Los Angeles, California: ACM Press.
Grudin, J. (1990b) “The computer reaches out: the historical continuity of interface design”,
Proceedings of the 1990 Conference on Human Factors in Computing Systems, pp.
261-268, Seattle, Washington: ACM Press.
Heath, C. and Luff, P. (1992) “Collaboration and control”, Computer Supported Cooperative
Work: An International Journal, vol. 1 (1), pp. 69-94.
146
References
Heritage, J. (1984) Garfinkel and Ethnomethodology, Cambridge: Polity Press.
Hildreth, C.R. (1982) Online Public Access Catalogues, Dublin: OCLC.
Hirschheim, R. and Klein, H.Z. (1989) “Four paradigms of information systems
development”, Communications of the ACM, vol. 32 (10), pp. 1199-1216.
Hughes, J.A., Shapiro, D., Sharrock, W.W. and Anderson, R.J. (1988) The Automation of Air
Traffic Control, SERC/ESRC Grant No. GR/D/86157, Lancaster University:
Sociology Department.
Hughes, J.A., Randall, D. and Shapiro, D. (1992) “Faltering from ethnography to design”,
Work, pp. 115-122, Toronto: ACM Press.
Hughes, J.A. (1993) The Philosophy of Social Research, London: Longman.
Hughes, J.A., Randall, D. and Shapiro, D. (1993) “From ethnographic record to system
design: some experiences from the field”, Computer Supported Cooperative Work:
An International Journal, vol. 1 (3), pp. 123-141.
Hughes, J.A., King, V., Rodden, T. and Andersen, H. (1994) “Moving out of the control
room: ethnography in systems design”, Proceedings of the 1994 ACM Conference
on Computer Supported Cooperative Work, pp. 429-438, Chapel Hill, North
Carolina: ACM Press.
Hughes, J.A., Kristoffersen, S., O’Brien, J. and Rouncefield, M. (1996) “‘When Mavis met
IRIS’ - ending the love affair with organizational memory”, Proceedings of IRIS
19, pp. 767-787, Gothenburg Studies of Informatics, Report 8, June 1996.
Hughes, J.A., O’Brien, J., Rodden, T. and Rouncefield, M. (2000) “Ethnography,
communication and support for design”, Workplace Studies: Recovering Work
Practice and Informing System Design (eds. Luff, P., Hindmarsh, J. and Heath, C.),
Husserl, E. (1970) The Crisis of European Sciences, Evanston: Northwestern University
Press.
Hutchins, E. (1994) Cognition in the Wild, Cambridge, Massachusetts: MIT Press.
Jacobson, I., Christerson, M., Jonsson, P. and Övergaard, G. (1992) Object-Oriented
Software Engineering: A Use-Case Driven Approach, New York: Addison-
Wesley.
Jacobson, I. (1995) “The use-case construct in object-oriented software engineering”,
Scenario-Based Design: Envisioning Technology in Use (ed. Carroll, J.), pp. 309-
336, New York: John Wiley.
Jefferson, G. (1978) “Explanation of transcript notation”, Studies in the Organization of
Conversational Interaction (ed. Schenkein, J.), pp. xi-xvi, New York: Academic
Press.
Jirotka, M., Gilbert, N. and Luff, P. (1992) “On the social organization of organizations”,
Computer Supported Cooperative Work: The Journal of Collaborative Computing,
vol. 1 (1), pp. 69-94.
Jordan, B. and Henderson, A. (1995) “Interaction analysis: foundations and practice”,
Journal of the Learning Sciences, vol. 4 (1), pp. 39-102.
Kensing, F. and Simonsen, J. (1997) “Using ethnography in contextual design”,
Communications of the ACM, vol. 40 (7), pp. 82-88.
Knudsen, T., Bansler, J., Bjørn-Andersen, N., Greenbaum, J., Nurminen, M. and Thoresen,
K. (1993) “Panel remarks - The Scandinavian approaches: theories in use, of use
and organization of interdisciplinarity”, Proceedings of IRIS 16, pp. 29-38,
University of Copenhagen: Department of Computer Science.
147
References
Kontonya, G. and Sommerville, I. (1992) “Viewpoints for requirements definition”, Software
Engineering Journal, vol. 7 (6), pp. 375-387.
Kraft, P. and Bansler, J.P. (1994) “The collective resource approach: the Scandinavian
experience”, Scandinavian Journal of Information Systems, vol. 6 (1), pp. 71-84.
Kuhn, T.S. (1962) The Structure of Scientific Revolutions, Illinois: University of Chicago
Press.
Kuutti, K. (1996) “Activity theory as a potential framework for human-computer interaction
research”, Context and Consciousness: Activity Theory and Human Computer
Interaction (ed. Nardi, B.), pp. 17-44, Cambridge, Massachusetts: MIT Press.
Kyng, M. (1994) “Collective resources meets puritanism”, Scandinavian Journal of
Information Systems, vol. 6 (1), pp. 85-96.
Kyng, M. (1995) “Creating contexts for design”, Scenario-Based Design: Envisioning
Technology in Use (ed. Carroll, J.), pp. 85-107, New York: John Wiley.
Landes, D. (1972) The Unbound Prometheus, Cambridge, Cambridge University Press.
Lesser, V., Horling, B., Regis, V., Raja, A. and Zhang, S. (unpub. manu.) The TAEMS White
Paper, Multi-Agents Systems Lab. www.mas.cs.umass.edu/research/taems/
Livingston, E. (unpub. manu.) The Ordinary Society, University of New England, Armidale,
New South Wales, Australia: Sociology Department.
Livingston, E. (1987) Making Sense of Ethnomethodology, London: Routledge and Kegan
Paul.
Lynch, M. (1993) Scientific Practice and Ordinary Action: Ethnomethodological and Social
Studies of Science, Cambridge: Cambridge University Press.
Lynch, M. and Bogen, D. (1994) “Harvey Sacks’ primitive natural science”, Theory, Culture
and Society, vol. 11, pp. 65-104.
Madsen, O.L., Møller-Pedersen and Nygaard, K. (1993) Object-Oriented Programming in
the BETA Programming Language, New York: Addison-Wesley.
Malcolm, N. (1995) “Thinking”, Wittgensteinian Themes: Essays 1978-1989 (ed. Von
Wright, G.H.), pp. 1-15, Ithaca, New York: Cornell University Press.
Malinowski, B. (1922) Argonauts of the Western Pacific, London: Routledge and Kegan
Paul.
Mariani, J., Rodden, T., Colebourne, A., Palfreyman, K. and Smith, G. (1995) “Q-pit – a
populated information terrain”, IS&T/SPIE Symposium on Electronic Imaging:
Science & Technology, pp. 12-22, ISBN 0-8194-2030-1.
Martin, D., Rodden, T., Rouncefield, M., Sommerville, I. and Viller, S. (2001) “Finding
patterns in the fieldwork”, Proceedings of the Seventh European Conference on
Computer Supported Cooperative Work, pp. 39-58, Bonn, Germany: Kluwer
Academic Publishers.
Moerman, M. (1992) “Life after C.A.”, Text in Context: Contributions to Ethnomethodology
(eds. Watson, G. and Seiler, R.M.), pp. 20-34, New York: Sage.
Mogensen, P. (1992) “Towards a provotyping approach in systems development”,
Scandinavian Journal of Information Systems, vol. 3 (4), pp. 31-53.
Mogensen, P. and Trigg, R. (1992) “Artefacts as triggers for participatory design”,
Proceedings of the 1992 Participatory Design Conference, pp. 55-62, Boston:
Computer Professionals for Social Responsibility.
Mogensen, P. (1994) Challenging Practice: An Approach to Cooperative Analysis, Ph.D.
Thesis, DAIMI PB – 465, Århus University, Denmark: Department of Computer
Science.
148
References
Naumann, J.D. and Jenkins, A.M. (1982) “Prototyping: the new paradigm for systems
development”, MIS Quarterly, vol. 6, pp. 29-44.
Norman, D.A. (1986) “Cognitive engineering”, User Centred System Design (eds. Norman,
D. and Draper, S.), pp. 31-61, Hillsdale, New Jersey: Lawrence Erlbaum
Associates.
Norman, D.A. (1988) The Psychology of Everyday Things, New York: Basic Books.
Norman, D.A. (1992) Turn Signals are the Facial Expressions of Automobiles, New York:
Addison-Wesley.
Nygaard, K. (1979) “The Iron and Metal Project”, Computers Dividing Man and Work (ed.
Sandberg, A.), Swedish Centre for Working Life: Malmö.
O’Brien, J. (2000) Informing CSCW Systems Design: Theory, Practice and the Paradigm of
“The Workaday World”, Ph.D. Thesis, Lancaster University: Sociology
Department.
Orr, J. (1996) Talking About Machines: An Ethnography of a Modern Job, pp. 104-124,
Ithaca, New York: Cornell University Press.
Page, D., Williams, P. and Boyd, D. (1993), Report of the Inquiry into the London
Ambulance Service, South West Thames Regional Health Authority, London:
Communications Directorate.
Pedersen, E.R., Mc Call, K., Moran, T.P. and Hulas, F.G. (1993) “Tivoli: an electronic
whiteboard for informal workgroup meetings”, Proceedings of the 1993
INTERCHI Conference on Human Factors in Computing Systems, pp. 391-398,
Amsterdam: ACM Press.
Pettifer, S. Cook, Marsh, J. and A. West. (2000) “Deva3: architecture for a large-scale virtual
reality system”, Proceedings of ACM Symposium in Virtual Reality Software and
Technology 2000, pp. 33-39, Seoul, Korea: ACM Press.
Place, U.T. (1994) “Is consciousness a brain process?”, Mind and Cognition (ed. Lycan,
W.G.), pp. 29-36, Oxford: Blackwell Publishers.
Plowman, L., Rogers, Y. and Ramage, M. (1995) “What are workplace studies for?”,
Proceedings of the Fourth European Conference on Computer Supported
Cooperative Work, pp. 309-324, Stockholm, Sweden: Kluwer Academic
Publishers.
Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S. and Carey, T. (1999) Human-
Computer Interaction, pp. 3-27, New York: Addison-Wesley.
Prus, R. (1996) Symbolic Interaction and Ethnographic Research: Intersubjectivity and the
Study of Human Lived Experience, New York: State University of New York
Press.
Pycock, J. (1999) Designing Systems: Studies of Design Practice, Ph.D. Thesis, The
University of Manchester: Faculty of Science and Engineering.
Rogers, Y. and Belloti, V. (1997) “Grounding blue-sky research: how can ethnography
help?”, Interactions, vol. 4 (3), pp. 58-63.
Rogers, Y. (1997) An Introduction to Distributed Cognition, Discussion Paper, School of
Cognitive and Computing Sciences, University of Sussex.
www.cogs.susx.ac.uk/users/yvonner/dcog.html
Rouncefield, M., Hughes, J.A., Rodden, T. and Viller, S. (1994) “Working with ‘constant
interruption’”, Proceedings of the 1994 ACM Conference on Computer Supported
Cooperative Work, pp. 275-286, Chapel Hill, North Carolina: ACM Press.
Rouncefield, M., Hughes, J. and O’Brien, J. (1997) Ethnography: Some Practicalities of
Ethnographic Analysis, CSEG Technical Report (CSEG/27/97), Lancaster
University: Computing Department.
149
References
Ruhleder, K. and Jordan, B. (1999) “Meaning-making across remote sites: how delays in
transmission affect interaction”, Proceedings of the 6th European Conference on
Computer Supported Cooperative Work, pp. 411-430, Copenhagen: Kluwer
Rumelhart, D. and Mc Clelland, J.L. (1986) Parallel Distributed Processing: Explorations in
the Microstructure of Cognition (Volume 1. Foundations), Cambridge,
Massachusetts: MIT Press.
Ryle, G. (1971) The Thinking of Thoughts, University Lectures No. 18, Canada: University
of Saskatchewan.
Sacks, H. (1963) “Sociological description”, Berkeley Journal of Sociology, vol. 8, pp. 1-16.
Sacks, H., Schegloff, E. and Jefferson, G. (1974) “A simplest systematics for the
organization of turn-taking in conversation”, Language, vol. 50, pp. 696-735.
Sacks, H. (1984) “Notes on methodology”, Structures of Social Action: Studies in
Conversation Analysis (eds. Maxwell, J.M. and Heritage, J.), pp. 21-27,
Cambridge: Cambridge University Press.
Sacks, H. (1992a) “The baby cried. The mommy picked it up”, Lectures on Conversation
(ed. Jefferson, G.), Volume I, Part 3, Spring 1966, Lecture 1, pp. 236-242, Oxford:
Blackwell Publishers.
Sacks, H. (1992b) “Preserving and transmitting knowledge via stories”, Lectures on
Conversation (ed. Jefferson, G.), Volume 2, Part VII, Fall 1971, Lecture 8, pp.
466-469, Oxford: Blackwell Publishers.
Schön, D.A. (1988) “Designing: rules, types and worlds”, Design Studies, vol. 9 (3), pp. 181-
190.
Schmidt, K and Bannon, L. (1992) “Taking CSCW seriously: supporting articulation work”,
Computer Supported Cooperative Work: An International Journal, vol. 1 (1), pp.
7-40.
Schuler, D. and Namioka, A. (eds.) (1993) Participatory Design, Hillsdale, New Jersey:
Lawrence Erlbaum Associates.
Schutz, A. and Luckmann, T. (1974) The Structures of the Lifeworld, London: Heinemann.
Shapiro, D. (1993) “Interdisciplinary design: some future possibilities”, Proceedings of IRIS
16, pp. 15-27, University of Copenhagen: Department of Computer Science.
Shapiro, D. (1994) “The limits of ethnography: combining social sciences for CSCW”,
Work, pp. 417- 428, Chapel Hill, North Carolina: ACM Press.
Sharrock, W.W. (1980) “The possibility of social change”, The Ignorance of Social
Intervention (ed. Anderson, D.C.), pp. 117-133, London: Croom Helm.
Sharrock, W.W. and Anderson, R.J. (1994) “The user as a scenic feature of the design
space”, Design Studies, vol. 15 (1), p. 5-18.
Sharrock, W.W. (2000) Ethnography in the Workplace, paper presented at Tokyo University,
September 2000.
Shneiderman, B. (1987) Designing the User Interface: Strategies for Effective Human-
Computer Interaction, New York: Addison-Wesley.
Simon, H.A. (1969) The Sciences of the Artificial, Cambridge, Massachusetts: MIT Press.
Simon, H.A. (1984) “The structure of ill-structured problems”, Developments in Design
Methodology (ed. Cross, N.), pp. 145-164, Chichester: Wiley.
Simonsen, J. and Kensing, F. (1994) “Take users seriously but take a deeper look”,
Proceedings of the 1994 Participatory Design Conference, pp. 47-58, Chapel Hill,
North Carolina: Computer Professionals for Social Responsibility.
150
References
Sol. H.G. (1984) “Prototyping: a methodological assessment”, Approaches to Prototyping,
Berlin: Springer Verlag.
Sommerville, I. and Sawyer, P. (1997) Requirements Engineering: A Good Practice Guide,
New York: John Wiley.
Suchman, L. (1983) “Office procedures as practical action: models of work and system
design”, ACM Transactions on Office Information Systems, vol. 1 (4), pp. 320-328.
Suchman, L. (1987) Plans and Situated Actions: The Problem of Human-Machine
Communication, Cambridge: Cambridge University Press.
Suchman, L. (1989) Notes on Computer Support for Cooperative Work, Working Paper WP-
12, University of Jyväskylä, Finland: Department of Computer Science.
Suchman, L. (1995) “Making work visible”, Communications of the ACM, vol. 38 (9), pp.
56-64.
Sutcliffe, A. (1992) “HCI: where’s the practice?”, Proceedings of the Seventh Conference of
the British Computer Society - Human Computer Interaction Specialist Group, pp.
477-479, University of York: Cambridge University Press.
Taylor, R.S. (1968) “Question-negotiation and information seeking in libraries”, College and
Research Libraries, vol. 29 (3), pp. 178-94.
Thomas, J. and Kellogg, W. (1989) “Minimising ecological gaps in interface design”, IEEE
Software, pp. 78-86, Los Alimitos, California: IEEE Computer Society Press.
Twidale, M., Rodden, T. and Sommerville, I. (1993) “The designers’ notepad: supporting
and understanding cooperative design”, Proceedings of the Third European
Conference on Computer Supported Cooperative Work, pp. 93-108, Milan: Kluwer
Twidale, M., Randall, D. and Bentley, R. (1994) “Situated evaluation for cooperative
systems”, Proceedings of the 1994 ACM Conference on Computer Supported
Cooperative Work, pp. 441-452, Chapel Hill, North Carolina: ACM Press.
Twidale, M., Chaplin, D., Crabtree, A., O’Brien J., Nichols, D.M. and Rouncefield, M.
(1997) Collaboration in Physical and Digital Libraries, British Library Research
and Innovation Centre: Report No. 64.
Viller, S. and Sommerville, I. (1999) “Social analysis in the requirements engineering
process: from ethnography to method”, paper presented at the Fourth IEEE
International Symposium on Requirements Engineering, 7th-11th June, Limerick,
Ireland.
Vlissides, J. (1997) “Patterns: the top ten misconceptions”, Object Magazine, March 1997.
www.research.ibm.com/designpatterns/pubs/top10misc.html
Walsh, J.P. and Ungson, G.R. (1991) “Organizational memory”, Academy of Management
Review, vol. 16 (1), pp. 57-91.
Winch, P. (1988) The Idea of a Social Science, London: Routledge and Kegan Paul.
Wittgenstein, L. (1992) Philosophical Investigations, Oxford: Blackwell Publishers.
Wolcott, H.F. (1999) Ethnography: A Way of Seeing, London: Altamira Press.
Wynn, E. (1991) “Taking practice seriously”, Design at Work: Cooperative Design of
Computer Systems (eds. Greenbaum, J, and Kyng, M.), pp. 45-64, Hillsdale, New
Jersey: Lawrence Erlbaum Associates.
Zimmerman, D.H. (1973) “The practicalities of rule use”, Understanding Everyday Life:
Toward the Reconstruction of Sociological Knowledge (ed. Douglas, J.D.), p. 221-
238, London: Routledge and Kegan Paul.
151
References
Zimmerman, D. and Wieder, D.L. (1973) “Ethnomethodology and the problem of order”,
Understanding Everyday Life: Towards the Reconstruction of Sociological
Knowledge (ed. Douglas, J.D.), pp. 285-298, London: Routledge and Kegan Paul.
152
Subject Index
A E
Air Traffic Control, 82–86 Et cetera problem, 48
Analysing the design space, 28–36, Ethnography, 39–71
39–47, 56–71, 73–77, 86–101, ethnographic record, 47
110–18, 124–38 exploring work, 41–42
first-hand observation, 39–43
C gathering materials, 43–45
inspecting work, 42–43
Chicago School of Sociology, 39
instances, 45, 61–63, 66–67
Coherence method, 80–86 Ethnography and design
Communication and cooperative
co-construction of use scenarios,
analysis, 86
98–102
Constructive analysis, 45–51 communication of findings, 86–98
classification schemes, 46
concurrent ethnography, 75
coded results, 48–49
ethnographer as bricoleur, 79
codification, 46–47 evaluation of prototypes, 124–26
indexical relation of sign and
evaluative ethnography, 75
referent, 45–50
giving form to design, 79
problem of, 47–51 linking ethnography to design, 79–
use of analytic categories, 46–47
81
Conversation analysis
quick and dirty ethnography, 74
adjacency pairs, 53 re-examination of studies, 76
coordinating mechanism, 55
role of ethnography in design, 73–
repairs, 54
79
rule-set, 54 Ethnomethodology, 56–71
transcript format, 55
component events, 63
transcript symbols, 55–56
corrigibility of account, 66
turn-constructional components, gap in social science literature, 51
53
lebenswelt pairs, 66–67
turn-taking machinery, 52–55
member, 52
Conversational formulations, 61 missing interactional what, 51
Cooperative Design , 142
praxiological accounts, 65–67
Cooperative work, 28–36
probative description, 67
contingencies, 32–36 remedial exercise, 71
organizational procedures, 32–36
representing cooperative work,
routines, 33
65–67
working practices, 34–36 sequential orders of work, 63
studies of work, 51
unique adequacy requirement, 67–
69
validation of account, 67
152
Subject Index
vulgar competence and expertise, O

69
Organizational memory, 15–18
Evaluation of cooperative systems,
Organizational procedures, 30–36
108–26
criteria of evaluation, 117–18
evolutionary prototyping, 108 P
situated evaluation, 124–26 Paradigm change in design, 4–7
Evalution of cooperative systems process-oriented perspective, 6
participatory design, 110–21 product-oriented perspective, 5
Evolutionary prototyping, 108 ruling paradigm, 5
Participatory design, 110–21
F collective resources approach,
118–21
Formal methods, limitations of, 4–5,
cooperative analysis, 116–18
37–38, 95
cooperative design, 114–16
Formulating design solutions, 79–
design by doing, 111
102, 126–38
design language, 112–14
design of acceptable systems, 117
G
envisionments of the future, 112,
Generic analytic formats, 9–15, 45– 114
51, 71 family resemblances, 113
language games, 112–14
H mock ups, 111–14
quality of work, 114, 118–21
Human-computer interaction (HCI), Participatory Design , 142
8–18 Pattern languages, 86–94
dataflow mapping, 14 lingua franca, 86
distributed cognition, 15 patterns of technology use, 88
ecological validity, lack of, 18–20 presentation of findings, 88–94
evaluation, 121–23 typification, 22–23, 88
information processing, 9–10 Pattern languagess
mental models, 12–14 communication, 86
parallel distributed processing, 10 Perspicuous settings, 21–24, 25–28,
task analysis, 12–13 57–61, 95–98
Phenomenology, 65–66
I genetic origins of organizations,
Informal description, 37 65
Interface, in HCI, 9–11 independent Galilean objects, 65
reconceptualising the interface, lebenswelt pairs, 65–67
24–27 prescientific life-world, 65
Involving users, 24–27 Political ideology, 118–21
Prototyping methodology, 109–38
N hands on the future, 110–18
problem of tunnel vision, 116
Natural language, 52 proof by construction, 123
Naturally organized activity, 52 provotyping, 116
triggering artefacts, 117
152
Subject Index
R T
Radical studies of work, 51 TAEMS task structure, 46
Referent system, 4–7 Thick description, 61–64
Requirements problem, 1–4 Thinking, 19–20
requirements specification Typification, 22–23, 88
document, 3
waterfall model, 2–4 U
Use scenarios, 22–23
S
Use-case, 80
Scientific methods, value of, 15, 37– User in HCI, 9–11
39, 123 reconceptualising the user, 21–24
Searching in the library
categorisation work, 58–61 W
online public access catalogue
Work and organization, 28–36
(OPAC), 57–61
Self-organizing structures of work, rationalist mentality, 37–38
views of work, 79–80
33
work-in-context, 39–41
Socio-technical systems of work, 4–7
Story-telling, 95–98 Working up design solutions, 86–
107, 126–38
Supporting groups, 25
Syntactic sugar, 6
153

(Computer Supported Cooperative Work) Andy Crabtree - Designing Collaborative Systems - A Practical Guide To Ethnography (2003, Springer) PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

(Computer Supported Cooperative Work) Andy Crabtree - Designing Collaborative Systems - A Practical Guide To Ethnography (2003, Springer) PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Designing Collaborative Systems

Designing Collaborative Systems:

A Practical Guide to Ethnography

design process; 2) significant ethnographic practices for describing, analysing and

2. Making Cooperative Work Visible 37

3. Work Studies and Design 72

Subject Index 150

The Motivation for Ethnography in Design

Analysing the Design Space: The Waterfall Model

Waterfall Model provided the first overarching development structure for

A Paradigm Change in Design

and its capabilities, and practice is largely understood in a language close to

well understood, thus allowing software requirements to be determined in

Product-oriented view of the Process-oriented view of the

A Primary Analytic Point of View for Design:

The User and the Interface in HCI

Input / Encoding Com- Response Response Output /

Figure 1. Human information processing stages (Preece et al. 1999).

According to this model of the user, information constitutes an input that is

Figure 2. Parallel distributed processing: a connectionist network (Churchland & Sejnowski

Other input Keyboard, Visual Other out -

Figure 3. The Interface in HCI (Grudin 1990a).

Mapping Mental Models of the Referent System

Goal: Send message Email: Tasks

Start Open new Forward to

Select tool: letter.

Start menu Programme Email

Move cursor Move cursor Browse

Click on icon Click on Click on

Figure 4. Task Analysis (Preece et al. 1999).

Credit clearance Product unavailable

No credit clearance Product unavailable

Requirements on an order system control dialogue

Figure 5. Dataflow: Information Processing in an Order Purchase (Preece et al. 1999).

The Referent System in HCI

Some Technical Troubles with HCI

any closer to the workaday world. By way of example, and elucidation of an

A simple answer to the question is yes, of course local factors could be

From Human Factors to Human Actors: Exit HCI

Reconceptualising the User

technical specialization, with its own dialect, system of symbols, metaphors

number of roles defined by distinct occupational categories) whose actions are

Reconceptualising the Interface

systems administrators, customer support and field service representatives,

theoretical construction. Rather than propose some alternate a priori

The Turn to the Social

relationships that hold between people-working-together-in-groups. On this

rationale behind various object-oriented approaches is or have in the past been

Self-organizing Structures of Work

The local clothing industry was characterised by alternating seasons of

John Hughes et al.

Ethnography: An Informal Mode of

Investigating Cooperative Work

Assembling Data or Instances for Inspection

Analysing Cooperative Work

To anyone but the researcher, the composite fieldwork descriptions (the

The Problem of Constructive Analysis

are treated as impersonal or disinterested descriptions of witnessed events. The

Analysing Cooperative Work: Sacks and Garfinkel

turn-allocation and transition is accomplished in concert by parties to the

formulating is an account-able phenomenon. This is to say that (a) it is a

14. Lisa: It’s a journal.

of a specifically vague description is the first action in an unfolding course of