Representing Work in Design
In Lucy Suchman (Ed.) Representations of Work:A Symposium. Monograph for Proceedings of 27th HICSS Conference, January 1994, Hawaii International Conference on System Sciences (HICSS-27), Maui, Hawaii, pp. 44 - 50.
Liam J. Bannon
Dept. of Computer Science & Information Systems
University of Limerick, Ireland
bannonl@ul.ie
Introduction
In this short essay I wish to outline some of the problems of representing work that crop up in the systems development process, relate it to the views expressed in the 3 papers in this session (Karen Holtzblatt and Hugh Beyer: "Representing Work for the Purpose of Design"; Morten Kyng: "Making Representations Work"; Patricia Sachs: "Transforming Work: The Role of Learning in Organizational Change"), as well as make some specific comments on the material and arguments in these papers, with a view to stimulating further discussion. All of the papers are concerned about re-shaping the systems development process so that it better reflects the centrality of the work domain for which the computer system is supposed to be designed. The authors wish to support work practices through the (re-) design of work artifacts, and often procedures, processes and settings as well. While "work re-design" is one of the buzz-words of management schools at present, the work reported here differs from much of the literature in business process re-engineering and process modelling in important ways. Specifically, the authors argue that such approaches tend to leave out far too much of what is involved in the nature of work, specifically the inherent capabilities of the human actors and more particularly the communities of practice around such work.
In the application systems development process workers are asked to evaluate the descriptions made of their work processes by analysts and designers, yet this is often unproductive, as the representational formalisms adopted are often obscure to the workers. We can question many aspects of this process of representing work. Who makes the representation, who has access to it, what purpose does it have? In many cases rather than clarifying things, the representations used simply obscure actual work processes in a cloud of abstractions that make little sense to the people whose work is supposedly being modeled. Worse, these abstractions are then utilized as the basis for building the information system, with the result that the inadequacy of these descriptions becomes clear to all in the failure of the resulting system. Experiences in the office information systems area bear this out. All too often, as one researcher/developer noted, we end up "automating a fiction" (Sheil, 1983).
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. I found it difficult to discover the exact role of end-users in the development of the representations described in Holtzblatt & Beyer, as the makeup of the design team is not detailed sufficiently in this text. Grounding design in a deep understanding of the practical contingencies of work practice is, however, the key insight shared by all the authors. So, while there are some strong threads of similarity running through these papers, at the same time, the particular way in which work and its support with computer-based systems is approached in each of the papers differ.
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. For a number of years, problems have been surfacing in a variety of areas connected to information technology, including requirements "capture" and the usability of the resultant systems. There was much discussion over the validity and utility of developing formalizations of work processes. The argument is not whether some level of abstraction and formalization is possible or desirable, but rather, whether such techniques could in principle "capture" all that is required, and how to manage what is left outside the representation. While some simply argue for more powerful representational forms, and more resources to be provided to the systems analysts and designers, 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 be "captured" in any model of the work process. In an earlier paper discussing such issues, 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 - 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. Our critique of modeling was arguing for the essential limitations of any conceivable form of representation. In other words, no representation, or set of representations is ever complete.
We listed a variety of problems encountered by people who take too literal a view of the modeling process: "There is a constant temptation for designers to confuse the models with an underlying reality; the models impose an ordering on people and or events, often unilaterally; the models are difficult for "users" to understand and thus preclude people from appropriating and re-working the model in situations of use; the models do not define their basic concepts adequately; emphasis appears to be on model form and elegance over actual coverage and practicality or usefulness; emphasis is on "determinism" at the expense of "interpretation" in work processes; the models embody an inappropriate correspondence theory of truth, and thus make the untenable assumption of a specifiable, one-to-one, decontextualized relationship between an instruction and the action that satisfies it" (Robinson & Bannon, 1991).
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. Given this particular perspective, it is probably not surprising that many of the formulations in the current papers seem familiar to me, and express concepts and opinions with which I feel comfortable. Let us briefly run through each of the papers and highlight some points of interest, and some concerns.
Understanding Contextual Design
The paper by Holtzblatt and Beyer is detailed and explicit. It lays out an approach to design that depends heavily on the use of a variety of perspectives on understanding work that they argue are crucial to the design process. Their approach is, to use their term, "customer-centered", although the exact meaning of that term in the context of their work is something to which I will return later. They claim that "typical design teams are not used to conversations about the nature of people’s work, how to redesign that work, and the role of a system in supporting the redesigned work". Their approach is to develop a language for work: an explicit representation of work practice, allowing them (the design team) to record their understanding and communicate it to others (in the design team) unambiguously by means of their graphical representation of different aspects of work. They propose a set of interlocking models of work - that can be represented graphically - concerning the work context, the physical setting of work, work flow and the sequence of actions and operations required to accomplish work. As they note, "each work model focuses designers on a different set of issues".
While sympathetic to the overall goal of the work, their approach does raise a number of issues at a variety of levels. Under the context model, a large set of important concepts including power, organizational standards, values, the group’s sense of identity, emotions, and personal style are identified. While admittedly all of these issues are important to address, little clue is given to the designer as to how to examine these aspects, and certainly the graphical depiction of such an array of abstract yet powerful concepts in any model seems problematic. I believe that most design teams would discuss many of these issues informally, so my question concerns what does this approach give to designers, practically speaking, to help them in developing their "context work model"? At the next level, I fully support the authors in their attention to the physical work space and how it can affect the nature of the work. They recognize the (potential) need for a number of levels of such models - for a work group, an individual’s workspace etc. - but once again, based on the sample figure in their paper, I am not convinced about the adequacy of the specific graphical depiction of this model. Be that as it may, I fully support their emphasis on understanding the details of space, physical structures, work objects, tools etc. This interest can also be found in other approaches, such as object-oriented design, activity theory-based models of work (Kuutti, 1991), and also in ethnomethodological studies of work (Anderson, Hughes, & Sharrock, 1989).
The authors’ flow model of work recognizes interdependency in work, and thus implicitly establishes a link to a large body of field studies of work, many of them appearing in the area of Computer Supported Cooperative Work (CSCW). However, I am a bit concerned about the centrality of the concept of "role" in this account, and become uneasy when I see sentences of the form "roles interact to get work done", as in my view, it is people and not roles that interact, and this fact is important to bear in mind. Some further discussion of this issue can be found in another paper, so I will not elaborate here (Robinson & Bannon, 1991). Once again I find the graphical notation that is suggested to represent the flow model is underspecified and I am dubious of its ability to capture the nature of this flow. Finally the sequence model is suggested as an improvement over traditional flow or task analysis models, as it includes information as to the trigger for the sequence, and the intent of the sequence.
In sum, the paper is an ambitious attempt to provide a rich conceptual framework for analyzing work that might be useful to system designers, and embodies a claim that the different work models can be depicted graphically in a relatively intuitive yet useful way by designers . The approach obviously is based on a rich corpus of material from the authors’ own work, and they provide an initial outline semantics for many of their conceptual distinctions. Nevertheless, I do have some concerns and misgivings about the approach as presented in this paper - many of which may simply be due to my unfamiliarity with the background to this work.
While the authors note that the models of work they are proposing are not simply imposed from the outside, but must be based on observation and representation of particular instances of work, before building abstractions of particular types, I at least am left with a feeling that these work models carry a lot of conceptual baggage even before any local or specific information is gathered. Whether or not this is a big problem is hard to know without actual practice in using the particular approach advocated here. This brings me to a more general query concerning this approach, which is, how it is to be applied, and by whom? When I read that "most people are not trained and do not naturally see the structure, strategies, concepts and relevant dimensions of work in the context of customers and systems" I am left asking, rather bluntly, who are the people who "naturally" see the relevant dimensions of work - is it only the outside consultants? A second major question that I have concerning this approach is that, despite the rhetoric of "customer-driven" in the approach, I am left wondering where is the customer, client, user, person-in-the-setting, in all of this? How is this person, or persons, involved in the whole process, or are they simply subjected to this process by outside consultants who "naturally see" the underlying structure of the work? Whilst I realize that the authors were already ambitious in the scope of their paper, I would very much like to have seen some material on, and discussion about, their actual practice with this approach, of how such models are constructed, with whom, over how long a period etc. I have no idea of what it is like to work with this approach in practice. For example, who is in the design team? How do users react to the graphical models ? Perhaps I must await another paper, but after reading this one, which offers some useful insights into studying the complexities of work, I am left with a feeling of both enthusiasm and frustration; enthusiasm for the richness and detail of their conceptualizations, yet some frustration at the lack of information on how such models are used in practice, by whom, and with what results.
Making Representations Work
The paper by Morten Kyng presents a rationale for the work of the systems development group at Aarhus University in Denmark. The perspective is one shared by several groups in Scandinavia that is based on the belief that the design of computer systems should be based on concepts and objects from the application domain & intimately linked to the actual work of end-users. Thus it shares with the other papers a concern with changing the system design process in order to make it more responsive to the nature of work. Kyng argues for the need to understand present use as the key to future developments as there is a co-evolution of work and artifacts. He is, in my view, rightly, circumspect about the idea of radical change: "innovation is difficult and tied to whatever already is - for better or worse". At the same time, he is aware of the need for us to build flexible, adaptable systems: "our artifacts should be modifiable, or even replaceable". His argument in 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". The problem of how then to design appropriate systems is handled by the notion of "concretization" and simulation of future work through the development of 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.
I like the rich picture painted of the variety of activities involved in cooperative design, the brief account of how object-oriented design may help, while not being a panacea, and the rationale for the need to understand the nature of work and to work with users through prototypes in order to develop useful systems. While the paper may not present as well-rounded or interlocking a framework as depicted in Holtzblatt & Beyer, it does provide a useful overview of what cooperative design is about, and some examples of its practice, something which I was missing in the earlier paper. At the same time, other questions emerge, such as what happens in cooperative prototyping experiments when users experience breakdowns caused by aspects of the prototype that are irrelevant to the actual work situation, but crucial to the experience of the users. How can one ensure that users do not get hung up on surface or irrelevant features of a prototype?
The realization that any descriptions that are made by designers will be (irremediably) incomplete is an important one, as too often, one finds the wish or hope on the part of some extreme formalists in systems development that, with a little extra effort or resources, complete descriptions will be possible. It is important to nail this misconception to the wall!!
While the paper does describe in some length 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 fleshed out. I don’t think anybody who uses the term thinks of it as a Method or Methodology as such, indeed that is the last thing that should happen to the term. Rather it suggests an ideal towards which people are striving. Based on experiences, we are learning about some techniques that seem to assist in this process, but it is very important to realize that you can’t simply coerce users into "cooperating", nor can you be assured that you are doing "cooperative design" simply because you use certain techniques such as prototyping, or Future Workshops, or whatever techniques seem to be used by people discussing this concept. This is not to say that certain techniques may not assist in the process, the point is that it would be wrong to consider that the essence of the concept resides in the techniques or tools that are used. That kind of operationalization of the term vitiates the values underlying the approach, which respects users skills and recognizes the need for a period of mutual learning between designers and users, as well as seeking to promote more democratization in all phases of design and work practice.
At the same time, one must raise the other side of the coin, which is, what can practicing 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?
Transforming Work
The third paper by Sachs shares with the other papers the view that we need to focus on the nature of work in great detail during the development of computer-based systems. Sachs argues passionately and cogently for the need to re-conceptualize the nature of work, away from what she terms an "organizational" view, to one she labels "activity - oriented". A synopsis of this perspective is given by Sachs in the first few pages of her article, and some key distinctions between the ‘old’ and ‘new’ perspectives are summarized in the initial Figure in her article. Her critique of the former view is built on an impressive amount of work by a variety of figures, including Wynn, Suchman, Blomberg, Orr, Scribner, Hutchins, and herself and others on the nature and organization of everyday work practices. This body of work, through critical argumentation and extensive field work, has begun to have an impact on a number of fields - including management studies, business administration, information systems development, organizational behavior, job design, human resource management, training, etc. This increasingly prominent view re-conceptualizes the nature of work and organizational life, and the role of information technology support. It emphasizes work practices, and the way learning is accomplished within communities of practice. It argues that learning and action are ‘situated’ (Suchman, 1987), and that work is accomplished via artifacts, in conjunction with others. Much of this work has helped to contribute to the interdisciplinary field of CSCW mentioned earlier (Schmidt & Bannon, 1993). This perspective is distinct from earlier critiques of neo-Taylorist management approaches, such as that of Braverman and the labour process school, in its emphasis on the detailed observation and understanding of the mundane practicalities of ‘getting the work done’. Much, though not all, of this work is inspired by Garfinkel’s ethnomethodological studies. Another source for some is the work of people utilizing aspects of the Russian school of activity theory, - Vygotsky, Leontiev and others - and represented by the work of Cole, Scribner and colleagues in the United States. Their emphasis is on activity systems, and on understanding the context in which activities are carried out. As such, the approach provides an alternative framework for conceptualizing human work activity, mediated by artifacts, and by other people, to the prevalent information processing paradigm (Bannon, 1990). My personal perspective on the nature of work and learning is almost entirely in line with what Sachs presents, and I agree with virtuallly all the key assumptions and concepts employed by the author. This is perhaps, not too surprising, when I confess that I was exposed to much of the work cited by Sachs during my studies in California in the early 80’s.
Sachs usefully draws into the discussion the current "hot topic" in management concerning "business process re-engineering", 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 I am discussing fits into the gamut of work in areas such as process modelling 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, and Sachs is to be thanked for at least bringing the topic into the limelight, even if there is not room in this short paper for extensive and detailed critique. However I look forward to this debate, and to being a part of it, in different fora over the next few years embracing the areas of management, software design, and CSCW.
Sachs provides an instance of the problems that she is railing against in the case of the new Trouble Ticketing System (TTS) that was installed in an organization that she studied. She shows how the system, while deemed "organizationally" more effective on certain criteria, was systematically making the work of the people on the ground more difficult, as well as totally ignoring the need for learning that used to be a part and parcel of the everyday work practices of the people. Sachs shows several instances of how the new system systematically reduced the competencies of the people using the system, and thus effectively reduced the competence of the overall system. Some of the measures of effectiveness used to evaluate the system totally ignored aspects such as training on the job, an important part of the work. Recent studies by Lave, Hutchins and others give excellent examples of how certain established ways of working effortlessly accomplish the overall group work, at the same time as encouraging the development of the competence of the individuals making up the group (Hutchins, 1990). What I miss in this particular paper is a more developed account of the alternative system to the TTS that was put into place as a result of the intervention of Sachs and her colleagues, as well as more detail on the nature of the "team" assembled to do the re-structuring, and especially the role of ‘end-users’ in the whole process. While the author does say end-users were involved, there is no detail of how, when, in what way, etc. they were involved. Likewise, I would be interested to know the details of any methods or techniques that were developed by the design team to encourage mutual learning and development, akin to the techniques mentioned by Kyng. However, I do find the work very interesting and look forward to a fuller recounting of the details of how change was accomplished in the organization studied.
Conclusion
Finally, I would like to make a few general remarks in the context of some of the questions raised by the organizer, Lucy Suchman, in the preamble to the session. I do not think that anyone here is arguing against 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. Holtzblatt and Beyer provide a detailed set of models of aspects of work, shown in graphical form, that they claim help designers to keep their attention on the specifics of the work. Kyng argues for the development of representations of work situations as reminders of work, not as some complete form of abstraction of work, whereas Sachs critiques one model of work, and provides a general outline of an alternative route.
In terms of whose knowledge of the work is relevant, Holtzblatt & Beyer argue that the design team’s informed view is the crucial one, yet it is not clear to what extent this view is co-extensive with end-users. Kyng argues for a process of mutual learning , with end-users clearly seen as integral members of the design team, and Sachs, while clearly listening to end-users, does not give sufficient detail in this text for me to be able to clearly state her view on this issue. In terms of the forms of representation, Holtzblatt & Beyer plump for simple graphical notations, Kyng uses a variety of forms and media, and Sachs does not give details of the forms used.
The papers in this session have presented us with different, though at times overlapping, views on the nature of work, and how it might be represented more adequately in the systems development process. There remains the question of how we can take their experiences and utilize them in our own contexts. Do any of the accounts in the papers present any methods or techniques that design teams could use directly to help them focus on the work process that they should be designing for. If I may be a little loose in my interpretation of the papers, I would say that Holtzblatt & Beyer seem to argue that they do have a detailed and worked-out method, but that you may need them as consultants to use it properly! Kyng describes a number of techniques that his group have found useful, but how much of their ‘method’ is tied in with their own understanding and empathy with the workers and the specific workplace, and how much is based on techniques that can be "exported", is not always clear. Certainly others could try to develop the work situations and use scenarios described by Kyng and see what they learn. The level of detail in the Sachs paper does not allow us to say much on this issue other than arguing for some form of worker involvement, which is a pity, as the author intriguingly notes that she has been involved in "teaching workers alternative models for analyzing work environments". It would be interesting to know how this was accomplished, and what problems were encountered. Perhaps we need to look at other papers by this author for details.
In sum, all three papers have presented us with a critique of existing (re-)presentations of work that often have little to do with the actual work, and an account of how it might be done more adequately. They travel different, though at times overlapping, paths in their efforts to re-focus design teams on the nature of work and how to support it, and provide us with new concepts and understandings. They also provide us with accounts of their own experiences of trying to do things differently. The above commentary is intended to highlight some of the insights that I got out of the papers, as well as some of the questions that I wish to ask the authors, and which hopefully we can discuss during the session.
Acknowledgements
Thanks to Lucy Suchman for the invitation to contribute to this discussion. Support for this work was provided by the EU Esprit Basic Research Action 6225 (COMIC).
References
Sheil, B. (1983) Coping with Complexity. Office: Technology & People, vol 1.
Suchman, L. (1987), Plans and Situated Actions, Cambridge, Cambridge University Press.