The Politics of Design
- Representing Work
Communications of the ACM, vol. 38, no.9 , Sept. 1995.
Liam J. Bannon
Dept. of Computer Science & Information Systems
University of Limerick, Ireland
bannonl@ul.ie
(1700 words approx.)
The three papers in this Section provide an opening into an important and increasingly contentious area in computer systems development, namely, the methods used in understanding, representing and modelling work processes and practices. Suchman describes part of the problem as the "relation between normative accounts of how work gets done and actual practice". The arguments raised are of a fundamental and radical character, as they do not involve simple debate about the adequacy of any particular representational formalism, but call into question the perspectives underlying particular methods and techniques of making work "visible", as a prelude to designing computer-based systems to "support" the work.
My own perspective on these issues has been formed over a number of years through interaction with people in the areas of software engineering, information systems development, human-computer interaction and information technology support in end-user organizations. The argument is not whether some level of abstraction and formalization of work processes is possible or desirable, but rather, whether such techniques could in principle "capture" all that is required, and how to manage what is inevitably left outside the representation. While some simply argue for more powerful representational forms, there has been a growing awareness that the problem is not simply one of richer notations or more ample resources, but more fundamentally, of an inappropriate concept of what can, in principle, be "captured" in any model of the work process. In an earlier paper entitled Questioning Representations Mike Robinson and I argued: "Rather than viewing the models embedded in designs as implementable accounts of work processes, they should be conceived as heuristic devices that provide resources on particular occasions for particular groups of people" (Robinson & Bannon, 1991).
Our goal in that paper was to develop a case against an objective reality that can be usefully "captured" in a model and subsequently used as a sufficient basis on which to develop a computerized system. Our critique relied on the centrality of interpretation in the conduct of work, and also on the fact that the development of computer-based applications requires the collaboration or involvement of a variety of distinct communities, workers with different skills using different representational frameworks - users, analysts, developers, programmers, etc. This necessary heterogeneity poses a number of problems which cannot be removed simply by ensuring good "communication" between the differing groups. The issue is more fundamental, arising out of the different practices of the groups and the essential incommensurability of their world views and language. How to construct a shared or common information space (Schmidt & Bannon, 1992) among these groups is thus seen as a central concern. Thus Suchman asks how " ..shared understandings can be constructed across multiple, often conflicting perspectives." Likewise, we pointed to the dangers of transporting representations between different semantic communities with different practices, which again strikes a chord when Suchman notes: "problems arise when normative representations are either generated at a distance from the sites in which the work they represent goes on, or are taken away from those sites and used in place of the work itself".
Our critique of modelling argues for the essential limitations of any and every form of representation. In other words, no representation, or set of representations is ever complete. Models are thus seen, in our view, as interpretations, as constructions, which for some purposes, under certain conditions, used by certain people, in certain situations may be found useful, not true or false. We thus wished to re-cast some of the discussion about the uses and limitations of models in the context of "reframing" rather than of simply "describing" or "abstracting from" some external reality. Suchman argues cogently in a similar vein, noting the explicitly political nature of this work, as any representation highlights certain features and ignores others. Thus the underlying perspective that one brings to the workplace will be reflected in the representations of that work, and she provides examples of what this can mean in real world situations. She sums up: "..once we recognize that representations are statements made within particular traditions and social locations, we can expand our concern from the adequacy of representational forms, to their positioning within ongoing dialogues and debates regarding work and system design."
While these concerns may at first glance appear somewhat esoteric in the context of everyday systems development practice, over the last few years an emerging community has collected around these and related issues and made its presence felt within the field of systems development. I refer here to the work in participatory design (see CACM June 1993, for a representative sampling of views). Incorporating the experiences of the workers themselves, or "end-users", through active participation in the design process, is an important aspect of the perspectives adopted and described in the papers by Kyng and by Sachs as an antidote to the problems of over-reliance on the normative representations of work that dominate traditional systems development practice.
Kyng’s argument for participative design is based on the belief that "many design artifacts such as requirements specifications, are more directed towards managerial needs for control than towards supporting creative design work, no matter who does the work." and that "many of the aspects of our work environment that are crucial for our effective performance are not explicit to us". He argues that we can proceed through "concretization" and simulation of future using work situation descriptions & use scenarios. He is thus proposing a method by which designers can, in conjunction with end-users, come to explore the possibilities and limitations of specific tools for specific work practices, thus avoiding the problems of developers working solely with abstract representations of the work.
While the paper describes the activities involved in cooperative design, it is important to note that Kyng is not simply providing a "method" or bag of tricks for how to do design. Rather he is highlighting how he and his colleagues have evolved a set of design practices that have helped to ensure that system designers understand the work situation and design for and with end users. It is important to note that the concept of "Cooperative Design" is just that, a concept that needs to be and is being, fleshed out. At the same time, one must raise the other side of the coin, which is, what can practising professional designers take from these studies and apply, if there is no clear "method" being defined? If such descriptions and techniques are to become effective and widely used, how can they be "packaged" in a way that makes sense, commercially, for system developers? Is it experience with the work domain that is crucial, or learning to work with workers in the domain, or specialized skills in facilitating workshops that is the crucial ingredient, or what? How long must one study the workplace before coming up with "work situations" for example? To what extent does one get involved in site visits to see exemplary systems? What amount of time and effort is required of the end user organization, and specifically those who are involved in the design team? This is not meant as a critique of the utility of the work done by Kyng and others, but an attempt to address the question of how to make aspects of this approach more relevant for professional system developers. What can they apply and use directly? While the Aarhus studies do take work seriously, the actual framework within which the design process is conducted is not usually one with the constraints - time, money, effort, contractual obligations - of commercial software development. So, what are the possibilities and dangers if we move the discussion of their work out of these environments and into the world of practical systems development? Put rather baldly, what is required to make their design practices "industrial strength"? Is this a legitimate question - and if not, why not?
In the third paper, Sachs argues for a shift to an alternative "activity"-based view of work, influenced by the cultural-historical activity concepts of Vygotsky and others, which again emphasizes work practices, and pays attention to the ways in which people in work situations are required to continually mediate with other workers, artifacts, in constructing and developing the object of work. Sachs describes a case study where a deficient system built on the traditional model of work organisation is re-designed, based on the alternative perspective noted above, which included end-users as members of the re-design team.
Sachs usefully draws into the discussion the current "hot topic" in management concerning "business process re-engineering" (BPR), and argues that this approach is seriously flawed due to its limited vision of how work is accomplished - its ignorance of actual work practices. To my mind the whole issue of how the views articulated in the three papers discussed here fits into the gamut of work in areas such as process modelling and BPR more generally is ripe for detailed and extensive debate. For the past few years, it appears that both sides have been developing their arguments and resources internally without much attempt to engage the other side in direct debate and critique. I believe that the time has now come to engage in direct confrontation and argument, as the resulting discussions should serve a useful purpose for both the organizational development and software development communities .
In sum, I do not think that anyone here is arguing against the need for representations of work per se, rather the argument is over what it is that you are doing when you build representations initially, and how they are to be used in subsequent stages of the design process. Suchman reminds us that any representation is made for a purpose, and that what this is, and what perspective it embodies, should be open to debate. Kyng argues for the development of representations of work situations as reminders of work, not as some complete description of the work, whereas Sachs critiques one (dominant) model of work, and provides a general outline of an alternative framework and its implications. Taken together these papers provide not only a powerful critique of the dominant perspective on the representation of work practices, but also provide powerful new conceptualisations, methods and techniques for changing current practice.
References