ABSTRACT
We are working on an approach for designing CSCW systems since
we advocate the importance of generalizing from own work practice
as designers and from studies of designers working under industrial
conditions. We use the term approach as something in between commodified
methods and isolated techniques supporting one or a few activities.
Our background is computer science. In our design approach we
use a combination of intervention and ethnographic techniques. The question for us is how to present our approach:
what kind of guidelines and at what level of detail might designers
from industry find useful. These are the question we would like
to discuss at the workshop.
KEYWORDS: design approach, participation, contextual design, intervention, ethnografic techniques, methodologies and tools
INTRODUCTION
Our ambition is to develop a coherent approach, for design in
an organizational contexts under industrial conditions. Our main
interest lies in designing for a specific organization's needs
rather than generic products for a larger market. We use the term
design in the same way as architects do - focusing on the analysis
of needs and opportunities, and the preliminary design of functionality
and form, ending up with representations for (others') construction
and implementation. Therefor we see results of a design project
to include a conceptual design in terms of a written document,
sketches, mock ups and/or prototypes. We consider an evaluation
of individual and organizational consequences of implementing
the design as well as a plan for the implementation to be part
of the result too. Based upon a design proposal it should be possible
for the organization to say "go", "no go", or "more design is
needed". Eventually the project may proceed to construction and
implementation, but we consider this latter part of systems development
to be outside the scope of our emerging approach which focus on
the initial part of systems development.
What is reported on here is part of a research program, the purpose of which is to develop theories of and approaches to systems design. The research program comprises design projects carried out by us, as well as by others using our approach, and studies of designers working under industrial conditions. This paper is a first reflection upon nine of our own design projects.
A DESIGN APPROACH
In order to make our own design approach explicit we have reflected
upon nine projects we have been engaged in during the last six
years [10, 11, 27, 41]. Starting from our own experience as designers,
we present a first attempt to generalize in terms of an approach,
specifying the what, the how and the why, as well as the who and the where when in projects we strive to get from an understanding of cooperative
work to designing computer support. The point is not to promote
what we have done as the CSCW approach, nor to start an inquiry to find such an approach.
Rather the point is to facilitate one type of learning among practitioners,
researchers, and students: learning from guidelines.
We will describe our emerging design approach by the following
headings[1]:
Application Area:
We developed our approach, and hence our experience in projects,
the aim of which has been to investigate opportunities for computer
support for a specific organization. In all but one of our nine
projects we were brought in because somebody, employees or managers,
thought that computers might be part of solutions to problems
they had encountered. The initial problem definitions have been
quite open. We have carried out detailed studies of the organization's
needs and opportunities and designed tailored applications in
combination with (modified) standard products found feasible.
Most of the people we have worked with saw the main part of their jobs as problem solving and problem definition rather than routine work, and cooperation was considered a substantial part of the jobs. The list of jobs comprises: radio journalists; university secretaries; operations people in an airport; managers, consultants, and secretaries in a multinational medical company; managers, editors, secretaries, and store-clerks in a film board; scientists in a R/D lab; and senior managers within the administration at a university.
A common objective of the projects has been to support the existing work force, which was considered overworked. Another has been that the existing work force or management wanted to automate some of the routine tasks. In some projects there was a request for computer support of activities which had really never been done before in the organization. Sometimes the purpose was stated explicitly to improve quality of working life and the product and service delivered by the organization. None had the (explicitly stated) purpose of head count reduction, down-sizing or "right-sizing" (sic!).
Seven projects were action-research, one was a case study and one was a pilot study. Our experience relates to more "office-like" settings compared to the many detailed "control room studies" within the CSCW community [3, 19, 20]. We find that the same level of attention is critical for design in these settings, and so do others [4, 35].
In the action-research projects we worked closely with those to be affected by the design. The aim of two of these projects [8, 10] was to clarify the employees own needs in terms of computer support in order to prepare for management plans for implementing standard systems. In the other five [41, 42] management and employees had agreed upon the need for a design project. In the pilot study [27] the aim was to develop and test forms of representataion for design. In the case study the aim was to study designers in action. The projects lasted from 3 to 12 calender months and comprised from 2 to 6 person months
Perspective
We agree with Suchman [44] that categories do have politics. Guidelines
may be used in rather different ways according to how you perceive
what you are doing, and who is doing it to/for whom. Therefor
we need to specify explicitly our basic assumptions and principles
and how we as designers, working in participatory projects, perceive
organizations; their members and their role in design, as well
as our own role; and how we perceive design processes and their
products.
Organizations do of course have structural properties, however organizations are not there to be studied, rather we perceive them as constantly being enacted through members' interaction and activities. Stable structures - understood as enacted social order - as well as procedural aspects, need to be understood as part of a design project. Since organizations are constantly changing, a design might need a review if say it has "simmered" for eighteen months, as one of our designs did in the Film Board.
We see organizations as frameworks for cooperation as well as for conflicts. Therefore groups and individuals participating in design should be expected to have common, as well as conflicting goals. The role of designers is neither to cover up nor to solve political conflicts in design. Rather they should help the parties to formulate their visions, and leave it to them to solve conflicts in relevant fora.
We expect users, given the right opportunities, to be able to make their own decisions concerning what kind of computer support and work re-organization they might need and what kind they might want to get rid of, cf. [27]. As addressed above "they" however, is seldom experienced to be a homogenous entity. In the Film Board we ran into a conflict between the production manager and the editors [41]. When we realized the conflict we arranged a meeting and explained the consequences as to each of the parties of various design decisions. The production manager then gave in, but subsequently tried - unsuccessfully - to persuade the president to make an end to the project in the department.
Direct confrontation might not work in all situations. Blomberg, Suchman and Trigg [4] report on a project where they came to know of management's confidential plan of closing down a department in which they were doing their design project. At a meeting with management they chose to mediate between management and employees by speaking at least partly on behalf of the supervisor of the department they had studied. Whether and how designers might approach conflicts that evolve in a project depends on how the conflict is related to the design project [41].
Working with users and from ethnographic studies of organizational life we have learned that often there is quite a difference between what people say they do and what they observably do. This is not necessarily because people play games (though they do), sometimes they are truly surprised when confronted with the difference. With the journalists in the Radio project our observations told us that there was a contradiction between their initial request for technology to support cooperation and their enacted values showing a desire for working solo. Our detailed study of their work practice aimed at making it discussible in which parts of their work they wanted to cooperate and in which they preferred to work alone with. The final design reflected a joint decision of this aspect [10].
We are in favour of participatory design as a democratic ideal. Also we are in favour of having users at all levels from the organisation participating in managing the project: it as a human right to be able to influence one's own working situation. Also we have pragmatic reasons: as designers we need direct interaction with users' knowledge in order to propose feasible designs, and there is a need for anchoring a design vision with those who are going to create the change.
Though we advocate a participatory approach we have not always succeeded in establishing a real working group consisting of users and designers[2] taking joint responsibility for the process as well as the product of the design project. Sometimes we have had to accept that users would just show up at meetings arranged by us, being willing to be observed, test a prototype, decide upon what to do next, or what ever kind of activities we ask them to participate in. This is however not the ideal form of cooperation, either in terms of democratic principles or in terms of anchoring design visions in the organization.
A good product of a design process most often is a mix of tradition and transcendence [16]. One reason for bringing in designers is to transcend the tradition. At least someone in the organization has considered some of the old ways of doing things have lost their rationale, or found that new technological opportunities are worthwhile investigating. We have experienced managers as well as employees in that role. However, designers need to respect traditions in an organization, both as a way of maintaining (or establishing!) credibility but also because there often is a rationale behind phenomena perceived odd by a newcomer. Designers thus have to be careful in reading the meaning attached to mundane activities, modes of cooperation, or artefacts used in the work processes.
Overall approach
We apply a combination of intervention and ethnographic techniques in our overall iterative approach to design. In earlier
work [26] we advocate that it is the responsibility of designers[3] to set up activities applying tools and techniques that will
allow themselves and users to develop knowledge at two levels,
abstract and concrete, within three areas: users' present work,
new systems4, and technological options5. A combination of intervention
and ethnographic techniques in an iterative approach has turned
out to be a good learning strategy for this purpose.
It is crucial for designers to develop a thorough understanding of users' present work (work practice, organization of work, products/services, relations to customers, clients, suppliers, history of recent major changes, management strategies and style, etc.) This in order for the design to reflect - in a realistic way - the traditions of the organization. Realistic in the sense that the design reflects an appreciation of the rationale given by members of the organization, and in the sense that the organization is geared to meet the challenge of the envisioned design. Thus, by detailed studies of the present situation we try to "measure" the organizations needs and readiness for change. What we are trying to avoid is a too futuristic design or a design, the greater proportion of which will never be used. We have found that ethnographic techniques are helpful in accomplishing this.
Ethnographic techniques vs. intervention
Ethnographic techniques come out of a tradition where the basic
idea was to develop and present to other scholars an understanding
of a foreign culture. In its original form this implied that ethnographers
tried not to change what they were studying. Current ethnographers
however, reconceptualize this practice and try to establish an
encounter between different cultures, for the purpose of informing
those involved [4, 21]. Also Blomberg, Suchman and Trigg report
from a project "linking ethnography with design" in an organizational
setting: "We orient to the details of people's practices, recognizing
the importance of members' own articulation of what they do [....]
we are accountable to the people who are or may become users of
our technology" [4].
Interventionists deliberately set up activities designed to change the organization or the work settings of some of its members. The presumption is that it is through change that key factors of organizations and their members perception become observable. Our interventions address each of the three areas of discourse in figure 1 (users' present work, new system, technological options). The intentions are to facilitate reflections upon current practice, to generate ideas, and to further develop the "technological fantasy" of users and designers.
We strive to select carefully the area and the mode of intervention based upon what we have learned by the ethnographic techniques. This is in contrast to some consultants bringing with them from site to site a design concept, claiming that what people in the organization know is irrelevant for their re-engineering project[6]. Using ethnographic techniques - as they were originally developed - one spends years to develop and present an understanding of the culture studied. The interventionist is more impatient. Taking into account the time constraints put on most designers in the context we are talking about, we have found that interventions help make short cuts feasible. Also we find that ethnographic techniques provide a significantly deeper understanding than traditional computer science/software engineering techniques. This holds even when the former are used in "a quick and dirty way" compared to what they were originally developed for.
When we first tried to become quasi-ethnographers, colleagues and students claimed that such an approach would take far too much time, so why not start prototyping right away? We found that spending time on analysis, without going to the extreme of systems analysis of the 70-ties and 80-ties, paid back in relation to single out areas of the work relevant for prototyping and in relation to generating realistic design proposals. Also we found that detailed knowledge of users' current work allowed us to discard by 'mental testing' design ideas that turned out not to be worth prototyping [10, 41].
Ethnography and intervention are contradictory in terms of basic approach and intended results.However to us at a practical level, the two approaches in combination have been an effective way to learn about the organization and also a main resource for generating realistic visions of future use of technology.
We have one main concern though, which is part of the reason we think it is necessary to reveal and discuss approaches in the CSCW community, part of which develops technologies with a wide range of impacts on organizations, groups, and individuals. Getting to know people in an organization as closely as you do when carrying out in-depth analysis for the purpose of design, you easily get into political/ethical dilemmas [4, 41]. Since organizations are (also) political battle fields - people are fighting for their jobs, for preserving/getting an interesting job, for preserving/increasing their power base etc. And since the introduction of new technologies often affect such issues, designers cannot avoid playing a role and sometimes taking a stand in these battles. This is true whatever approach designers use, but some approaches allow you to keep a higher distance from those affected by your designs than others. Choosing an approach that might get you into close relations with users, you had better be prepared to defend your observations and design ideas - not all designers may be ready for that, nor may their employers give them the opportunity.
Iteration
The overall approach is iterative in two ways. First we iterate
between analysis of the present and generating and eventually
prototyping design ideas. This is not at all a new idea. Second
we iterate between the two levels of knowledge indicated in figure
1 (abstract, concrete). This is in contrast with most methods
currently used in systems design, where an understanding is achieved
only by acquiring abstract knowledge documented by formal tools
and techniques. Kensing and Munk-Madsen [26] argue from a theoretical
standpoint that designers have to put themselves in situations
where they experience users while they are performing their every
day activities. In [10, 41, 42] we have illustrated the consequences
this kind of experience had as to the proposed design.
Techniques
In our design projects we have applied a number of techniques
to support the investigation os users' present work, technological
options and the new system, as well as iterations back and forth
between the various areas. Some of the techniques are well-known,
such as observation, interviewing, and prototyping, while others
are more specifically developed within various design traditions,
e.g. design workshops from the Participatory Design-tradition
[18, 34, 40]. Each technique provides information which might
identify a need for further investigation, either in terms of
opening up the search space - when it turns out that the problems
are not properly understood, or not agreed upon - or narrowing
down the search space - when it turns out that it is necessary
to understand the problem in greater detail by e.g. using another
technique.
Some techniques rely on users as informants through interviews in situations detached from their ongoing work, others rely on the designers' ability to observe users while performing their daily work, yet others establish a situation in between (e.g. interview in-situ). What ever the situation, we have found it important - even if we do focus on specific issues - to constantly remind ourselves to be open to what ever might come up. Field notes or audio/video recording are helpful tools for documenting and for shifting focus [10, 41, 45].
Ethnographers have developed elaborate techniques for analyzing recordings [23, 45]. We have no experience in this type of analysis, though for some tapes we have done content logging. Running through the tapes several times may generate hypotheses and design ideas, or identify issues to look for in greater detail.
Representations
In our design projects we have applied a number of representations
to document knowledge on users present work, technological options
or the new system. Designers might apply more formal representations
for their internal communication; e.g. in order to develop a prototype
a consistent data model (e.g. an E/R model) has been used. However,
we tend to postpone formal tools and techniques introducing concepts
and symbols not common to the users until detailed analysis and
implementation of the visions. At that time designers cannot do
without them, but still when users are involved in this part of
design, some kind of translation might be appropriate. In general,
representations are used to develop and represent knowledge with
a particular emphasis, so it is a medium for developing knowledge
as well as a medium for later referencing. We judge the relevance
of a description on how it facilitate discussions among us as
designers and among us and users and their managers.
The table below summarizes our techniques and representations and indicates in which projects they have been used.
QUESTION
We are working on an approach for designing CSCW-systems. We apply
a combination of ethnographic techniques and intervention in an
overall iterative approach. This is in line with what has been
labelled "ethnographically informed design"[7], as represented in e.g. [21]. Their approach implies that the
ethnographic study, performed by social scientists, inform the
systems design, performed by designers, and further that the system
design is evaluated and tested jointly. We take a slightly modified
approach. Being computer scientists we have used ethnographic
techniques in design processes. Our research goal is to develop
theories and approaches for design oriented towards practitioners
working under industrial conditions. Here we have not found sociologists
available. The question for us is how to present our approach:
what kind of guidelines and at what level of detail might designers
from industry find useful. These are the question we would like
to discuss at the workshop.
REFERENCES
[1] Andersen, N.E. et al. Professional Systems Development. Prentice-Hall, Englewood Cliffs, N.J., 1990.
[3] Bentley, R., T. Rodden et al (1992): Ethnographically-Informed Design for Air Traffic Control, in Turner, J. & R. Kraut (Eds): CSCW '92 Sharing Perspectives. Proceedings of the Conference on Computer Supported Cooperative Work, ACM, pp. 123-129
[4] Blomberg, Jeanette, Lucy Suchman and Randall Trigg. Reflections on Work-Oriented Design in Three Voices. To appear in S.L. Star "Paris workshop", 1994
[8] Bødker , Keld. A Cultural Perspective on Organizations Applied to Analysis and Design of Information Systems. In Organizational Competence in Systems Development. A Scandinavian Contribution, Gro Bjerknes et al. (Eds),.Studentlitteratur, Lund 1990.
[10] Bødker, Keld, and Finn Kensing. Designing Computer Support for Editorial and Administrative Work in an Editorial Section in a Danish Radio Station, in Proceedings of the 16th IRIS (Information Systems Research Seminar in Scandinavia),, Department of Computer Science, University of Copenhagen, Report no. 93/16, 1993, pp.376-394.
[11] Bødker, Keld, and Jesper Strandgaard Pedersen. Workplace Cultures: Looking at Artifacts, Symbols, and Practices. In [18].
[16] Ehn, Pelle. Work-Oriented Design of ComputerArtifacts. Arbetslivcentrum, Stockholm, 1988.
[17] Floyd, C. A Systematic Look at Prototyping. In Approaches to Prototyping, R. Budde et al. (Eds), Springer Verlag, 1984, pp. 1-18.
[18] Greenbaum, Joan, and Morten Kyng (eds). Design at Work: Cooperative Design of Computer Systems. Lawrence Erlbaum Associates, Chichester, UK, 1991.
[19] Heath, C. and P. Luff: Collaboration and Control. Crisis Management and Multimedia Technology in London Underground Line Control Rooms, in Computer Supported Cooperative Work, Vol 1, Nos 1-2, 1992, pp 69-94
[20] Heath, C, M. Jirotka, P. Luff, and J.Hindmarsh: Unpacking Collaboration: the Interactional Organisation of Trading in a City Dealing Room, in G. De Michelis, C. Simone, K. Schmidt (Eds): Proceedings of the Third Eurpean Conference on Computer Supported Cooperative Work, Kluwer, Dordrecht, Holland, 1993
[21] Hughes, J., D. Randall & Dan Shapiro (1992): Faltering from Ethnography to Design, in Turner, J. & R. Kraut (Eds): CSCW '92 Sharing Perspectives. Proceedings of the Conference on Computer Supported Cooperative Work, ACM, pp. 115-122
[23] Jordan, Brigitte and Austin Henderson. Interaction Analysis: Foundations and Practice. To appear in Journal of the Learning Sciences.
[26] Kensing Finn, and Andreas Munk-Madsen. Participatory Design; Structure in the Toolbox. In Communications of the ACM, no. 36, Vol. 4, 1993, pp. 78-85.
[27] Kensing, Finn and Terry Winograd. Operationalizing the Language/Action Approach to Design of Computer-Support for Cooperative Work. In Collaborative Work, Social Communications and Information Systems, R. K. Stamper et al. Eds. North-Holland, 1991, pp. 311-331.
[33] Mogensen, Preben, and Randall Trigg. Artifacts as Triggers for Participatory Analysis. In [34]
[34] Muller, M.J., S. Kuhn and J.A. Meskill (Eds): PDC'92 Proceedings of the Participatory Design Conference, Cambridge MA US, 6-7 November 1992. Computer Professional for Social Responsability
[35] Robinson, Mike: "Design for unanticipated use.... ", in G. De Michelis, C. Simone, K. Schmidt (Eds): Proceedings of the Third Eurpean Conference on Computer Supported Cooperative Work, Kluwer, Dordrecht, Holland, 1993
[38] Schmidt, Kjeld, and Liam Bannon: "Taking CSCW Seriously. Supporting Articulation Work" in Computer Supported Cooperative Work (CSCW). Vol. 1, Nos. 1-2, Kluwer Academic Publishers, Dordrecht, The Netherlands, 1992. pp. 7-40.
[40] Schuler and Namioka (Eds.). Participatory Design: Perspectives on System Design, Lawrence Erlbaum, Hillsdale, NJ1993.
[41] Simonsen, Jesper, and Finn Kensing. Take Users Serious, but Take a Deeper Look: - Organizational and Technical Effects from Designing with an Intervention and Ethnographically Inspired Approach. Stanford University/CSLI (Center for the Study of Language and Information), Report No. CSLI-93-185, 1994. (in press)
[42] Simonsen, Jesper. Technological Design in an Organizational Context, Ph.D. dissertation, Roskilde University, Computer Science Department, 1994 (Forthcoming).
[44] Suchman, Lucy A. Do Categories Have Politics? The Language/Action Perspective Reconsidered. In Proceedings of the Third European Conference on Computer-Supported Cooperative Work, 13-17 September 1993, Milan, Italy, pp.1-14.
[45] Suchman, Lucy A., and Randall H. Trigg. Understanding Practice: Video as a Medium for Reflection and Design". In [18].