The brief I was volunteered for was to reflect on the use of ethnography in system design from the perspective of the Lancaster group of researchers, some of whom have now moved to pastures new, who can make the claim that they were among the pioneers of ethnography in system design. There is no special credit that should accompany this. Like many innovations they were simply ‘going there own way’ which happened to be at the right time. Through a quite fortuitous meeting, a group of sociologists and computer scientists got together to see how far the ethnographic study of work settings could go in the software engineering process. One might hope to say at this juncture that ‘the rest is history’ and that ethnography is the accepted method in distributed system design, is part of the training of every designer, and that henceforth all systems would be properly designed in light of the social settings in which they are to be used. This would, of course, be both wrong and dangerous to assume. While ethnography, as said earlier, has a respected place in the design process, this is mainly confined to the research environment and has yet to find an assured place in circumstances where its potential can be exploited more fully in the ‘front line’ of system design. Some years ago we set out some of the reasons for this in a paper, ‘Moving out of the control room: ethnography in CSCW’, and suggested a variety of ways in which ethnography could be used within more commercial and industrial settings. I want to revisit the issue and try to bring it more up-to-date.
Of course, gaining acceptance for a method is a long process and probably not made any easier in a field such as system design where innovation is such an imperative and a fact of life that things rarely settle down for a sufficient length of time for adequate experience to accumulate. This is compounded by the related fact that designing and building complex systems is extremely difficult and the Holy Grail of ‘getting it right’ first time and on time is as far away as it ever was.
In such an atmosphere there is a tendency to leap on any new method which offers a glimmer of hope of solving the problems of design and ethnography has not been immune to such hype. When it fails to deliver, as it must because no method can meet all the problems of design, then the reaction against it can be severe. While ethnography has, so far, escaped this fate, it is not an atmosphere which encourages a clear sighted look at what the method can, and cannot, contribute to system design. In the remainder of the paper I want to sketch out some issues involved in taking a clearer look at the method in system design. These are not intended to be exhaustive but they are some of the salient ones which, at Lancaster, we are trying to give some thought to.
Elsewhere we have described this problem as one of connecting two different ‘mentalities’. While this is a term which should be treated with some caution, it does direct attention to ways of working which are different. Engineering requires, among other things, attention to detail, the systemic working though of elements and fitting them together coherently, handling complex processes, testing proposed solutions, agreement on precisely stated objectives, and so on. All of these are supported by diagrammatic formats, systematically written documents, step-by-step procedures, and so on. Ethnography, by contrast, is much more the activity of the ‘bricoleur’ — the handyman — taking what one gets, working it up into a story, using illustration, and the discursive practices of the essay (See Comic Deliverable 2.1).
While one can perhaps make too much of these differences they have a kernel which is real enough, as we have found. Of course, in small research groups, if the will is there, much can be achieved through discussion and the ethnographer and designer just sitting down together. This is the way we have proceeded in our own research group through debriefings and the informalities of interpersonal contact.
However, though not to be neglected it is unlikely to be sufficient in an industrial context where there may be little opportunity to develop the trust and ease of working that we have been fortunate to experience — and for many reasons. In particular, the size of the typical software engineering group far exceeds that of the few who typically compose a research team. Nor is it likely that in the former case, one will always have the same personnel working on the same problem for the length of time it might take to carry the project through from beginning to end. There is, too, the perennial ‘what if the ethnographer is run over by a bus?’ problem. Despite the possibility of various recording devices, the knowledge gained from fieldwork is mostly resides in the fieldworkers’ head until brought to bear on the design process and, as part of this, recorded.
These kind of problems suggest a further research direction for ethnography if it is to progress as a method having wider acceptability, namely, bring the results of fieldwork to bear more formally and systematically to the software engineering process. I have stated this generally because it is really a host of problems all of which need to be thought about. One idea which we tried was DNP, a support tool which enabled software engineers and fieldworkers to use a format which, in effect, enabled the design process to move from the textual and illustrative mode in which fieldwork is typically presented, to the more graphical format in which designers work (See Rouncefield et al, 1997). This effort had equivocal success — largely due to lack of resources to take it very much further — but it did serve to highlight the problem.
Another tack is to try to introduce some formality into the presentation of fieldwork results. This is, in significant respects, a much more challenging idea since, on the face of it, it flies in the face of what ethnography is all about. One of the main virtues of the method was that it seemed to accommodate so well with one of the main tenets of CSCW, that is, the requirement of examining each setting in its own right rather than assuming that work processes were identical. It was just such an assumption that had been pointed at as one of the failings of cooperative system design. Ethnography’s ability to get at those essential if informal features of work activities not mentioned in more formal characterisations of work, was seen as one of its strengths (See Rouncefield et al, 1994) in that it examined the social organisation of work in its own terms rather than filtered through the lens of some formal system which owed more to the requirements of system design than it did to getting at the phenomenon.
However, over the years there has been a waning of such religious wars. If treated as a practical problem of supporting the communication between engineers and fieldworkers rather than an epistemological issue, then it becomes a problem worth having a go at. After all, one of the main presuppositions underlying much of the ethnography done in CSCW, and derived from ethnomethodology, is that the social world is massively self-organised and that this organisation is describable. In which case, it should be possible — at least an idea which is worth some research effort — to identify ‘patterns’ much in the way that has been proposed for architectural design. This is where some of our current research effort lies.
I now want to turn to one other issue of interdisciplinarity though, for emphasis, treat it as a problem in its own right: that of working within organisations.
This is not a simple problem and, in any case, has much to do with ethnography being able to deliver on its promises. Certainly, it is not something which is going to change overnight. An important part of it, too, is being modest about what it can achieve. It will also require giving some thought to the training of people with appropriate ethnographic skills — assuming that we can work out what these might be in the context of system design — and presenting this in ways which emphasise the practical rather than the epistemological role that ethnography would need to play in system design.
More than this, obviously, is required and not least getting ethnographers who, on the whole, are academically inclined, to realise that the industrial environment is a very different one. Things can change quickly, projects abandoned, firms bought and sold, things to do yesterday, getting used to never having sufficient time, and more, which are often the lot of engineers.
It has made a major contribution to sensitising the system design community to the social dimension in ways which are practical and offer considerable promise for further development. In many respects its success in this is that in the CSCW community, and beyond, the method is taken as a standard one. There is still much to do to carry the message beyond these confines, but this is no mean achievement. The danger is that the impetus to develop the method further will be lost. However, there is a slowly growing corpus of knowledge and experience which, it is hoped, will be carried forward.
A second but more contentious achievement, and related to the first, is the constant reminder the method offers of the need for designers to look at the domain first as a basic initial requirement of design. While there has for long been much talk about the need for ‘user-centred design’ realising it in ways that go beyond articles of faith and do not, importantly, simply see the user as some isolated individual but as a social being, then ethnography has much to offer. There is more to be done — there always is — and though I have focussed mainly upon ‘leading edge’ possibilities it is important not to ignore the more prosaic things that can be done, such as developing a corpus of fieldwork materials, better training, facilitating communication between engineers and fieldworkers, challenging the too easy assumptions of generalisable methods, and so on.
Hughes, J.A., King, V., Rodden, T. and Anderson, H. (1994), ‘Moving out of the control room: ethnography in CSCW’, in Proceedings of CSCW’94, Chapel Hill, ACM Press
Rouncefield, M., Hughes, J.A., O’Brien, J. and Rodden, T. (1997), ‘On becoming an DNP user’, in Proceedings of IRIS20, 1997