Designing Collaborative Systems

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 A Paradigm Change in Design 4

2

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 Reconceptualising the User 21 Reconceptualising the Interface 24 The Turn to the Social 28 Cooperative Work? 28 Self-organizing Practices of Work 2. Making Cooperative Work Visible

18

33 37

Ethnography: An Informal Mode of Description and Analysis 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 Conversation Analysis 52 Ethnomethodological Analysis 56 General Methodology: Thick Description 61

39

51

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 The HCI Tradition Alternates to HCI

121 121 124

Cooperative Design in Action 126 Situated Evaluation (Formulating Design Solutions 3) Summary References Subject Index

3

139 142 150

126

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

The Requirements Problem

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

The Requirements Problem

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 preunderstanding leads largely to a view of practice as seen from the computer 4

The Requirements Problem

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

The Requirements Problem

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

The Requirements Problem

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 userfriendly, 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 referent system 1. The referent system is chosen with a view towards developing the software system.

Process-oriented view of the referent system 1. The referent system is chosen with a view towards designing the work processes to be supported by the software system.

2. The referent system is described in terms of information processing.

2. The referent system is described in terms of work and its processes. 3. The referent system is considered to be dynamic and evolving throughout development.

3. The referent system is considered to be essentially static, having two states (before and after the software system is introduced). 4. The software developer is outside the referent system; development and use are considered separately.

4. The software developer becomes a part of the referent system in the process of coming to understand the use context (the work environment).

5. The software system is productionally closed; it is viewed as coherent set of programs based on a complete understanding of the referent system.

5. The software system is productionally open; the software system is a version subject to revision in coming to understand the use context.

6. The interaction between software and its environment is predefined as part of the development.

6. The interaction between software and its environment is tailored by users to the actual needs arising from their work.

7

The Requirements Problem

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 humancomputer 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

The Requirements Problem

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 / stimuli

Encoding

Comparison

Response selection

Response execution

Output / 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 informationprocessing, 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

The Requirements Problem

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

The Requirements Problem

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

The Requirements Problem

A Computer

Other input devices

Keyboard, mouse

Visual display

Other out 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 sub12

The Requirements Problem

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 email

Open new message

Forward recipient

Start menu

Programme menu

Email shortcut

Move cursor on to icon

Move cursor up menu

Browse programme list

Click on icon

Click on Programme icon

Click on email shortcut

to

Select tool: letter. typewriter, email

Figure 4. Task Analysis (Preece et al. 1999). © 1994 The Open University, reprinted by permission of Pearson Education Limited. ___________ 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

The Requirements Problem

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 Check order

Product unavailable Check product

No credit clearance

Supervisor

Stock Dept.

Product unavailable

Issue delivery note

Deliveries

Requirements on an order system control dialogue

Figure 5. Dataflow: Information Processing in an Order Purchase (Preece et al. 1999). © 1994 The Open University, reprinted by permission of Pearson Education Limited.

14

The Requirements Problem

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

The Requirements Problem

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

The Requirements Problem

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

The Requirements Problem

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

The Requirements Problem

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

The Requirements Problem

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

The Requirements Problem

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

The Requirements Problem

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 Requirements Problem

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

The Requirements Problem

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

Documentation

System 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

The Requirements Problem

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). © 1990 ACM, Inc. Reprinted by permission.

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

The Requirements Problem

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

The Requirements Problem

Rodden reported that users identified three significant interfaces: the personalpublic 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 Requirements Problem

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 crossfertilization of new ideas. 28

The Requirements Problem

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

The Requirements Problem

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

The Requirements Problem

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 whatto-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 whatto-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

The Requirements Problem

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, selforganizing 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 wellestablished 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

The Requirements Problem

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

The Requirements Problem

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 Requirements Problem

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 Requirements Problem

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, understanding 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, technologydriven 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

Making Cooperative Work Visible

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 wideranging 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; firsthand 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

Making Cooperative Work Visible

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 fundgranting 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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

52

For a thorough review of Conversation Analysis see Lynch (1993).

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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 turnconstructional 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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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. 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. 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

Making Cooperative Work Visible

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). 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) 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 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. 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). 60

Making Cooperative Work Visible

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. 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. 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. 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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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-apair, 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

Making Cooperative Work Visible

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 ethnomethodologicallyinformed 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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Making Cooperative Work Visible

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

Work Studies and Design

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 reexamination 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 studies studies studies studies

DEBRIEFING MEETINGS

Scoping document Figure 7. Quick and Dirty Ethnography (Hughes et al. 1994). © 1994 ACM, Inc. Reprinted by permission.

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

Work Studies and Design

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 study

DEBRIEFING MEETINGS

Systems development

System prototype Figure 8. Concurrent Ethnography (Hughes et al. 1994). © 1994 ACM, Inc. Reprinted by permission.

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 ‘workability’ 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

Work Studies and Design

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). © 1994 ACM, Inc. Reprinted by permission.

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

Work Studies and Design

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-today 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

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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 sidestep 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

Work Studies and Design

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: 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

Pilot

Flight strip

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

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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 nonverbal practical actions of the parties to the interaction (see Figure 14).

90

Work Studies and Design

??? 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: 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. (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. 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 14. Lisa: It’s a journal. 15. Sarah: It’s not so much a journal but it does come out every few months. 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 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 20. Sarah: Been there. Figure 14. The ‘Body of the Problem’. 91

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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 Qpits. 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

Work Studies and Design

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

Work Studies and Design

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 storytelling, 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

Work Studies and Design

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, endusers, 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

Work Studies and Design

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

Work Studies and Design

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 andor 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

Work Studies and Design

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 coconstruction 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

Work Studies and Design

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-to103

Work Studies and Design

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

Work Studies and Design

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

Work Studies and Design

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, sessionoriented, 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

Work Studies and Design

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 requirements 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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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 (endusers) 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, mockups 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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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 endusers 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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

[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

Evaluating Systems Support for Cooperative Work

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 coconstruction 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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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 ‘nonScandinavians’. 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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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 sociotechnical 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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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 CDROM 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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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

Evaluating Systems Support for Cooperative Work

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 workability 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

Evaluating Systems Support for Cooperative Work

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 investigator 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: SpringerVerlag. 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 357368, 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: PrenticeHall. 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.), pp. 10-19, Cambridge: Cambridge University Press. 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”, Proceedings of the 1992 ACM Conference on Computer Supported Cooperative 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.), pp. 187-214, Cambridge: Cambridge University Press. 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: AddisonWesley. Jacobson, I. (1995) “The use-case construct in object-oriented software engineering”, Scenario-Based Design: Envisioning Technology in Use (ed. Carroll, J.), pp. 309336, 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) HumanComputer 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 Academic Publishers. 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. 181190. 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”, Proceedings of the 1994 ACM Conference on Computer Supported Cooperative 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 HumanComputer 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 WP12, 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 Academic Publishers. 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. 221238, 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 Air Traffic Control, 82–86 Analysing the design space, 28–36, 39–47, 56–71, 73–77, 86–101, 110–18, 124–38 C Chicago School of Sociology, 39 Coherence method, 80–86 Communication and cooperative analysis, 86 Constructive analysis, 45–51 classification schemes, 46 coded results, 48–49 codification, 46–47 indexical relation of sign and referent, 45–50 problem of, 47–51 use of analytic categories, 46–47 Conversation analysis adjacency pairs, 53 coordinating mechanism, 55 repairs, 54 rule-set, 54 transcript format, 55 transcript symbols, 55–56 turn-constructional components, 53 turn-taking machinery, 52–55 Conversational formulations, 61 Cooperative Design , 142 Cooperative work, 28–36 contingencies, 32–36 organizational procedures, 32–36 routines, 33 working practices, 34–36

E Et cetera problem, 48 Ethnography, 39–71 ethnographic record, 47 exploring work, 41–42 first-hand observation, 39–43 gathering materials, 43–45 inspecting work, 42–43 instances, 45, 61–63, 66–67 Ethnography and design co-construction of use scenarios, 98–102 communication of findings, 86–98 concurrent ethnography, 75 ethnographer as bricoleur, 79 evaluation of prototypes, 124–26 evaluative ethnography, 75 giving form to design, 79 linking ethnography to design, 79– 81 quick and dirty ethnography, 74 re-examination of studies, 76 role of ethnography in design, 73– 79 Ethnomethodology, 56–71 component events, 63 corrigibility of account, 66 gap in social science literature, 51 lebenswelt pairs, 66–67 member, 52 missing interactional what, 51 praxiological accounts, 65–67 probative description, 67 remedial exercise, 71 representing cooperative work, 65–67 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, 69 Evaluation of cooperative systems, 108–26 criteria of evaluation, 117–18 evolutionary prototyping, 108 situated evaluation, 124–26 Evalution of cooperative systems participatory design, 110–21 Evolutionary prototyping, 108 F Formal methods, limitations of, 4–5, 37–38, 95 Formulating design solutions, 79– 102, 126–38 G Generic analytic formats, 9–15, 45– 51, 71 H Human-computer interaction (HCI), 8–18 dataflow mapping, 14 distributed cognition, 15 ecological validity, lack of, 18–20 evaluation, 121–23 information processing, 9–10 mental models, 12–14 parallel distributed processing, 10 task analysis, 12–13 I Informal description, 37 Interface, in HCI, 9–11 reconceptualising the interface, 24–27 Involving users, 24–27 N Natural language, 52 Naturally organized activity, 52

152

O Organizational memory, 15–18 Organizational procedures, 30–36 P Paradigm change in design, 4–7 process-oriented perspective, 6 product-oriented perspective, 5 ruling paradigm, 5 Participatory design, 110–21 collective resources approach, 118–21 cooperative analysis, 116–18 cooperative design, 114–16 design by doing, 111 design language, 112–14 design of acceptable systems, 117 envisionments of the future, 112, 114 family resemblances, 113 language games, 112–14 mock ups, 111–14 quality of work, 114, 118–21 Participatory Design , 142 Pattern languages, 86–94 lingua franca, 86 patterns of technology use, 88 presentation of findings, 88–94 typification, 22–23, 88 Pattern languagess communication, 86 Perspicuous settings, 21–24, 25–28, 57–61, 95–98 Phenomenology, 65–66 genetic origins of organizations, 65 independent Galilean objects, 65 lebenswelt pairs, 65–67 prescientific life-world, 65 Political ideology, 118–21 Prototyping methodology, 109–38 hands on the future, 110–18 problem of tunnel vision, 116 proof by construction, 123 provotyping, 116 triggering artefacts, 117

Subject Index

R Radical studies of work, 51 Referent system, 4–7 Requirements problem, 1–4 requirements specification document, 3 waterfall model, 2–4 S Scientific methods, value of, 15, 37– 39, 123 Searching in the library categorisation work, 58–61 online public access catalogue (OPAC), 57–61 Self-organizing structures of work, 33 Socio-technical systems of work, 4–7 Story-telling, 95–98 Supporting groups, 25 Syntactic sugar, 6

T TAEMS task structure, 46 Thick description, 61–64 Thinking, 19–20 Typification, 22–23, 88 U Use scenarios, 22–23 Use-case, 80 User in HCI, 9–11 reconceptualising the user, 21–24 W Work and organization, 28–36 rationalist mentality, 37–38 views of work, 79–80 work-in-context, 39–41 Working up design solutions, 86– 107, 126–38

153