RoskildeUniversity

MUSTA Method for Participatory Design

Kensing, Finn; Simonsen, Jesper; Bødker, Keld

Published in:Human-Computer Interaction

DOI:10.1207/s15327051hci1302_3

Publication date:1998

Document VersionPeer reviewed version

Citation for published version (APA):Kensing, F., Simonsen, J., & Bødker, K. (1998). MUST: A Method for Participatory Design. Human-ComputerInteraction, 13(2), 167-198. https://doi.org/10.1207/s15327051hci1302_3

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain. • You may freely distribute the URL identifying the publication in the public portal.

Take down policyIf you believe that this document breaches copyright please contact rucforsk@ruc.dk providing details, and we will remove access to thework immediately and investigate your claim.

Download date: 27. May. 2020

1

MUST - A Method forParticipatory Design

Finn Kensing, Jesper Simonsen, and Keld Bødker

Department of Computer ScienceRoskilde University

P.O. Box 260, DK-4000 RoskildeDenmark

Tel: +45 46 74 20 00Fax: +45 46 74 30 72

e-mail: { kensing, simonsen, keldb}@ruc.dk

ABSTRACTThe article presents a conceptual framework and a coherent method for designin an organizational context within the participatory design tradition. TheMUST method has been developed throughout 10 projects in Danish andAmerican organizations, and it has recently been evaluated and adopted by 3Danish organizations. The method is based on thorough participation withusers and managers, and it combines the use of ethnographic techniques andintervention. The article describes the application area and perspective of themethod, presents 6 general principles on which the method is based, anddescribes 5 main activities providing a stepwise decision-making process inthe overall design process. Each of the main activities are illustrated by anexample taken from our last project. The article concludes by summing up themain points.

© Lawrence Erlbaum Associates, Inc. Reprinted with permission fromLawrence Erlbaum Associates, Inc. This article is originally published inHuman-Computer Interaction, Vol. 13, No. 2, 1998, pp. 167-198.

2

CONTENTS

1. INTRODUCTION ........................................................................................... 3

2. WHY A METHOD, AND WHAT KIND OF METHOD?........................................ 6

3. THE SIX PRINCIPLES ................................................................................... 9

3.1. Principle 1: Participation............................................................................ 93.2. Principle 2: Close Links to Project Management ...........................................103.3. Principle 3: Design as a Communication Process...........................................123.4. Principle 4: Combining Ethnography and Intervention....................................13

Ethnography: Firsthand Encounters.............................................................13Intervention............................................................................................15Iterations................................................................................................15

3.5.Principle 5: Co-development of IT, Work Organization, and Users’ Qualifications.163.6. Principle 6: Sustainability .........................................................................17

4. FIVE MAIN ACTIVITIES CONSTITUTING THE DESIGN PROCESS..................19

4.1. Project Establishment ...............................................................................214.2. Strategic Analysis ....................................................................................234.3. In-Depth Analysis of Selected Work Domains ...............................................244.4. Developing Visions for the Overall Change ..................................................264.5. Anchoring the Visions..............................................................................28

5. SUMMARY..................................................................................................29

NOTES............................................................................................................30

REFERENCES .................................................................................................30

3

1. INTRODUCTIONThe purpose of this article is to present a coherent method, the MUST1

method, for participatory design (PD). Referring to the distinctions of Grudin(1991), the article presents a method for PD in an organizational context,where this context is either in-house/custom development or competitivebid/contract development. The method is not intended for Grudin’s thirdcategory, the design of generic products for a large market.

We use the term design in the same way as architects do - focusing on theanalysis of needs and opportunities and the design of functionality and form.We do acknowledge, however, that in a succeeding development process,further design is needed, and that when applying a computer system, usersmight very well find new ways of utilizing the system, as well as come up withadditional demands. This does not negate the need for a design that is a goodfirst approximation.

The MUST method has been developed throughout 10 projects in Danish andAmerican organizations (Kensing, Bødker, & Simonsen, 1994), and it hasrecently been evaluated and adopted by information technology (IT)professionals within three Danish organizations, one of which is documentedin Kensing, Simonsen, and Bødker (1998). The method is inspired byethnographic approaches, (see, e.g., Blomberg et al., 1993; Blomberg,Suchman, & Trigg, 1996; Hughes, Randall, & Shapiro, 1992, 1993; Suchman,1995), and by Scandinavian participatory design approaches, (see, e.g.,Greenbaum & Kyng, 1991; Grønbæk, Kyng, & Mogensen, 1993; Kensing &Munk-Madsen, 1993; Kyng, 1995). We have designed IT support for 9people on an editorial board of a film company and for 50 people working ina research and development lab; we have designed multimedia support for 140people working at a radio station. All the work domains can be characterizedas professional work in complex settings with a very open-ended agenda forthe design project - no clear statement of the problems, of the kind of ITsupport needed, or of how the project should be carried out.

The MUST method relates to other approaches to design in a number ofways.

First, it is important to note that we offer a conceptual framework of thedesign process, whereas, for example, Stolterman (1991), and Ehn, Meggerle,Steen, and Svedemar (1997) developed a conceptual framework facilitating an 1 MUST is a Danish acronym for theories of and methods for design activities.

4

ongoing evaluation of the qualities of the designed products. Yet others (e.g.,Carstensen, 1996; Rasmussen, Pejtersen, & Goodstein, 1994; Schmidt, 1990,offered a framework for the conceptualization of users’ work domain.

A second distinction is related to the application area of the proposedmethods. The MUST method focuses on the early activities in a developmentprocess, like most PD methods, business process reengineering (BPR;Hammer & Champy, 1993) and object oriented analysis (Coad & Yourdon,1991). It offers guidelines for project management (like BPR) as well as forthe design proper (like PD and object oriented analysis). The CooperativeExperimental System Development method (Grønbæk, Kyng, & Mogensen,1997) deals with the entire development process, but focuses solely on thedesign proper.

A third distinction, also related to the application area, is what kind of changesthe design process strives towards. Although downsizing is an inevitableconsequence of BPR (Hammer & Champy, 1993, p. 212), ethical issues inrelation to involving users are not dealt with. We state explicitly that if man-agement aims at job cuts or other drastic changes, this should be announcedup front.. If users know and accept these objectives, we still recommend aparticipatory approach.

Fourth, the MUST method includes management issues in relation to designprocesses in an organizational context. This has not been dealt with earlier inPD literature, where the focus has been on why and how to work with users.Although S. Bødker (1996) reported on the role of management in relation tothe future use of a system, she does not deal with the role of management inthe processes of generating visions and helping them to materialize.

Fifth, though linking - or aligning - a business strategy to IT is addressed ininformation systems (IS) literature, especially within the field of strategicinformation systems planning, it is generally viewed as a (top) managementissue (Cash, McFarlan, & McKenney, 1992; Keen, 1991; Lederer & Sethi,1991) dominated by a rational top-down approach (Henderson & Sifonis,1988; Premkumar & King, 1994; Yetton, Craig, & Johnson, 1995). Instead, inline with, for example, “the double-loop transformation process withinstrategic alignment” (Henderson & Venkatraman, 1992) and “theorganizational approach” (Earl, 1993), we consider the relations between adesign project and an organization’s business and IT strategies. And wedeal with these issues from the perspective of IT professionals.

5

As a sixth distinction, we argue for the need for a separate design activityincluding the development of visions for the overall change, to produce asustainable basis for further development and implementation. Otherapproaches (see, e.g., Grønbæk et al., 1997) primarily strive for an ac-countable design through extensive user participation in prototyping.

Seventh, Plowman, Rogers, and Ramage (1995) reported that the dominant ap-proach in projects using ethnography consists of sociologists conducting theethnographic studies and informing IT professionals of their findings. Weand others (see Blomberg et al., 1996; Shapiro, 1994) are working toward acloser link between ethnography and design. We recommend that ITprofessionals start practicing ethnographic techniques themselves in theircooperation with users. In some countries, such as Denmark, there is notradition - in organizational settings - for involving sociologists oranthropologists in design projects. Our experiences confirm that it is possibleand valuable for IT professionals to use ethnographic techniques as part oftheir design activities (K. Bødker & Kensing, 1994; Kensing & Winograd,1991; Simonsen & Kensing, 1994, 1997, 1998).

Finally, although systems development methods suggest various formalismsfor describing users’ current work and the envisioned design of IT systems(e.g., Coad & Yourdon, 1991), formalisms play a minor role in the MUSTmethod. Instead we suggest plain text, freehand drawings, and sketches for theproduction and presentation of the relation between proposed IT systems andusers’ current and future work practice. An extended use of formalisms ispostponed until later on in the development process.

According to Mathiassen (1981), a method is characterized by its applicationarea, its perspective, and its guidelines: techniques, representation tools, andprinciples for organizing a project. Our suggestions according to thesecategories are described later. Section 2 explains why IT professionals need amethod like MUST as a resource for design activities. Section 3 presents andargues for the method’s guiding principles, whereas Section 4 describes themain activities that constitute a design process according to MUST. Wesuggest techniques for each of the main activities and illustrate how they werecarried out in a recent project. The article is concluded by a summary. Forfurther examples, we refer the reader to K. Bødker (1990); K. Bødker andKensing (1994); Kensing et al. (1998); Kensing, Bødker, and Simonsen(1994); Kensing and Winograd (1991); Simonsen (1994, 1996, 1997); andSimonsen and Kensing (1994, 1997).

6

2. WHY A METHOD, AND WHAT KIND OF METHOD?In the years of outsourcing and BPR, many organizations have chosen tooutsource costly and hard-to-manage software development. Bansler andHavn (1994) referred to this as “the ‘industrialization’ of informationsystems development” (p. 707), and they argued that in the future, most ITsystems will be based on prefabricated generic systems.

In the same way that prefabricated walls, beams, and doors have not madearchitectural design irrelevant, we have found that the increased use of genericsystems does not rule out a need for customized design. We argue that it isthe job of design, based upon a thorough understanding of the organization inquestion, to investigate which generic systems are adequate, as well as how toreorganize work accordingly. Often generic systems need to be customizedand supplemented with the design of organizationally specific systems tofulfill a coherent solution. It is these parts of systems development that we calldesign and that our method deals with: the analysis of needs and opportunitiesand the preliminary design of functionality and form. An organization maycarry out a design project in cooperation with either internal IT specialists orexternal consultants. These we refer to as IT professionals, and they may ormay not participate in the succeeding development and implementationactivities.

In Figure 1, we combine Bansler and Havn’s (1994) project model forindustrial software development with our experiences. In this model, theorganization relies on outside contractors for software development.

The organization’s IT department (or external consultants) in cooperationwith the user departments performs the design and specification of one ormore coherent visions for change (“design”) and then prepares a contractualbid (“Contractual bid and selection”). The chosen contractor then gets thecontract of delivering generic IT products or developing organizational-speci-fic systems (“Delivery and/or development of IT”). In parallel, the ITdepartment performs “Delivery management”. This involves quality controlof deliverables from contractors. It also includes facilitating the organizationalimplementation by working with the user departments, external contractors,and other involved parties. There are major managerial decision points after“design” (e.g., which of the proposed solutions to go for) and as part of“Contractual bid and selection” (e.g., which contractor to choose). For ITprofessionals, this means taking on a role similar to that of an architect.Besides designing a building, the architect often is in charge of the overallsupervision when the building is constructed. A particular instance of this

7

model occurs when the organization’s IT department chooses also to bid onthe contract, in which case, the systems development might take place as in-house development (Grudin, 1991).

Contractualbid and

selection

Design

Deliverymanagement

Use anddesign - in - use

Delivery and/ordevelopment

of IT

MUST

MUST

Figure 1. Project model for IT development.

The model (as well as Bansler & Havn, 1994) indicates that IT professionalsneed special skills to deal with people in the user organization on their ownbasis, and not solely on a technical basis. IT professionals have to handlecomplex and open problem situations. We see a method as a resourceavailable for IT professionals facing such situations, rather than as a recipe tobe followed step by step. IT professionals need methodological support forthe activities that take place in an organization before a contractual bid andselection can take place and before the organization can decide which genericsystems to select and purchase. We propose the MUST method as supportfor IT professionals responsible for these initial parts of IT development. Wehave learned that for IT professionals to integrate new work practices, adescription of the method is needed, and the method also has to be

8

supplemented with other activities. We are currently involved in thesupervision of ongoing projects involving IT professionals who areintegrating the MUST method as part of their work practices.

The MUST method has been developed to support the design activity, asshown in Figure 1. The method is coherent in the sense that it deals with allactivities within its application area: analysis of needs and possibilities,generation of visions for change, project management, and planning fortechnical and organizational implementation. Most Scandinavian PDresearchers, coming from a background in trade union projects, have notexplicitly dealt with activities related to management (see, however S. Bødker,1996). We want to stress that for design ideas to be implemented, establishingand maintaining relations with management is crucial when designing in anorganizational context.

Design in an organizational context is an open-ended process. The objectiveof the design project is to investigate the situation and provide information fora decision about how to proceed. If appropriate computer systems can beidentified, the overall functionality and form of such systems are outlined. Theresults of a design project should include a conceptual design in terms of awritten document, sketches, mock-ups, and prototypes. We consider anevaluation of consequences of implementing the design, as well as a plan forthe implementation, to be parts of the result, too. Based on a design proposal,it should be possible for the organization to say “stop,” to say “more designis needed,” or to proceed in purchasing and developing the proposed design.The project may afterwards proceed to development and implementation, butwe consider these parts of systems development to be outside the applicationarea of our method.

We see organizations as frameworks for cooperation as well as for conflicts.Groups and individuals participating in design should be expected to havecommon as well as conflicting goals. The role of IT professionals is neither tocover up nor to solve political conflicts in design. Rather they should help theparties formulate their visions and leave it to them to solve conflicts in relevantfora (see Principle 2 in section 3.2). A good design most often is a mix oftradition and transcendence (Ehn, 1988). One reason for bringing in ITprofessionals is to transcend the tradition. At least one person in theorganization has considered that some of the current ways of doing thingshave lost their rationale, or they have considered that new technologicalopportunities are worthwhile investigating. However, IT professionals need tounderstand and respect the existing traditions in an organization, both as a

9

way of maintaining - or establishing - credibility, and to understand therationale behind phenomena that otherwise can be perceived as odd by anoutsider.

We want to emphasize that an important ethical issue involved in applying ourmethod - and for participation in general - is that if management wants jobcuts or other drastic changes, this should be announced up front. Otherwisean important ethical principle will have been violated and, as a consequence,participation will be made more problematic and difficult in future projects.This does not imply that drastic changes cannot be realized by a participatoryapproach. We have experienced drastic changes in work organization as partof design projects, as well as job cuts just before the project started, but theusers knew and accepted the objectives beforehand (Kensing et al., 1998).

3. THE SIX PRINCIPLESOur method is grounded in six principles and offers a set of techniques andways of representing current work and the envisioned computer-basedsystems. We consider the principles to be indispensable, although thetechniques and representation tools may be chosen by the IT professionalsaccording to their preferences and understanding of the situation in question.In this section we present each of the six principles and illustrate varioustechniques, representation tools, and principles of organization, whenappropriate.

3.1. Principle 1: ParticipationA large proportion of the software installed in organizations is never used.The primary reason for this is that IT professionals have not understood thespecifics of the organization in question (Boehm, 1981; Bullen & Bennett,1990; Lederer & Sethi, 1991; Lyytinen & Hirschheim, 1987; Orlikowski,1992). Participation is a way of increasing the chances for a design tocorrespond with real needs and to be used as intended.

There have been both pragmatic and political arguments to participatorydesign (Ehn, 1988; Greenbaum, 1993). The pragmatic argument stresses thatparticipation between IT professionals and users enables a mutual learningprocess and facilitates the development of an envisioned computer-basedsystem. IT professionals need knowledge of the use context, users needknowledge of the technological options, and these should be developed in acolearning process. In our projects, this view has been acknowledged byusers, management, and IT professionals. Further, in this article, we argue that

10

for a design vision to be realized, not only does an IT solution need to betechnically correct, but the design team also needs to focus on anchoring thevision in the organization. This requires the design team to engage multipleparticipants in the design endeavor. It is the responsibility of the IT pro-fessionals to organize a participatory design process, and it is the respon-sibility of the management to provide users with the necessary time andinformation to participate in this process.

Political arguments to participatory design stress users’ rights to influencetheir own working conditions and that this should be taken care of by theirlocal union representatives (Ehn, 1988; Greenbaum, 1993; Kyng &Mathiassen, 1982; Nygaard, 1975). From the very start of the Scandinaviantrade union projects, it has been a key issue to ensure that users get time off toparticipate and that trade unions should build up their own competence apartfrom the management-controlled systems development process (Ehn &Sandberg, 1979; Kyng & Mathiassen, 1982; Nygaard, 1975). We have greatrespect for these projects. However, we realize that IT professionals need to bepragmatic, too. In the years of downsizing, with the decrease of unions’ powercombined with the increase of employees striving to build a career - or holdon to their jobs - we have experienced very valuable user representatives. Inspite of the fact that users were not given time off for participation and tradeunion participation has been low, or non-existent, the users were most eager toparticipate in project groups and as informants.

3.2. Principle 2: Close Links to Project ManagementProject management deals with the division of labor in the project, how theproject is designed as a process, quality control, and how conflicts are dealtwith. We deliberately include establishing close interaction between projectmanagement and activities related to the design proper as a principle, becauseit has not been dealt with explicitly in PD literature.

We recommend a division of labor between a design team and a steeringcommittee. The design team should consist of a combination of ITprofessionals and future users. They are the ones responsible for carrying outthe project and for informing management and all future users. The steeringcommittee should include managers of the involved organizational unit(s); themanager of the IT department, if any; and one or two user representatives2.

2 In some organizations the local union (by law or agreement) has a say in relation to

11

The design team must decide how it will organize the process of developingan understanding of the organization’s needs and possibilities, developingvisions of future computer-based systems, and sketching plans for technicaland organizational implementation. Designing the project as a process is ofspecial concern in dealing with the early design activities, because they arecharacterized more as problem setting than problem solving (Lanzara, 1983;Schön, 1983). We do acknowledge that for a group of IT professionals to beefficient, they need to rely on a set of standard techniques, representationtools, and ways of conducting projects. However, each project needs to bedesigned according to an understanding of the specifics of the actual context.

As described in further details in Section 4, we suggest the project bedesigned around the following five main activities: (a) project establishment,(b) strategic analysis, (c) in-depth analysis of selected work domains, (d)developing one or more visions of the overall change, and (e) anchoring the vi-sions. Each activity produces knowledge that allows the design team to informall future users and allows the steering committee to focus on the type ofdecisions that the design team needs to make in order to proceed. This enablesthe steering committee to make decisions on a qualified basis, thus minimizingrisks in the ongoing interpretations of the project’s goals, and of developingunrealistic visions.

Design is also a political process where groups and individuals have commonas well as conflicting goals (Andersen et al., 1990). The steering committee isresponsible for supervising the design project, dealing with potential andmanifest conflicts, and making decisions based on information provided bythe design team. We suggest leaving it to the steering committee to deal withthe conflicts generated or becoming manifest in relation to the project. It is notup to the design team to solve the political controversies, but the team doeshave a role in providing a sound basis for dealing with them and in seeing thatthey are dealt with in the relevant fora. This has been emphasized in most ofour projects (see K. Bødker, 1990; K. Bødker & Kensing, 1994; Kensing etal., 1998; Simonsen, 1994; Simonsen & Kensing, 1994; 1997).

We suggest three techniques for the design and the continuous evaluation ofboth the process and the product: project establishment, planning withbaselines (Andersen et al., 1990), and reviews (Freedman & Weinberg, 1982). development of new IT systems. If this is the case, we recommend that shop stewardsbecome members of the steering committee. If this is not the case, users should be giventhe opportunity to appoint representatives.

12

3.3. Principle 3: Design as a Communication ProcessIn earlier work (Kensing & Munk-Madsen, 1993), we created a model of thecommunication between users and IT professionals (see Figure 2). The modelis based on two distinctions: dealing with three domains of discourse and twolevels of knowledge. The model is not a process model. It depicts six areas ofknowledge that need attention. How knowledge in these areas is developed isdealt with in Section 4.

Users’ present work New system Technological options

Abstractknowledge

Relevant structures ofusers’ present work

Visions and designproposals

Overview oftechnological options

Concreteexperience

Concrete experience withusers’ present work

Concrete experiencewith the new system

Concrete experience withtechnological options

Figure 2. Six areas of knowledge in user-IT professional communication.

“Users’ present work” includes work practice, organization of work, use ofIT, products and services, relations to customers, clients, and suppliers, historyof recent major changes, management strategies and style, and so forth. “Newsystem” includes envisioned technology in relation to new work organizationfor the specific work domain. “Technological options” incorporates generalknowledge and experiences with IT and its relation to work organization. Thethree domains reflect both the users’ and the IT professionals’ typicalprerequisites in terms of knowledge and understanding prior to entering thedesign process. At the outset, the users have knowledge of their present workand of organizational options. The IT professionals have knowledge oftechnological options with regard to hardware and software. At the outset, thisis all we can expect them to know.

The second distinction between abstract knowledge and concrete experienceexpresses that we need to deal explicitly with two levels of knowledge. Just asprototyping is a powerful approach for developing concrete experience withvisions and design proposals, we argue that IT professionals need concreteexperience with users’ present work practices to understand and evaluate therelevance of oral or written descriptions of these practices. As we argue in thenext section (Principle 4), it is by iterating between these two levels ofunderstanding that the design team is able to develop the needed insight.

13

It is the responsibility of IT professionals to choose the techniques andrepresentation tools that allow them to establish a communicative process withusers, through which they are able to jointly develop knowledge within thesesix areas. Section 4 provides examples of techniques and representation toolsfor this purpose.

3.4. Principle 4: Combining Ethnography and InterventionWe apply a combination of ethnographic techniques and intervention in aniterative approach to design. We strive to select carefully the area and themode of intervention, based upon what we have learned by applyingethnographic techniques - in contrast to BPR (Hammer & Champy, 1993, p.207). Ethnography and intervention contrast in terms of their basicapproaches and intended results: ethnographers originally strove not tochange the phenomena they were studying, whereas interventionistsdeliberately set up activities to change the organization, to learn from thereactions to the change. However, we have experienced that at a practical level,combining the two approaches and iterating between them has been an ef-fective way to learn about the organization and also an important resource ingenerating realistic visions of future use of technology (see K. Bødker &Kensing, 1994; Kensing et al., 1998; Simonsen, 1994; Simonsen & Kensing,1994, 1997).

Ethnography: Firsthand EncountersBlomberg et al. (1993) stated that “to learn about a world you don’tunderstand you must encounter it first hand” (p. 125). It is crucial for ITprofessionals to develop a thorough understanding of users’ present work forthe design to reflect - in a realistic way - the norms and traditions of theorganization. A design should be realistic in the sense that it reflects anappreciation of the rationale given by members of the organization and in thesense that the organization is geared to meet the challenges of the envisioneddesign. Through detailed studies of the organization’s present situation, wetry to “measure” the organization’s needs and readiness for change(Christensen & Molin, 1983). We try to avoid an extreme futuristic design ora design of which the greater portion will never be used. We have foundethnographic techniques helpful in accomplishing this (K. Bødker &Kensing, 1994; Kensing et al., 1998; Simonsen, 1994; Simonsen & Kensing,1994, 1997).

Blomberg et al. (1993) suggest descriptions in terms relevant to those beingstudied, in contrast to applying traditional IS techniques and their formalisms.

14

The latter, when at their best, suggest interviews with future users but arerelying on the IT professionals’ predefined conceptual frameworks. InKensing and Munk-Madsen (1993), we argued that by going back and forthbetween observing users’ work practice and producing descriptions (orinterpretations, if you like) of these practices, IT professionals and users areable to develop an understanding of the current practices that are relevant indesign.

Figure 3. Excerpt from the collages (text is in Danish)

Formalisms play a minor role in the MUST method. In later parts of thedevelopment process, they are powerful tools, but when working with userswithout a technical background, we can easily do without them. We suggestusing plain text, freehand drawings, sketches on large sheets of paper (e.g.,representing communicative structures, the relation between work organizationand the use of current/envisioned technology, and so forth). The closest weget to using formalism with users is when we model information flows anddata structures for the purpose of prototyping.

We recommend two types of descriptions (reflecting the abstract/concretedistinction in Figure 2). One description is stated in language based on users’categories and presented in plain text or visualized - for example, by collages(see Figure 3, from K. Bødker & Kensing, 1994) or by wall graphs

15

(Simonsen, 1994; Simonsen & Kensing, 1994, 1997). The other descriptionpoints out current domains and creates envisioned structured domains thatmight benefit from new IT systems (Dahlbom & Mathiassen, 1993;Winograd & Flores, 1986). For these, we use problem lists (Kensing et al.,1998) or maps (Lanzara & Mathiassen, 1984). The first type we have founduseful in detecting and evaluating the relevance of the latter, which in turn isneeded for further design purposes.

InterventionInterventionists deliberately set up activities designed to change theorganization. As Dahlbom and Mathiassen (1993) put it, “only by trying tochange it [the organization] will we come to really understand it” (p. 169).The presumption is that through creating a change, key factors of theorganization and its members’ perception of it become observable - factorsthat might not be mentioned, for example, in interviews.

Schön (1983, 1992) described design as a reflective conversation with thematerials of a design situation. According to Schön, intervention happens inthe mind of the designer or through conversations among designers, ratherthan in the physical world, as with, for example, prototyping or organizationalexperiments. This type of intervention is less expensive in terms of time andpotential consequences and, thus, preferable, but sometimes imagination is notenough and “real” experiments need to be carried out.

IterationsTwo types of iteration interplay when we combine ethnographic techniqueswith intervention. First, iterations between interviews and observations allowIT professionals to be aware of the discrepancies between what people saythey do or want to be able to do and what IT professionals as outsiders areable to observe them doing. In other words, iterating between interviews andobservations helps IT professionals handle the say/do problem (Blomberg etal., 1993; Gougen & Linde, 1993). Second, iteration between usingethnographic techniques and intervention may be used to confront users withthese discrepancies between what is said and what is done. In K. Bødker andKensing (1994), we used the detection of such discrepancies as the input for adesign workshop3. Others suggest the use of rapid prototyping for similar

3 Beforehand we had formulated provocative statements highlighting the differencesbetween what users told us and what we were able to observe. These statements dealt withtheir current practice as well as with the relation between these and their ideas for IT

16

purposes, such as Mogensen (1992) who suggests the term provotyping. Yetothers, such as Blomberg et al. (1996), suggest case-based prototypes. Wesuggest the two types of iteration even prior to prototyping.

3.5. Principle 5: Co-development of IT, Work Organization, andUsers’ QualificationsIT is introduced because someone - usually management - wants change.However, projects far too often focus solely on IT systems, leaving it to theusers to struggle with the organizational implementation afterwards andreducing educational aspects to training the functionality of the systems.

Organizational development

Development of IT

Development ofusers' qualifications

Figure 4. Co-development in related domains.

Since the early 1970s, Mumford and associates have worked on asociotechnical approach (see Mumford, 1972, 1993; Mumford, Land, &Hawgood, 1978) advocating development of the social and technical systemsmore or less parallel to each other. The approach was heavily critiqued byScandinavian researchers involved in trade union projects in the mid- to late1970s. The critique was two-fold. From an ideological point of view, theapproach to users’ participation and control was evaluated as too narrow;from a technical point of view, the proposed techniques were evaluated asnaive and as not addressing relevant aspects (Ehn & Sandberg, 1979; Kyng &Mathiassen, 1982). However, we owe to the sociotechnical approach thedouble focus on organizational and technical issues and for includingmanagement in a participatory approach. The sociotechnical approach evenincluded prototyping as early as 1978 (Mumford et al., 1978).

support. This led to an evaluation of consequences of the design ideas and a clarification ofwhich work practices they preferred, which in turn resulted in a modified set ofrequirements.

17

We recommend, as indicated in Figure 4, including a third issue in this co-development process - users’ qualifications because we have seen too manysystems that are only partly used because users have never been properlyintroduced to them. “It seems that the money ran out,” as one user stated it.Educational activities help users (re-)gain control over their jobs and allowsthem to be more efficient.

Users need the qualifications to operate the systems that are supposed tosupport their work. However, this is often neglected in practice, and training isoften organized around the functionality of the system rather than around theusers’ daily work. A design team’s report should suggest who should receiveeducation, how much education (in terms of content and time), how theeducation will be organized, and an estimate of the costs. If a new division ofwork is part of the design, or if new products or services are part of the overallvision of change, we see it as part of the design report to suggest adequate ed-ucational and training activities and an evaluation of the costs. Finally, wesuggest an initial and ongoing introduction of user representatives to themethod used in the project, as well as to what is expected from them in termsof involvement, relation to colleagues, and the specific tasks they will beparticipating in. The reason that we stress the importance of informing usersof these issues is not in any way to hinder them from suggesting or takingother initiatives themselves. The point is that far too often we have seenprojects where users were unaware of the scope and rationale of theirparticipation.

All in all, a design project needs to address, plan for, and estimate the costs oftaking care of technical, organizational, and educational issues. This should bedone to produce a sustainable basis for the organization’s decision makingand for the succeeding development of the technical and organizationalimplementation to constitute a coherent whole.

3.6. Principle 6: SustainabilityThe early design activities are a first step in introducing sustainable IT. Wedeliberately use this ecological concept as a metaphor in an attempt to capturean overall picture of the use of the method. In ecology, the concept ofsustainability refers to a balance between the utilization and the protection ofthe earth’s resources in order not to destroy the basis of mankind. There is agrowing awareness of problems, alternative products and productionprocesses are being developed, and the market is slowly adapting. We see amodest start of a similar process in the development and use of IT systems.

18

Negative consequences have been seen. Some IT systems have been designedor introduced in ways that made it difficult for users to use/develop their skillsand experience as part of their job (see, e.g., Sachs, 1995). Often IT systemshave failed economically, too - expected rationalization did not materialize, andprojects ran far over budget. In such projects, scarce resources such as moneyand users’ qualifications were not taken properly care of.

Researchers and practitioners have developed alternatives - regardingprocesses within PD and also regarding products within computer supportedcooperative work - thus providing a basis for using and developing valuableresources in organizations. Users and managers have shown an interest inalternative products and processes. Of course they might not always agree onthe positive and negative consequences of the application, but we have seen awillingness to have such issues dealt with up front in design projects(Kensing et al., 1998). What still remains is for IT professionals - on a largerscale - to be introduced to a coherent method for participatory design. This isthe ambitious goal of the MUST method.

What is needed is a change of attitude for most managers and ITprofessionals. They need to experience through practice the effects of leavingthe traditional expert strategy, the result of which sometimes has beencompletely reversed. The way many systems work shows that rationality haslapsed into irrationality. Such cases are often reported in the news and havebeen documented by a wide range of ethnographic studies. However, inworking with managers and IT professionals in most of the 10 projectsinforming our method development, we have experienced an increasingawareness of the pitfalls in the predominant practice, as well as a willingnessto experiment with alternatives.

The pragmatic argument for participation is related to the principle ofsustainability. The MUST method suggests a high degree of userparticipation in order that new IT systems fit with preferred work practices,and the method supports the organization in an up-front uncovering anddealing with conflicts arising in relation to the introduction of IT (seePrinciple 2). Users, managers, and IT professionals in our projects sometimesfound this cumbersome, but compared with previous experiences, they foundit helpful in laying the basis for the proposed change.

19

4. FIVE MAIN ACTIVITIES CONSTITUTING THE DESIGNPROCESSIn the MUST method, the overall design process is constituted by five mainactivities: (a) project establishment, (b) strategic analysis, (c) in-depth analysisof selected work domains, (d) developing visions of the overall change, and (e)anchoring the visions. The main activities, each having their own purpose,support a stepwise decision-making process. Iterations are recommended,especially between the first and second activity and between the third andfourth activity. The fifth activity should be seen as an ongoing concernthroughout the project.

I Section 4.1 through Section 4.5, we discuss each of the main activities, andin Figures 7 through 11 we give examples of techniques, representation tools,and principles of organization taken from a recent project. To give the readeran idea of the complexity of the organization and the suggested overall design,we refer to Figures 5 and 6.

The examples focus on the procedural aspects of an application of themethod. We refer the reader to Kensing et al., (1998) for details on theintermediary and final products that the design team produced.The purpose of the project was to bring multimedia support to P3, a music channel of theDanish Broadcasting Corporation, DBC. To help the reader contextualize the example, wepresent some of the background and the overall design of computer support that resultedfrom the project (see Figure 6).DBC is the only Danish public station which is entirely funded by citizens paying a licensefee. The corporation is divided into a TV section and a radio section. DBC has undergoneseveral changes since its monopoly was broken in the late 1980's. While the former CEOhad publicly announced that he didn’t see it as his job to contribute to the growth inunemployment, the new CEO announced major restructuring for the purpose of producingmore TV and radio for less money. These changes include: A shift in the corporation’sprofile from a production company to a broadcasting company; new IT support foradministrative and managerial purposes; a different division of labor among journalists,technicians, and administrative staff; a shift from analogue to digital technology;restructuring of the IT departments; and considerable layoffs.The Radio section comprises 3 national radio channels, a news group, and 9 regional radiostations. There is competition among the national channels and the regional stations, aswell as between these and Danish and international radio and TV stations. The Radio strivesto meet the competition by the introduction of new technology, by reducing costs, and bysharpening the profile of the programs.

Figure 5 (part one). Introduction to the design context (from which later examples aredrawn).

20

P3 has 140 employees broadcasting 24 hours of radio daily all year round. When the projectstarted the channel had very little computer support. It had only on line access to newsagencies (NewsStar) and access to mainframe systems, like library systems used for searchingin a database for the corporations music titles and earlier broadcasted programs. As toproduction and broadcasting, the equipment was analogue, except for experiments with harddisk editing of pre-produced features and computer based selection of music for broadcastingduring the nights. In addition, typewriters, photocopiers, and text processors were used for theproduction and distribution of plans, manuscripts and management memos. The focus of theproject was on the production of programs, while administrative and managerial aspects wereonly to be considered to the extent that production activities would generate relevantinformation for these purposes.In relation to the P3 project, the most important parts of DBC’s IT strategy are:- that the technological platforms for office work and for the production and broadcasting of

TV and radio will merge,- that BPR is needed in relation to many work processes and that selective outsourcing

should be applied for example in relation to development of applications, networks,installation of PC’s, support, and the maintenance of installations,

- that new information systems should be based on standard systems, client/servertechnology, and a new wide band local area network (Intranet),

- that IT and data communication will be the strategic tools for reaching the right customerswith the right products at the right time, as well as for reengineering internal workprocesses.

- that the key factor to success is that management and employees in the radio will beactively engaged in the control and implementation of IT.

As depicted in Figure 6 the project developed a coherent vision for changing the ways in whichprograms are produced. MS-office is used for writing stories (Word) and for communicationpurposes (E-mail). Host allows access to DBC’s administrative systems. Journalists haveaccess to News Agencies, the Internet/WWW, and an Event Calendar for research purpose.They search in Sound Databases for music titles and earlier broadcasted material. List of Ideasholds the potential stories for a given program. While working on a specific story a journalistuses Program Element to type in the information needed during broadcasting. DigitalRecording and Editing is used for the production of each element in a program which is thenstored in the Pool from where the producer drags and drops them into the Manus (hismanuscript). The required reports about broadcasted programs are generated automatically bythe Report Generator. Video Links support the communication between the studios and theoffices in which the journalists work on their stories before they go to the studios.

Figure 5 (part two). Introduction to the design context (from which later examples aredrawn).

21

Figure 6. The suite of systems included in the design team’s vision for change.

4.1. Project EstablishmentWe always recommend starting with project establishment (Andersen et al.,1990). This is a systematic technique supporting the clarification and nego-tiation of the aim, level of ambition, scope, and conditions of the project. Thetechnique also suggests activities for the design team in deciding which toolsand techniques it will use to conduct the project, as well as for establishing theteam as a social unit. Although many projects start out from a rather loosedescription, project establishment provides the steering committee and thedesign team with a sound basis for the succeeding project activities.

In Lanzara’s (1983) terms, project establishment is a reframing process. Wehave often experienced that management and users have had rather specificideas of which IT systems are needed, but the problematic situation leading tothe solutions had not been analyzed properly (see Simonsen, 1994, 1996,1997; Simonsen & Kensing, 1994, 1997). We find that it is the responsibilityof IT professionals to question such ideas, and project establishment is thefirst attempt in that direction.

22

Project establishment involves

• An initial analysis to understand the purpose of the project. This includespresentation rounds in various organizational units, interviews,observations, and an initial analysis of materials and artifacts used.

• An identification of critical success factors - what the project needs tofulfill.

• Meetings to negotiate the conditions of the project.

• A hearing4 of all involved actors on the basis of the final (or draft) projectcharter.

• Project planning and writing or negotiating the project charter, which is thebasis for the steering committee’s and the design team’s decision about(and commitment to) how to approach the project.

Figure 7 presents an example of project establishment.

The design team started with only IT professionals, so part of our concern was to have theorganization find user representatives. This was taken care of by the deputy manager whoappointed two journalists and a secretary, while the local unions did not intervene. Asteering committee was formed consisting of the deputy manager (chairman), three middlemanagers from the radio channel, and the IT manager. The project team interviewed the ITmanager about IT strategies, and they interviewed the P3 managers about the purpose of theproject and about how the project should be related to corporate and channel strategies. Theproject team read various corporate strategic documents as well. The IT professionalsobserved an editorial unit for a full day and interviewed a producer, a couple of journalists, atechnician, and a secretary. The design team had a one day meeting where the project wasoutlined and a preliminary plan was drawn up. Two of the IT professionals made a draft ofthe project charter, which was then approved by the full design team with minor changes.The team then negotiated the draft with the steering committee. The design team and thesteering committee agreed upon the aim, level of ambition, scope, and conditions of theproject. The final project charter laid down the technological platform (Windows NT forclients and servers) and a package of standard office systems (MS Office). The only majorpoint of disagreement was that the deputy manager didn’t think the three users in the designteam should spend as much time on the project as we had suggested. We settled thisdisagreement by agreeing that the three users spend what corresponds to one full timeperson, while the IT professionals should spend an equivalent of two full time persons. Thisfirst part of the project was in progress over 6 weeks (calendar time), and the design teamspent a total of some 3 person weeks.

Figure 7. Example of project establishment.

4 By a hearing we mean that the involved actors are informed about the given subjectmatter with the possibility of commenting on it.

23

4.2. Strategic AnalysisThe purpose of strategic analysis is to clarify and delimit which work domainsshould be in focus in the design project. This is often rather unclear, even ifthe organization has a business strategy and a related IT strategy (Kensing etal., 1998; Simonsen, 1994, 1996, 1997; Simonsen & Kensing, 1994, 1997).Like project establishment, this too is a reframing process.

In some cases, strategic analysis may be a part of project establishment. If theorganization is unable to define the focus of the design project in an adequateway, or if there are conflicts as to which areas should be given priority, wesuggest that the strategic analysis be handled separately (see Simonsen, 1994,1996, 1997).

The manifest result depends on the degree to which the organization inquestion already has a business strategy and a related IT strategy, and on thedegree to which the involved parts of the organization see the relation betweenthese and the current project. Strategic analysis clarifies the potentials forinvestments in IT support and investigates organizational, economical, andtechnical limitations. It involves development of an understanding of theorganization’s situation in a competitive market, which parts of theorganization need to be strengthened and how this relates to the current pro-ject, identification and analysis of customers and suppliers (internal orexternal), and which products and services the organization should provide.The focus of strategic analysis is on the functional requirements of theenvironment on the organizational units in question (Schmidt, 1988;Simonsen, 1994).

Strategic analysis is primarily a management related activity. For this activity,the MUST method suggests

Interviews of managers; the IT manager, if any; and representative users,customers, and suppliers, as well as observations of key activities.

• Document analysis of (possible) strategic plans, IT strategies, and marketsurveys.

• Functional analysis (Schmidt, 1988; Simonsen, 1994, 1997).

• A hearing of all involved actors organized by the steering committee. Thepurpose is to collect comments for an eventual modification of thestrategic analysis and the project charter. Equally important, such ahearing ensures that all actors involved are informed about the objectivesof the third activity: in-depth analysis of selected work domains.

24

Strategic analysis leads to a decision situation, whereby it is decided whichwork domains should be further analyzed and subsequently supported by IT.Figure 8 presents an example of strategic analysis.In the P3 project the strategic analysis was carried out in parallel with the establishment ofthe project. In addition to what is reported above, we read the CEO’s strategic plans, theRadio’s IT strategy, and surveys of listener behavior. However, during the in-depth analysisof P3 (see Figure 9) we learned that another IT department at the Radio was running asimilar project for the regional stations. This project had a different perspective and rationalethan the P3 project. Since this had not been brought to the P3 design team’s attentionduring the strategic analysis, we found it necessary to arrange meetings with the regionaldesign team to learn more about them and their projects and to coordinate between theprojects. During this process we realized that the two IT managers from each of theirrespective departments were competing with each other. The design teams decided to give uptheir attempt to coordinate. Seen though in retrospect, we should have insisted oncoordinating.The P3 design team also tried to coordinate with the department responsible fororganizational development, since part of our project was to investigate a new division oflabor among journalists, technicians, and administrative staff, which was included in thecorporation’s strategic plans. The organizational development department however declinedour proposal to coordinate, partly because of its involvement in other projects, and partlybecause it wanted the management of P3 to state up front the goals of the reorganization.Instead P3 management and the design team saw it as part of the project to develop visionsof technical and organizational changes in parallel.

Figure 8. Example of strategic analysis.

4.3. In-Depth Analysis of Selected Work DomainsThe work domains pointed out by strategic analysis are in focus when in-depth analyses of current work practices are performed. The purpose of thesein-depth analyses is to reveal and develop an understanding of the rationalebehind current work practices (“users’ present work” in Figure 2). Theintention is not to map old practices into the new computer based system.However, we have experienced that users have good reasons for what they do,and that the rationale underlying current work practices is relevant for thedesign, even if management aims at rather drastic changes (Kensing et al.,1998).

The techniques proposed for developing an understanding of the workpractice, of the use of current systems, and of the use of information are:

• Interviews and observations, where directly affected users at all levels areinvolved.

• Document analysis of documents used in the work practice.

• Thinking aloud experiments.

25

• Mapping (Lanzara & Mathiassen, 1984)

• Future workshops (Kensing, 1987; Kensing & Madsen, 1991)

• Workshops where the design team, perhaps supplemented by additionalusers, makes rich pictures (Checkland & Scholes, 1990), collages (K.Bødker & Kensing, 1994), or wall graphs of current work practices(Simonsen, 1994; Simonsen & Kensing, 1994, 1997).

IT professionals might need to make preparations for these activities andsubsequently carry out, for example, modeling communicative structures(Kensing & Winograd, 1991) or cultural analysis (K. Bødker & Pedersen,1991), which then should be reviewed by the design team and affected users.

Even though project establishment and strategic analysis have pointed outspecific work domains, the analysis might lead to a conclusion that otherdomains need to be included in this activity, as well. In which case, the projectcharter is re-negotiated.This main activity was the key focus of the design team during 10 weeks (30 person weeks).We carried out interviews, observations and thinking aloud experiments with one third of theemployees of P3. Most of these were audio recorded, and rough transcripts were approved byeach of the involved before they were condensed into accounts of the practices of the variouscommunities that make up P3: editorial units consisting of a group of journalists,technicians, and administrative personnel; one-person editorial units; middle management;top management; and various support staff. In addition, the design team collected andanalyzed work documents, and a number of the design team’s meetings had the form ofworkshops. At the workshops, additional employees were invited to take part in mappingtheir individual work and its relation to their colleagues’ work. For these sessions, we usedfree hand drawings on large sheets of paper that were attached to the walls. Some drawingsfocused on the communicative structure involved in radio production, others on temporalstructures, yet others on information needed for and created in the process of planning,production, and administrative follow up of radio programs. The design team produced a listof problems and related suggestions for solutions. This enabled the steering committee todecide which areas should be supported and which design ideas should be developed further inthe next main activity.

Figure 9. Example of in-depth analysis of selected work domains.

The results of in-depth analysis are descriptions of the current work organiza-tion; the use of IT; and the related problems, needs, and ideas for IT support.These descriptions are supplemented with an ordered comprehensive list ofproblems, needs, and related ideas for IT support and work organization.Other important results of this analysis are that users come to see their ownwork in the light of others’ work, and IT professionals get to know users’concepts and categories, thus facilitating communication.

26

This leads to the third prototypical decision situation, where the steeringcommittee decides which of the ideas for IT support should be given priority.Additionally we suggest a hearing of all involved actors and suggest that thedesign team collect the actors’ comments for the purpose of an eventualmodification. Figure 9 illustrates an in-depth analysis of selected workdomains.

4.4. Developing Visions for the Overall ChangeThe development of one or more visions for the overall change is the centralactivity in the MUST method. We emphasize that the visions should not onlydeal with the functionality and the user interface of the suggested systems, butthey should also include organizational change and changes in qualificationsneeded by the users (see Principle 5).

Ideas and visions are developed throughout the project, and they are ofteninitiated in the very beginning of the project (Stolterman, 1991, 1992). Theyemerge in nearly all activities conducted in the project, but the purpose of thisactivity is especially to develop ideas and visions and form them into one ormore coherent visions for change.

We suggest

• Visiting “similar” workplaces using new IT facilities.

• Holding future workshops (Kensing, 1987; Kensing & Madsen, 1991).

• Holding design workshops where the design team, perhaps supplementedby affected users, sketches on large sheets of paper the envisioned futurework organization and its relation to new IT facilities.

• Sorting out design ideas - for example, by writing them on self-adhesivenotes and grouping them on a wall.

• Carrying out data modeling.

• Making mock-ups and prototypes.

Again, IT professionals might have to make preparations for these activitiesand subsequently carry out, for example, information modeling and thedevelopment of prototypes.

The result of this activity is a design report, that states the aim of the project,sums up the analyses, and describes the suggested visions. The design reportis supplemented with mock-ups and prototypes of the proposed IT systems.

27

The report holds an evaluation of positive and negative consequences of thesuggested visions, regarding the organization as a whole, consisting of bothorganizational units and communities of users. For this task we suggestscenarios outlining how the work will be carried out when the visions areimplemented (Clausen, 1993; Kensing et al., 1998; Kyng, 1995; Simonsen,1994). Finally, the report includes estimated costs as well as a plan forpurchase or development of IT systems, for technical and organizationalimplementation, and for the education and training of users.The design team spent 10 weeks (30 person weeks) on developing coherent visions ofcomputer support, organizational changes and related needs for new qualifications. The designteam split up in two sub-teams each of which visited a radio station abroad with “state of theart” digital systems. We video-taped central work processes, took notes, and collected writtenmaterial to inform each other. When the two sub-teams arrived back home, they held anumber of design workshops - again using large sheets of paper - to map the relationsbetween envisioned technology and work. At one workshop, we wrote all the needs comingout of the earlier activities, and all the design ideas on post-it notes. Grouping these on awall revealed loose connections that had to be investigated further. For the purpose ofprototyping, and for the subsequent programming, we developed data models on large sheetsof paper, that were put up on the wall. In smaller groups, we then developed prototypes ofthe key subsystems. The prototypes were demonstrated for the whole design team and for thesteering committee. The status of the prototypes did not allow for testing in real worksituations. Finally, the team wrote a report that summed up the needs - they were related tothe design ideas in a schema - and an estimate for their implementation was given. Wedeveloped a scenario of the envisioned new work practices, by giving an example of how aneditorial unit would use the new technology to coordinate among unit members, with othereditorial units, and with the editorial board. Each of the new systems were described in textand with illustrations. The consequences as to costs and as to a new division of labor werespelled out. The report also held a plan for the organizational implementation (for instancethe employees were split up in ten groups for the training, and the equipment would beinstalled during the course) as well as for the technical implementation (for example in whichorder should the various subsystems be developed, which should be developed in-house, andwhich should be outsourced.) The design report was presented to the steering committee andat a hearing for all employees. The report was accepted, and the job of the design team cameto an end. In the course of half a year, the proposed equipment and standard systems werepurchased, the employees received the training, and the development of the organizationalspecific systems started.Since only parts of the proposed design have been implemented, while a tender for theremaining parts has just been sent out, we feel that an evaluation of the successes and failureswill have to wait until all the systems are up and running and the organizationalimplementation has taken place.

Figure 10. Example of developing visions for the overall change.

The design report forms the basis on which the steering committee decideswhich parts of the proposed design should be purchased as generic systems,some of which might have to be customized; which parts need to be developedespecially for the organization; and which parts should be postponed or

28

perhaps rejected. Also, suggested organizational changes and trainingactivities are decided by the committee. We suggest that the steeringcommittee organizes a hearing of all involved actors, thereby collectingcomments for the purpose of an eventual modification of the proposed design.Figure 10 presents an example of developing visions.

4.5. Anchoring the VisionsWe use anchoring as a metaphor (Simonsen, 1994) that moves beyond thedesign/implementation dichotomy. For a vision to materialize, it needs to bedeeply rooted in the organization. Its rationale needs to be understood by

• Management and the steering committee, who decide if it should beimplemented.

• Those who will carry out the technical and organizational implementation -the latter including training activities.

• The users who will have to live with its consequences.

Because the mentioned actors are not all directly involved in developing thevisions, time and resources must be set aside to make it possible for them toget to know the visions. Anchoring the visions is the job of the design teamand the management of the involved parts of the organization. We see thisactivity to be orthogonal to the other four. It should be given attention inproject establishment and in strategic analysis, and both the direct participationof users, as well as the suggested hearings, contribute to the anchoringactivity. The purpose is to prepare for and even start the process oforganizational change while still carrying out analysis and design activities.This guides why and by which means the design team and managementinteract with actors in the organization and maybe also outside contractors. Inthis respect, anchoring the visions is contributing to viewing design as aprocess of change.

A participatory approach to design is the central strategy in obtainingappropriate anchoring of the visions. This includes

• Meetings and workshops including developing, presenting and evaluatingdesign ideas.

• Prototyping.

• Visits to other institutions using potentially relevant IT.

• Demonstration of IT products.

29

• Hearings.

• Scenarios describing envisioned future work practices supported by theproposed designs.

The design report and prototypes cannot convey everything that the designteam learned throughout the project (Naur, 1985). Therefore appropriateanchoring requires that (part of) the design team has to cooperate, at least inan overlapping period of time, with those taking care of technical andorganizational implementation. For IT professionals, this means having a rolesimilar to that of architects. Besides designing a building, the architect is oftenin charge of the overall supervision when the building is being constructed.Figure 11 illustrates an example of anchoring visions.Management wrote about the project in the departments’ newsletters during the designperiod. The design team presented intermediate results to the management team and at thehearings. Since no journalists turned up for the first hearing, the project leader arranged topresent and receive feedback on the work of the design team at regular meetings with eachof the channel’s editorial groups. During the interviews, observations, and thinking aloudexperiments with one third of the employees, time was set aside for the design team todiscuss more freely with the employees the rationale of the project and to listen to theirideas. The design team tried, but failed, to engage the organizational developmentdepartment and those responsible for the training program. Finally, the externalprogrammers that were to develop the organizational specific systems were selected. Theyread the design team’s report, spent one day observing an editorial unit, and the prototypeswere demonstrated for them. Part of the programming done by the external programmerstook place at the IT department at the Radio. In this way, any questions that arose could bemore easily handled.

Figure 11. Example of anchoring the visions.

5. SUMMARYWe have argued for the need of a separate design activity to produce asustainable basis for further development and implementation of IT in anorganizational context. Within the tradition of PD, we have presented aconceptual framework; a coherent method; and suggested techniques,representation tools, and principles of organization for this design activity.Figure 12 summarizes the MUST method’s main activities and theircorresponding decisions.

We have illustrated the MUST method as it was applied in one of the projects,through which the method has been evaluated and modified. Up until now themethod has proven successful, even in design projects linked to job cuts anddrastic changes in work organization. These projects have been carried out orsupervised by the authors. The degree to which the MUST method, without

30

our direct involvement, is a useful resource for IT professionals in their workwith users and managers is currently being tested in three organizations. Weinvite the reader in challenging the method.

Main activity Leads to decisions about

Project establishment Project charter

Strategic analysis Work domains in focus

In-depth analysis ofselected work domains Problems, needs, and ideas for IT-support

Developing visions forthe overall change

Coherent visions for changeEvaluation of consequences

Plans and estimates for implementation

Anchoring the visionsNone

(on going concern related to dissemination andfeedback on project results)

Figure 12. The MUST method’s main activities and corresponding decisions. The designteam carries out all the main activities involving users and management as needed, herebyproducing the basis for the steering committee’s decisions.

NOTESBackground. This is a significantly revised and expanded version of a paperthat was presented at the PDC’96-conference (Kensing, Simonsen, & Bødker,1996).

Finn Kensing, Jesper Simonsen, and Keld Bødker are associate professorsin Computer Science at Roskilde University. They share an interest in theresearch areas of participatory design, computer supported cooperative work,and human computer interaction.

HCI Editorial Record. First manuscript received July 11, 1997. Revisionreceived April 6, 1998. Accepted by Terry Winograd. - Editor

REFERENCESAndersen, N. E., Kensing, F., Lundin, J., Mathiassen, L., Munk-Madsen, A.,

Rasbech, M., & Sørgaard, P. (1990). Professional systems development:Experience, ideas and action. Englewood Cliffs, NJ: Prentice-Hall.

31

Bansler, J. & Havn, E. (1994). Information systems development with genericsystems. Proceedings of the Second Conference on Information Systems,707-715. Breukelen, The Netherlands: Nijenrode University Press.

Blomberg, J., Giacomi, J., Mosher, A., & Swenton-Hall, P. (1993).Ethnographic field methods and their relation to design. In D. Schuler &A. Namioka (Eds.), Participatory design: Principles and practices (pp.123-155). Hillsdale, NJ: Lawrence Erlbaum Associates, Inc.

Blomberg, J., Suchman, L., & Trigg, R. (1996). Reflections on a work-oriented design project. Human-Computer Interaction, 11, 237-265.

Boehm, B. (1981). Software engineering economics. Englewood Cliffs, NJ:Prentice-Hall.

Bullen, C. V., & Bennett, J. L. (1990). Learning from user experience withgroupware. Proceedings of the Conference on Computer-SupportedCooperative Work, 291-302. New York: ACM.

Bødker, K. (1990). A cultural perspective on organizations applied to analysisand design of information systems. In G. Bjerknes, B. Dahlbom, L.Mathiassen, J. Stage, K. Thoresen, P. Vendelbo, & I. Aaen (Eds.),Organizational competence in systems development. A Scandinaviancontribution (pp. 211-232). Lund, Sweden: Studentlitteratur.

Bødker, K. & Kensing, F. (1994). Design in an organizational context: anexperiment. Scandinavian Journal of Information Systems, 6(1), 47-68.

Bødker, K., & Strandgaard Pedersen, J. (1991). Workplace cultures: Lookingat artifacts, symbols, and practices. In J. Greenbaum, & M. Kyng (Eds.),Design at work: Cooperative design of computer systems. (pp. 121-136).Hillsdale, NJ: Lawrence Erlbaum Associates, Inc.

Bødker, S. (1996). Creating conditions for participation: Conflicts andresources in systems design. Human-Computer Interaction, 11, 215-236.

Carstensen, P. (1996). Computer supported coordination. Unpublisheddoctoral dissertation, Department of Computer Science, RoskildeUniversity, Denmark.

Cash, J.I., McFarlan, F.W., & McKenney, J.L. (1992). Corporateinformation systems management. Homewood, IL: Business One Irwin.

Checkland, P., & Scholes, J. (1990). Soft systems methodology in action.Chichester, England: West Sussex.

32

Christensen, S., & Molin, J. (1983). Organisationskulturer - kultur og myter,deltagerstyring, ledelse og omstilling, viden og erfaring, design,[Organizational cultures - Culture and myths, participatory government,management and change-over, knowledge and experience, design].Copenhagen, Denmark: Akademisk Forlag.

Clausen, H. (1993). Narratives as tools for the systems designer. DesignStudies, 14, 283-298.

Coad, P., & Yourdon, E. (1991). Object-oriented analysis. Englewood Cliffs,NJ: Yourdon Press.

Dahlbom, B., & Mathiassen, L. (1993). Computers in context. Thephilosophy and practice of systems design. Oxford, England: Blackwell.

Earl, M. J. (1993). Experiences in strategic information systems planning.MIS Quarterly, 17(1), 1-24.

Ehn, P. (1988). Work-oriented design of computer artifacts. Stockholm,Sweden: Arbetslivcentrum.

Ehn, P., Meggerle, T., Steen, O., & Svedemar, M. (1997). What kind of car isthis sales support system? On styles, artifacts and quality-in-use. In M.Kyng & L. Mathiassen (Eds.), Computers and design in context (pp. 111-143). Cambridge, MA: MIT Press.

Ehn, P., & Sandberg, Å. (1979). Företagsstyring och löntagermakt.Planering, datorer, organisation och fackligt utredningsarbete[Management and employee power. Planning, computers, organization andunion investigation]. Stockholm, Sweden: Prisma.

Freedman, D. P., & Weinberg, G. M. (1982). Handbook of walkthroughs,inspections and technical reviews. Boston, MA: Little, Brown.

Gougen, J.A., & Linde, C. (1993). Techniques for requirements elicitation.Proceedings of the IEEE International Symposium on RequirementsEngineering, 152-164. Los Alamitos, CA: IEEE Press.

Greenbaum, J. (1993). PD: A personal statement. Communications of theACM, 36(4), 47.

Greenbaum, J., & Kyng, M. (Eds.) (1991). Design at work: Cooperativedesign of computer systems. Hillsdale, NJ: Lawrence Erlbaum Associates,Inc.

33

Grudin, J. (1991). Interactive systems: Bridging the gaps between developersand users. IEEE Computer, 24(4), 59-69.

Grønbæk, K., Kyng, M., & Mogensen, P. (1993). CSCW challenges:Cooperative design in engineering projects. Communications of the ACM,36(4), 67-77.

Grønbæk, K., Kyng, M., & Mogensen, P. (1997). Toward a cooperativeexperimental system development approach. In M. Kyng & L. Mathiassen(Eds.), Computers in context, (pp. 201-238). Cambridge, MA: MIT Press.

Hammer, M., & Champy, J. (1993). Reengineering the corporation: Amanifesto for business revolution. London: Nicholas Brealey.

Henderson, J. C., & Sifonis, J. G. (1988). The Value of strategic IS planning:Understanding consistency, validity, and IS markets. MIS Quarterly, 12,187-200.

Henderson, J. C., & Venkatraman, N. (1992). Strategic alignment: A modelfor organizational transformation through information technology. In T. A.Kochan & M. Useem (Eds.), Transforming Organizations (pp. 97-117).New York: Oxford.

Hughes, J. A., Randall, D., & Shapiro, D. (1992). Faltering from ethnographyto design. Proceedings of the Conference on Computer SupportedCooperative Work, 115-122. New York: ACM.

Hughes, J. A., Randall, D., & Shapiro, D. (1993). From ethnographic recordto system design: Some experiences from the field. Computer SupportedCooperative Work (CSCW): An International Journal, 1(3), 123-141.

Keen, P. G. W. (1991). Shaping the future: Business design throughinformation technology. Boston: Harvard Business School Press.

Kensing, F. (1987). Generation of visions in systems development: Asupplement to the toolbox. In P. Docherty, K. Fuchs-Kittowski, P. Kolm,& L. Mathiassen (Eds.), Systems design for human development andproductivity: Participation and beyond, (pp. 285-301). The Netherlands:Elsevier.

Kensing, F., Bødker, K., & Simonsen, J. (1994). An emerging approach tosystems design: Experience from the MUST program (Datalogiskeskrifter No. 94). Roskilde, Denmark: Roskilde University.

34

Kensing, F., & Madsen, K.H. (1991). Generating visions: Future workshopsand metaphorical design. In J. Greenbaum & M. Kyng (Eds.), Design atwork: Cooperative design of computer systems, (pp. 155-168). Hillsdale,NJ: Lawrence Erlbaum Associates, Inc.

Kensing, F., & Munk-Madsen, A. (1993). Participatory design: Structure inthe toolbox. Communications of the ACM 36(4), 78-85.

Kensing, F., Simonsen, J., & Bødker, K. (1996). MUST – A method forparticipatory design. Proceedings of the Fourth Biennal Conference onParticipatory Design, 129-140. Palo Alto, CA: Computer Professionalsfor Social Responsibility

Kensing, F., Simonsen, J., & Bødker, K. (1998). Participatory design at aradio station. CSCW: The Journal of Collaborative Computing,7(3-4),243-271.

Kensing, F., & Winograd, T. (1991). Operationalizing the language/action ap-proach to design of computer-support for cooperative work. In R. K.Stamper, P. Kerola, R. Lee, & K. Lyytinen (Eds.), Collaborative work,social communications and information systems, (pp. 311-331).Amsterdam, The Netherlands: North-Holland.

Kyng, M. (1995). Making representations work. Communications of theACM, 38(9), 46-55.

Kyng, M., & Mathiassen, L. (1982). Systems development and trade unionactivities: Information society for richer, for poorer, (pp. 247-260).Amsterdam, The Netherlands: North-Holland.

Lanzara, G. F. (1983). The design process: Frames, metaphors, and games. InK. Briefs, C. Ciborra, & L. Sneider (Eds.), System design for, with, and bythe users, (pp. 29-40). Amsterdam, The Netherlands: North-Holland.

Lanzara, G. F., & Mathiassen, L. (1984) Mapping situations within a systemdevelopment project: An intervention perspective on organizationalchange (MARS-report No. 6, DAIMI PB-179). Aarhus, Denmark:Computer Science Department, Aarhus University.

Lederer, A. L., & Sethi, V. (1991). Critical dimensions of strategicinformation systems planning. Decision Sciences, 22, 104-119.

Lyytinen, K., & Hirschheim, R. (1987). Information systems failures: Asurvey and classification of the empirical literature. Oxford Surveys inInformation Technology, 4, 257-309.

35

Mathiassen, L. (1981). Systemudvikling og systemudviklingsmetode, [Systemdevelopment and system development method] (DUE-Report No. 5,DAIMI PB-136). Aarhus, Denmark: Datalogisk Afdeling, MatematiskInstitut

Mogensen, P. H. (1992). Towards a provotyping approach in systemsdevelopment. Scandinavian Journal of Information Systems, 4, 31-53.

Mumford, E. (1972). Job satisfaction: A method of analysis. PersonnelReview, 1(3).

Mumford, E. (1993). The ETHICS approach. Communications of the ACM,36(4), 82.

Mumford, E., Land, F., & Hawgood, J. (1978). A participative approach to thedesign of computer systems. Impact of Science on Sociology, 28(3), 235-253.

Naur, P. (1985). Programming as theory building. Microprocessing andMicroprogramming, 15, 253-261.

Nygaard, K. (1975). Kunnskapsstrategi for fagbevegelsen [Knowledgestrategy for the trade union]. Tidsskrift för Universitets- ochForskningspolitik. Nordisk Forum 6, 10(2), 15-27.

Orlikowski, W. J. (1992). Learning from notes: Organizational issues ingroupware implementation. Proceedings of the Conference on Computer-Supported Cooperative Work, 362-369. New York: ACM.

Plowman, L., Rogers, Y., & Ramage, M. (1995). What are workplace studiesfor? Proceedings of the Fourth European Conference on Computer-Supported Cooperative Work, 309-324. Dordrecht, The Netherlands:Kluwer.

Premkumar, G., & King, W. R. (1994). Organizational characteristics andinformation system planning: An empirical study. Information SystemResearch, 5(2), 75-109.

Rasmussen, J., Mark Pejtersen, A., & Goodstein, L. P. (1994). Cognitivesystems engineering. New York: Wiley.

Sachs, P. (1995). Transforming work: Collaboration, learning and design.Communications of the ACM, 38(9), 36-44.

36

Schmidt, K. (1988). Function analysis instrument. In G. Schäfer & R.Hirschheim (Eds.), Functional analysis of office requirements: Amultiperspective approach, (pp. 261-289). Chichester, England: Wiley.

Schmidt, K. (1990). Analysis of cooperative work. A conceptual framework(Risø-M-2890). Roskilde, Denmark: Risø National Laboratory.

Schön, D. A. (1983). The reflective practitioner: How professionals think inaction. New York: Basic Books.

Schön, D. A. (1992). Designing as reflective conversation with the materialsof a design situation. Knowledge-Based Systems, 5(1), 3-14.

Shapiro, D. (1994). The limits of ethnography: Combining social sciences forCSCW. Proceedings of the Conference on Computer SupportedCooperative Work, 417-428. New York: ACM.

Simonsen, J. (1994). Designing systems in an organizational context: Anexplorative study of theoretical, methodological, and organizationalissues from action research in three design projects (Datalogiske skrifterNo. 52). Unpublished doctoral dissertation, Roskilde University, Roskilde,Denmark..

Simonsen, J. (1996). Involving customer relations in contextual design: ACase Study. Proceedings of the 4th European Conference on InformationSystems, 1153-1161. Lisbon, Portugal.

Simonsen, J. (1997). Linking design to business strategy through functionalanalysis. Proceedings of the 5th European Conference on InformationSystems, 1314-1327. Cork, Ireland: Cork Publishing Limited.

Simonsen, J., & Kensing, F. (1994). Take users seriously, but take a deeperlook: Organizational and technical effects from designing with anethnographically inspired approach. Proceedings of the Third BiennialConference on Participatory Design, 47-58. Palo Alto, CA: ComputerProfessionals for Social Responsibility.

Simonsen, J., & Kensing, F. (1997). Using ethnography in contextual design.Communication of the ACM, 40(7), 82-88.

Simonsen, J., & Kensing, F. (1998). Make room for ethnography in design!The Journal of Computer Documentation, 22(1), 20-30.

Stolterman, E. (1991). Designarbetes dolda Rationalitet. En studie av metodikoch praktik inom systemutvekling. [The hidden rationale of design work -

37

A study in the methodology and practice of system development] (No.14.91). Unpublished doctoral dissertation, Institutionene forInformationsbehandling, Administrativ databehandling, Umeå Universitet.

Stolterman, E. (1992). How systems designers think about design andmethods: Some reflections based on an interview study. ScandinavianJournal of Information Systems, 4, 137-150.

Suchman, L. (1995). Making work visible. Communications of the ACM,38(9), 56-64.

Winograd, T., & Flores, F. (1986). Understanding computers and cognition,A new foundation for design. Reading, MA: Addison-Wesley.

Yetton, P. W., Craig, J. F., & Johnston, K. D. (1995). Fit, simplicity and risk:Multiple paths to strategic IT change. Proceedings of the SixteenthInternational Conference on Information Systems (ICIS’95), 1-11. TheNetherlands.

Yourdon, E. (1989). Modern structured analysis. Englewood Cliffs, NJ:Prentice Hall.