Mutual learning

Enabling cooperation on systems design

Tone Bratteteig
Department of Informatics
University of Oslo

pp. 1-20 in Braa & Monteiro (eds): Proceedings of IRIS'20, Dept. of Informatics, University of Oslo, 1997


Mutual learning between users and designers is an important part of participatory systems design. Examples from a mutual learning process are used to discuss problems that highlight important principles for mutual learning. The process of mutual learning benefits from being based on theories about learning and teaching, in particular principles of problem oriented pedagogy.

Keywords: user participation, learning, problem oriented pedagogy

1. Introduction

Mutual learning is an important part of participatory design. Mutual learning means that users and designer learn from each other during the design process, and both qualify themselves with respect to the systems development process they are involved in. Systems design includes to understand and to create: the way we understand a phenomenon influences the way we give form to it, and vice versa. The understanding part of design is "fed" by learning processes during design and before the actual design takes place. Mutual learning is important when different categories of people participate in the design process, typically users and informaticians. The mutual learning typically deals with knowledge about the application area and the work that the future computer system is supposed to support, as well as technology and possible applications of new technology.

My first experience of mutual learning was in the Florence project (1983-87). The notion was used to denote the first phase of the project (described in section 1.2). The Florence experience summarises to: mutual learning is difficult and hard work, but that it is possible to succeed—success implies better design of the computer based system. However, many of the essential characteristics of mutual learning are difficult to understand, and sometimes very hard to accomplish.

In this article I describe and discuss important characteristics of mutual learning in terms of theories of learning and teaching. The aim is to arrive at a set of concepts that can be used for planning and carrying out, teaching and communicating about mutual learning. I have chosen to base the discussion on a concrete example of a mutual learning process, and have structured the discussion by problems and challenges experienced during the process. I have selected problems that seemed to be important to the success of mutual learning in the Florence project.

This section continues with a brief overview of the Florence project, and I end with presenting a list of six problems to be discussed in the rest of the paper. The next six sections discuss these problems. Section 8 discusses tools and techniques for mutual learning. Section 9 discusses planning of mutual learning processes, and section 10 concludes the article.

1.1 An example of a mutual learning process: the Florence project

The Florence project was an interdisciplinary research project initiated by the Department of Informatics, University if Oslo, aimed at developing techniques for user participation in system development [Bjerknes et al, 85; Bjerknes & Bratteteig, 87a]. Four informaticians, one social anthropologist, one nurse and a secretary was working in the project. The project chose nurses as a user group for several reasons: Nursing is a profession, nurses interact with other professions, nursing is female dominated, reproduction aspects like giving service and information are important, and the profession involves an interesting mix of manual and knowledge based work. The research strategy was based on the view that research on system development techniques requires an action-oriented approach in which actual system development is carried out [Bjerknes & Bratteteig, 95]. The research goals of the project were concerned with developing and testing techniques for user participation in system development, and to investigate the idea that profession oriented languages would be helpful in systems development within a professional setting. The goal for the development side of the project was to build a computer system for nurses' daily work, based on their professional language and skills.

The project was carried out as a collaboration between the researchers at the University of Oslo and two different hospital wards:

a ward for asthmatic and allergic children at the National Hospital (Asthma ward), 1983-1985

a ward for cardiology at a Regional Hospital outside Oslo (Cardiology ward), 1986-1987

The same process of mutual learning and collaborative design was carried out in both wards, at a different speed. The mutual learning included activities under the labels field work (interviews, observations), system descriptions (means for discussion, specifications), system presentations (excursions, demonstrations), and teaching (lectures-on-demand, planning, evaluating). The techniques are discussed in detail in section 8.


1.2 Problems and challenges in the mutual learning process

In planning the process of mutual learning in the Florence project we used our knowledge about teaching as well as systems development techniques. The process gave us some interesting surprises—for good and bad—, and this article aims to explain these experiences.

2. Nurses don't do what they say that they do

Observations and interviews with nurses in work revealed that there are interesting differences between formal routines and what people actually do in order to get the work done [Bjerknes & Bratteteig, 87a]. A couple of situations from the Florence project can be used to illustrate this.

At the Asthma ward, I was sitting as an observer in the ward office trying to get a picture of the information flow and information processing in the ward [Bjerknes et al, 85]. The traffic varied a lot: some chaotic periods with several people present in the room all exchanging messages, some quiet periods with only one person around, writing or using the telephone. After every hectic period, the nurse who was on duty in the room said to me: "I hope that you don't write this down, this is not how we normally do things." or "... this is not how we should do things." An example would be to make a decision to change the medicine to a smaller dose to be distributed in the morning round before the daily meeting with the responsible medical doctor. The discussion with the doctor was important for the legal responsibility for the decision, but experienced nurses knew enough about the typical development of allergies—and knew the actual child from observations during the last night and day—to know the outcome of the discussion.

At the Cardiology ward, there is a strict division of responsibilities between medical doctors, nurses and nursing assistants. The ward has a high status in the hospital, and the nurses are technically competent. In our observations of the work at the ward, we saw several examples of nurses educating medical doctors in cases where the doctor lacked knowledge (first year doctors or visiting anaesthetics doctors), but without breaking the rules of the formal hierarchy: emphasising the high quantity of "CK enzymes" that indicates a large infarct of the heart, or discussing the combination of medicine X with medicine Y as possibly disadvantageous for some patients.

Nurses don't do what they say that they do. The Asthma ward story also refers to their experience of being watched by us, but the main point is that the formal routines of work are made for a number of purposes (legal, administrative) that may conflict with the values in work, eg, the purpose of giving the best care in the situation. Many nurses rely on their practical knowledge in such situations, and use the formal procedures to legitimate their actions in an after-the-fact manner. The Cardiology ward story tells that the nurses role as an information "processor" is essential: even if the nurses complained that they had no time for "real nursing", ie, sitting by the bedside, we observed that the "real" nurses did professional administration of information and resources in order to secure that all and every patient got the best possible care.

2.1 Work practice tells more about work than standard routines

In the Florence project we chose to emphasise practice at the expense of formal routines: what people do is more important than what they say that they do. One important consequence from this view is to see administration of the ward as a part of nursing rather than an addition to it: administration of information and resources are done on a professional basis. The pilot system built at the Cardiology ward supports this kind of administration [Bjerknes & Bratteteig, 87a; 88a].

The focus on practice also implies acknowledgement of the tacit knowledge involved in the work. Tacit knowledge [Göranzon, 84] refers to practical knowledge, or skills, acquired through experience. Tacit knowledge is typically not explicit—or even explicable. The development of tacit knowledge happens through experience: years of observing asthmatic children gives you a feeling for how they normally develop and how a particular medicine dose affect the illness. Through experience the nurse develops a theory: a "theory-of-practice" [Handal & Lauvås, 83] or theory-in-use [Schön, 91]. The theory-of-practice differs from espoused theories, but can be based on a general theory which is modified through reflection and knowledge from practice. The experienced nurse make explicit parts of her/his knowledge in explaining a case: the explanatory power of a theory can only be shown by referring to a situation [Lave & Wenger, 91]. Work is always situated, and rather than being rules to be followed routines are abstractions of activities which can support people in deciding how to act in a particular situation (cf. eg. [Suchman, 83; 87; Suchman & Wynn, 84]).

The stories from the Florence project also suggests that work includes more than what is visible, and nurses in particular carry out a lot of articulation work to get the ward running [Strauss, 85; Strauss et al, 85; Star 91]. Articulation work is exemplified in the information processing involved in the handling of changing medication for a child, or the work of making sure that the medical doctor realises the seriousness of the infarct when deciding further treatment. Work also includes extra work because of inadequate equipment or routines, like the medication taking place before the morning meeting at the Asthma ward, or the need to know the EKG equipment in order to interpret correctly the heart beat curve on the screen (cf, eg, [Gasser, 86]).

Work practice tells more about work than standard routines, because standard routines are used as resources for acting in a situation. The experience from Florence was that explanations for the way work was carried out gave information about the basic principles and values in nursing, and thus had greater explanatory power than the routine descriptions could have. The next section explains why we appreciated this kind of knowledge.

3. Our nurses refused our prototype

At the end of the first phase of the Florence project, two prototypes were built. One departed from the nursing journal: the Kardex—an important document which contains information about all the patients present in the ward. The other prototype was a simple collection of text files that constituted an electronic version of the Procedure book: a cover in which sheets of paper describing the procedures to follow in acute cases was put. The nurses were happy for the Procedure book, but refused the Kardex system [Bjerknes & Bratteteig, 87a; 87b].

At the end of the period of mutual learning at the Asthma ward we divided into two teams, and decided that each team would build a prototype. The decision processes in the two teams differed. In one of the teams, the nurses suggested to digitise the Procedure book, and the group decided to do so. They immediately started teaching two of the nurses to use the text processor. The nurses were happy to update the Procedure book, and to get rid of the many versions of procedures included in the cover.

The other team decided differently. The informaticians wanted to digitise the most used document in the ward: the Kardex. Even if the nurses said that they just had finished a long redesign of their paper based Kardex, the Kardex was chosen. The Kardex consists of a main card which includes all facts about the patient, and a set of observation sheets that 1) describe problems or diagnoses, and for each problem: 2) list actions to be taken to improve the problem, and: 3) list observations of the patient's development (in blue, green, and red colour for day, evening, and night shifts) [Bjerknes & Bratteteig, 87b]. The technology we had at our disposal was a NORD machine with a line-oriented terminal to it. A simple application generator was used to design the screen layout. The limits of the technology created severe problems for the design:

The nurses did not like the system for professional reasons. The main argument was that the system did not offer the overview necessary for them to carry out their work. One example was the field "allergies" that we happened to locate in the second screen: the field was rarely filled in, and not at all in the Kardex records we had looked through. The allergies field tells if the patient is allergic to medicines—very important knowledge in emergency cases. The lack of data in this field is actually vital information. Similar critique was put forward for the messy presentation of problems, actions, and observations: the screen could not provide an overview of all the problems defined for a patient without browsing through many screens. The different styles that should compensate for the lack of colours did not highlight the night shift observations which was considered the most important for indicating the patient's condition (usually written in red). A quick glance in the paper based Kardex gave such an overview.

Our nurses refused our prototype, and when told we immediately understood their reasoning. We concluded that the experience was an important part of our learning: after this we felt that we knew enough about nursing (at this ward) to be able to cooperate about designing a computer system. We had learnt that nurses reason differently from informaticians, and that although we could understand the reasoning when told, we probably were not able to apply it on new situations.

3.1 A willingness to listen

Mutual learning is based on a willingness to listen—but the ability to listen is based on knowledge. The recognition of one's own limitations is one important prerequisite for opening up for a different perspective, the acknowledgement of other kinds of knowledge is another. Both were present in the Kardex case.

Acknowledgement of nurses' way of reasoning implies a recognition that informaticians reason differently from nurses, and that there is no need to try to become a nurse in order to design nursing based computer systems. Computer systems are based on routines, on generalised knowledge, on choices that increase efficiency etc. Nurses think differently: they relate to situations and individual patients and refuse to talk about what is "normal". Procedures are checklists. Informaticians emphasis on efficiency isn't always appropriate, eg, the copying of a sheet to another may just also be an important process of control or information distribution maintaining a community of practice.

The Kardex case also illustrates a dilemma in participatory design, the difficulties concerned with legitimating informaticians' interests. The choice of the Kardex system was based on what the informaticians considered interesting to do, not what the nurses considered useful. There is often a conflict between technically challenging systems and the users' needs for something simple but useful [Bjerknes & Bratteteig, 88b; Thoresen, 89].

The Kardex case provided knowledge that was needed in order for us to open up for listening to the nurses. The decision process leading to the design in the second phase of the Florence project (cf, sections 6 and 7) was therefore very different. One of the difficult questions in a mutual learning process is what are we to learn about each other, and when do we know enough? Uneven distribution of knowledge about the application area is considered to be a problem in systems development [Curtis et al, 88; Walz et al, 93]. Learning has to happen both within and between the professional groups involved in the design. The willingness to listen to and respect a different voice is an important characteristic of participatory design.

4. Nurses' acknowledgement of informaticians

Cooperation and mutual learning is based on—and produces—mutual respect for each other's professional competence. The balance between being an expert in some questions and novice in other cases is difficult. The fact that the expertise of one group or person probably fits with the ignorance of other groups/persons adds to the problem: differences in resources (mental or physical) may be used as a basis for exercising power [Bråten, 73]. Differences between traditions and cultures can make mutuality difficult to achieve.

A two day seminar was included in the mutual learning phase after an initial period of field work and teaching [Bjerknes et al, 85‚ Bjerknes & Bratteteig, 87a]. The seminar included testing and discussions of prototypes that demonstrated particular technological solutions, as well as system description activities aimed at discussing the work in the ward, the organisation of work, and the information processing parts of work. For the seminar two Master students had built three prototypes in order to show various ways of presenting nursing information [Einarsrud & Granholm, 86]. The prototypes were very simple, they were not finished, and they were deliberately designed with errors. The nurses immediately engaged in discussing the concrete prototypes, criticising the solutions and suggesting improvements.

The second day was used for system description. The aim of the system description activities was discussion rather than specification, thus we chose a simple description technique: Wall-graph, and allowed the nurses to feel free to modify the technique and the symbols and description language along the way. A wall-graph is a big sheet of paper hanging on the wall, used as a background for drawing information sources (like forms and notes) and information flow happens in the organisation (cf, eg, [Bjerknes et al, 85]). The technique is very concrete: the forms are reduced scale copies of the real forms, thus it is easy to involve the users in the drawing. In addition, we let the nurses use the symbols in their own way or invent new, "home-made symbols" if they wanted [Bjerknes & Bratteteig, 87c; Munk-Madsen, 78]. The system description activities became an opportunity for the nurses to observe nursing from the outside, encouraging discussions about the information processing at the hospital as a whole as well as at the ward. The system descriptions demonstrated an informatics perspective to the nurses.

The three system description groups behaved very differently. The point here is the experience of the two students of informatics (the prototype builders) who were chairing a group together with the nurse employed in the Florence project. They experienced not to be respected: they were not considered knowledgeable, and their attempts to chair the activity was undermined by the group. They were very frustrated!

Nurses' acknowledgement of informaticians is one side of the mutual learning that we did not expect any trouble with: we were more concerned with being met with too much respect. The students' frustrating experience fitted with other experiences where the nurses took for granted that informaticians also acted as technical service staff for all sorts of equipment when needed.

4.1 Mutual respect

An important part of the learning about other disciplines is to make a basis for mutual respect and acknowledgement of each other as participants who contribute to the design process. Mutual respect is necessary in order to share responsibilities and benefits—it is necessary in order to enable participation.

But mutual respect is based on knowledge about each other. One of the difficult parts of cooperation with non-informaticians is that the process of building a computer system is not visible for non-professionals [Bjerknes & Bratteteig, 88a]. The nurses were not able to appreciate the skills involved in the mutual learning activities (prototyping, system description, teaching). An informatician who shows an open attitude towards the users is at risk for being less respected than a technician showing technical skills—who may limit the communication with the users both with respect to breadth and depth because of his/her expert role.

The hospital is a very hierarchical organisation—our group at the university was less so. The strong hierarchy between medical doctors, nurses, and nursing assistants framed the way we were addressed. We needed to "bring a professor along" when negotiating a contract of rights and duties with the hospital management. The hospital culture influenced the communication in the project through expectations and prejudices, and through our images of "the others".

5. Our nurses were responsible for training

Mutual respect is a prerequisite for sharing responsibility in the systems development process. Taking responsibility involves both rights and duties, in particular the right to carry out the task in one's own way.

At the end of the last programming period at the Cardiology ward, we planned the introduction and training of the Work Sheet system (described in sections 6 and 7) with the nurses. The five nurses who had participated in the project team were educated by us, and a couple of them also joined a text processing course at the vendor (Norsk Data). The nurses got and took the responsibility to plan and carry out the training of the rest of the staff at the ward, and we agreed on a date for introducing the system.

The training program consisted of a number of minor tasks that should enable the users to login and find a file, to create, edit, and print a text document, and to use the Work Sheet system. The training exercises were fairly small, and the plan was to encourage their colleagues to do a couple of exercises in the quiet periods during night shift. The nurses at the Cardiology ward were organised in small groups of three, and the groups were expected to make some advance in the training program. One group of older nurses and nursing assistants did not participate in the training program, and thus did not use the system.

The introduction of the system was smooth. The Florence nurses were responsible for input of data in the start period, and the rest of the nurses got the sheets provided by the Work Sheet system to use. The sheets were used during shift report meetings, and during the work hours. The group of non-users made a hand-made sheet similar to the report from the system when they were responsible for preparing for the shift report meeting. Being small and local, and with only local data, the flexibility of the system use made it possible to live with a small number of non-users.

Our nurses were responsible for training and utilised their knowledge about the organisation: they suggested that most parts of the training was carried out during night shifts. They arranged for flexible use of the system, allowing their colleagues to train at their own speed—or not at all.

5.1 Distribution of responsibility means distribution of power

The Florence project members shared rights and duties in the project to a certain degree. The nurses were responsible for introducing the Work Sheet system in the Cardiology ward, including training their colleagues in using the system. The introduction was smooth and utilised characteristics of the work organisation that we did not think of.

Giving responsibility includes giving away power and control. In this case we were surprised and positive to the arrangement that the nurses arrived at. It is, however, not difficult to imagine situations in which a different way of conducting a task can cause conflicts.

6. Our nurses designed the pilot system

Mutual learning means sharing knowledge about the disciplines involved in the development process. The idea is to share knowledge that explains the basic principles and values in the work, not educating in the discipline [Bjerknes et al, 85]. This seems reasonable when informaticians learn about nursing, but what about nurses learning about informatics? What do they need to know?

Parts of the process leading to the design suggestion from the nurses at the Cardiology ward has been described above: a process of mutual learning at the Asthma ward, programming of two prototypes, one successful and one not (cf. section 3), and another process of mutual learning at the Cardiology ward. At the end of this period, the group of nurses and the informaticians involved in the Florence activities each suggested a list of computer systems they would like to have, and the idea was to meet and negotiate which one to decide on [Bjerknes & Bratteteig, 88a]. Of course, several ideas for systems had been mentioned and discussed in informal ways during the months of mutual learning, but the lists with priorities were supposed to express commitments of the groups.

We were quite curious when we arrived at the negotiation meeting because we had decided not to repeat the Kardex failure: We decided to be very open to suggestions from the nurses, but with a possible veto for really uninteresting ones. However, the nurses had the Work Sheet system as their first priority, and we accepted to build it.

The Work Sheet system is a simple system basically showing a geographical map of the ward (half of the ward at each page, corresponding to each of the teams). The "bed objects" are filled with patient information, and the "ward office object" is filled with administrative information (distribution of tasks and duties between the present staff). The screen layout is similar to the paper report layout. The idea was that it would be simple to move a patient from one bed to another (eg, from a acute bed to a recovery bed) by moving the patient object to another location on the screen. The screen was only to be used for updating and making reports, the paper reports were to be used as scraps for individual nurses in work and group communication. This design was sketched on a paper, and we could all imagine a system producing such reports (and screen layouts).

The design was not simple to program, however. The ideas were based on object oriented technology—inspired by the Macintosh prototypes at the seminar (cf, section 4), and the Mac with text processing and games that we lent to the ward during the mutual learning period. The pilot system was to be built on a NORD computer, with line oriented terminal, and with simple application and report generators [Bjerknes & Bratteteig, 87a]. The design did not relate to possible constraints in the technology, and the simple system was surprisingly difficult to realise. We did manage to arrive at an object-oriented solution by utilising weaknesses in the programming tools provided for us. But the process took long, and nurses were disappointed to experience that the prototype they had seen only a week after the design meeting (a text showing the screen layout and the report layout) took so long to build [Bjerknes & Bratteteig, 88a].

Our nurses designed the pilot system. The mutual learning period had provided them with sufficient knowledge about informatics to suggest a design. In fact the nurses had learnt enough about informatics to develop a technological fantasy, and were able to suggest an application that did not replace old systems or paper based systems, but built on the characteristics of computer technology. The Work Sheet system provided a tool for information sharing in the group of nurses, as well as providing individual work spaces. The presentation of information to the group in both written and spoken forms made it possible for the shift report meetings to focus more on education and discussion during the meeting.

6.1 Sharing visions

The sketch describing the design of the Work Sheet System was made by the nurses during a Florence project meeting [Bjerknes & Bratteteig, 87a], but was very well suited for communicating about the system and its functionality. The design was based on a shared vision of the future system, but the vision was understood differently by nurses and informaticians. The key word for the vision was overview—we experienced the importance of overview to nurses at the Asthma ward (cf, section 3). To the nurses overview expressed the basic responsibility in their work, and the purpose of the shift report meetings. To the informaticians the notion of overview was abstract, referring to the purpose of gathering and distribution of information, ie, the purpose of q common information base. The Work Sheet system should contribute to a more efficient way of getting an overview.

The sketch functioned as a shared communication device for talking about the future system: a boundary object [Star, 89]. To the nurses a map offered a better structure of information they needed during their work than the existing information hand-written notes and lists. A paper copy of the map would still preserve the flexibility of paper, the nurses could carry it around and take notes. To the informaticians the map suggested an object-oriented structure and presentation of data. The map of the ward was used as a model for screen and report lay out.

The vision for the Work Sheet System was found in the present situation, but not by analysing the present work tools: the system replaced a number of small, informal note scraps and lists. The system was constructed from both nursing and Informatics knowledge: the aim of the system was to provide overview for the nurses—a basic principle in the nurses' work. The image of the map was used as a way of concretising how the vision could be realised in a computer system. The map was a commonly shared image through which nurses and informaticians could meet and cooperate [Bratteteig & Stolterman, 97].

Interdisciplinary groups, like a project group in which informaticians and professional users participate, experience both combination and conflicts between the disciplines and world views involved. Interdisciplinarity is based on multidisciplinarity [Jantsch, 80]: in multidisciplinary groups there is no intention to create overlap between the single disciplines and their approach to a common problem, while the interdisciplinary group tries to synthesise their efforts and make one approach across the disciplinary borders. The community of practice [Lave & Wenger, 91] developed in an interdisciplinary systems development group meets the challenge to establish a new practice that is also grounded in the original disciplines or professions. The basic idea in interdisciplinarity is that the group is more than the sum of its parts, and that the group activities may lead to new and emergent qualities [Bailey, 84].

7. Our nurses decided on the design

The objective of mutual learning is to enable the future users to participate in design, ie, to do parts of the design. Design of computer systems is not their profession, and their responsibilities should be concerned with designing a work instrument rather than how the instrument is realised (as a computer system). We succeeded in engaging our nurses in the design process in the second part of the Florence project.

Before the meeting (mentioned in section 6, cf, [Bjerknes & Bratteteig, 88a]) we discussed the possibility that the nurses would suggest something that we would find uninteresting to build—a situation that would be difficult because we knew from the Asthma ward that persuading the nurses to accept our priorities was not the way to success. We did not want to repeat the failure of the Kardex system, but we did not want to repeat the success of the Procedure book either (cf, section 3).

The informaticians priorities were based on evaluations concerned with technological quality and challenge. We felt that the suggested design should have a certain technological quality, ie, that the technology should be utilised to support nursing information in a innovative and solid way. A successful Kardex system would have done that, but the Procedure book only involved using the text processing program, ie, no programming at all. One important goal of the project was to demonstrate how computer technology could be used to support a particular profession, which meant both to build new applications based on the profession and to utilise the potentials n the technology. The wish for a technological challenge added to the quality discussions: we wanted the research project to be challenging also in the technical sense: we wanted the programming to be difficult—and to be recognised as such by colleagues and fellow researchers.

The Work Sheet system was high on our list of priorities also, so we accepted to build the system. We, the researchers in the project, gave the nurses the power to suggest and decide on the design.

7.1 Giving away power

Giving away power of the design was difficult for us as researchers and as informaticians. Both roles imply possible differences—and even conflicts—with the ways that nurses evaluate computer systems: nurses like simple and well-functioning systems that everybody can learn. Technical brilliance or utilisation of new technology is of less interest. In the design of the Work Sheet system we expected no possibilities for technical brilliance because the system did not seem very difficult to program. However, it turned out to be difficult to realise the design on the equipment we possessed [Bjerknes & Bratteteig, 87a]. The reason was that the nurses did not think of constraints in the equipment (the material) that would limit what is possible to make.

System development, and in particular the design part of systems development, is the responsibility of informaticians. We are responsible for the technical quality of the system: without technical quality, the use quality will suffer [Bjerknes et al, 91]. Technical quality is also concerned with things like stability, reliability, durability, maintainability—characteristics that is of limited interests to users in the moment of design. Giving away parts of the power to design means giving priorities to other aspects than the technical—or even giving less priorities to technical aspects. The choice is professionally difficult, even if several of the technical issues mentioned depend on users' commitment and knowledge: durability increases if the system is based on stable parts of professional knowledge, reliability depends on the users' ability to operate and trust the system, as well as to maintain and use the information in the system. The decision in the Florence project was not easy, and we were prepared to negotiate on the decision of system—even if the research frame implied that a failure also is interesting as a result. In a real life systems development project, the choice would have been even harder and the technical constraints even worse.

8. Tools & techniques for mutual learning

Mutual learning is difficult and hard work, but it is possible to achieve a shared vision based on professional knowledge from both users and informaticians. The tools and techniques we used to support the mutual learning process were modifications of existing tools and techniques. The following section discusses tools and techniques for mutual learning activities like field work, system descriptions, system presentations, as well as principles from pedagogy used for planning the teaching.

8.1 Field work

The field work included observations and interviews, ie, ethnographic studies of work. We observed and interviewed nurses in the ward, during work hours. We started by following a nurse or a team of nurses for one shift, taking notes and sometimes asking for explanations. Later in the process we also followed the activities in one particular room or a particular document for a day. Or we applied a particular perspective on the observations, eg, information flow or cooperation. The observations were supplemented by spontaneous interviews with the present nurses, and sometimes the nurses gave explanations to activities, utterances, words etc. that needed explanation. The observations were discussed with both nurses and the other researchers, but the analysis of the observations were used mainly by the researchers.

The observations taught us what the nurses do whereas the interviews revealed that they talk about nursing in ways that only partly fits with nursing practice. We carried out interviews with one nurse at a time or a group of nurses. The interviews provided us with information about the professional basis and connections between activities at the ward. We also got explanations for some of the actions and expressions by getting more knowledge about the medical basis for decisions.

Doing field work in two wards helped us recognise aspects of nursing which are candidates for general aspects, and the particular culture and work organisation in a ward, chosen because of characteristics of the patients and the hospital (team organisation in the Cardiology ward due to the fact that a number of the beds were connected to monitoring equipment and a need to be watched).

8.2 System descriptions

Most systems development methods are based on a system description technique. Traditionally, system descriptions are used for describing an application area and prescribing the computer system. As a description technique system descriptions are used for understanding and analysing particular aspects of the application area, and for communicating this understanding to the future users. As a prescription technique system descriptions are used for creating a new system, and for communicating the design to programmers who are to build the system. We used system descriptions as a description technique, as a means for understanding and communicating about nursing and work in hospitals [Bjerknes & Bratteteig, 87c]. Section 4 describes how we used the system description technique Wall-graphs.

We did not use system descriptions as means to analyse the needs of nurses for computer support. Formal descriptions and prescriptions, like procedures, are normally based on routines. Our focus on nurses' work emphasised other aspects of work than routines, and was based on the view that requirements are constructed and negotiated (cf, eg, [Bowers & Pycock, 94]), and that routines and deviations from routines is not a useful way of looking at work (cf, eg, [Suchman, 83]).

8.3 System presentations

In addition to system descriptions, the mutual learning included system presentations (cf, [Bjerg & Nielsen, 78]): presentations of systems and system models instead of descriptions of them. In our case this was done through excursions and demonstrations.

Excursions were visits to other hospitals with particular hospital information systems. The visits were instructive for us because we learnt what nurses thought were important features of their work and of the systems. The excursions gave the nurses concrete knowledge about a variety of computers, and of a variety of computer use.

Three kinds of system demonstrations were used:

The system demonstrations gave the nurses concrete knowledge about computers and computer use, by including several system presentations we wanted to avoid discussions of details of the solutions and to convey to the nurses a range of technological possibilities.

8.4 Teaching

The users also learnt about informatics, delimited to use of technology and technological possibilities. We gave lectures on computers and databases in general, mainly serving the purpose of demystifying informatics. After some time, the nurses asked for lectures on particular topics. It seemed that these "lectures-on-demand" were useful to the nurses. System presentations helped concretise what computers do in hospitals (cf, section 8.3), and system descriptions supported discussions about information processing in nursing and in hospitals in general (cf, section 8.2).

Knowledge about teaching was used for planning and evaluating the mutual learning process. Planning of a learning process involves formulating learning objectives and selecting means to achieve the objectives [Handal & Lauvås, 83]. The pedagogy used is called problem driven teaching [Illeris, 74; Askeland, 97].

8.5 Experiences of mutual learning techniques

The experiences from the mutual learning process in the Florence project also included experiences with tools and techniques aimed at involving users. The experiences can be summarised in three points (cf, the next three paragraphs).

9. Design of learning processes

Design of a mutual learning process can use theories from pedagogy: teaching involves planning a learning process [Handal & Lauvås, 83], ie, an individually based process that takes place in a heterogeneous group of people who form a project team also supposed to deliver a product. The learning objectives may seem unclear and vague, but they can be specified quite a bit without knowledge about the users profession.

9.1 Learning in context

Several critical theories of teaching are based on the idea that instruction is most effective when the students themselves discover the needs for knowledge to explore or solve a problem [Illeris, 74; Dewey, 63; 58]. Some even say that the learning should be situated within a student's own knowledge and world view [Freire, 71].

The teaching principles of learning in context is problem oriented learning. Problem oriented learning is based on the view that learning in connection with solving a given problem is better than trying to cover all knowledge within a field. The activity of the individual in a problem situation contributes to better learning [Askeland, 97; Engeström, 87; Fjuk & Øgrim, 97; Fjuk & Dirckinck-Holmfeld, 96; Grindsted & Olsen, 94]. The problems should of course be selected as good examples for learning. The project is a frame for problem oriented learning.

9.2 Learning by doing

Learning by doing is another way of expressing problem oriented teaching [Dewey, 63]. Learning by doing is what system developers normally do: we learn about an application area while doing systems development.

A learning project is, however, different from a project in work life, eg, by the choices a problem oriented teacher would do in distributing a work task to the group member that do not know the task in order for him/her to learn more.

In the Florence project we learnt about information processing aspects of nursing by doing system descriptions.

9.3 Individuals learn in groups

Project pedagogy emphasises the project as a frame for the individual learning process. The students benefit from having to make explicit and discuss their knowledge [Askeland, 97].

The group is a context for learning [Engeström, 87] and the group processes must be designed to enhance and not hamper the learning processes.

10. Mutual learning for collaborative design

Mutual learning means planning and carrying out a social and individual change process. Mutual learning means that one has to learn and teach as part of system development—in addition to other system development activities. The teaching part has to do with enabling a learning process in a group of (future) users. The planning of this process depends on a minimum of knowledge about these users: their preconditions for learning. The preconditions for learning tell the teacher which level s/he can start teaching, the ambitions and requirements that can be made with respect to the learning objectives. In mutual learning in systems development, these preconditions vary a lot, and some of the "students" do not even want to learn!

Mutual learning as discussed in this article has emphasised a teaching strategy that explain and handle the following challenges:

My experiences from the Florence project are that mutual learning is difficult to achieve, that it is hard work, but that a successful process of mutual learning creates new possibilities for applying computer technology. The simple Work Sheet system from the Cardiology ward is a piece of implemented nursing values that could not be designed by any of the two groups alone—and would not have been acknowledged by the informaticians without a basic knowledge about nursing.


The article has benefited from numerous discussions with Annita Fjuk and Joan Greenbaum about learning in systems development. I am of course also thankful to my fellow participants in the Florence project, in particular Gro Bjerknes, Jens Kaasbøll, and Henrik Sinding-Larsen.


Argyris, Ch. & D. Schön (1974): Theory in Practice—Increasing professional Effectiveness, San Francisco, Jossey-Bass Pub.

Askeland, K. (1987): Prosjekter som strategi for læring (Projects as a strategy for learning), UniPed, vol 18, no 1, pp. 5-23

Bailey, D.B. (1984): A Triaxial Model of the Interdisciplinary Team and Group Process, in Exceptional Children, vol 51 no 1, pp. 17-25

Bjerg, L: & L. Verner Nielsen (1978): Edb-systemer inden for avisproduktion (Computer systems within newspaper production) Master Thesis, DAIMI, University of Aarhus

Bjerknes, G. & T. Bratteteig (1987a): Å implementere en idé—samarbeid og konstruksjon i Florence-prosjektet (Implementing an idea—cooperation and construction in the Florence Project) Florence Report no 3, Department of Informatics, University of Oslo

Bjerknes, G. & T. Bratteteig (1987b): Florence in Wonderland, Bjerknes, Ehn, & Kyng (eds): Computers and Democracy—a Scandinavian Challenge, Avebury, Aldershot, pp. 279-295

Bjerknes, G. & T. Bratteteig (1987c): Perspectives on description tools and techniques in system development, Docherty et al. (eds): System Design for Human Development and Productivity: Participation and Beyond North-Holland, Amsterdam, pp. 319-330

Bjerknes, G. & T. Bratteteig (1988a): The memoirs of two survivors—or evaluation of a computer system for cooperative work, Proceedings for The Second Conference on Computer Supported Cooperative Work —CSCW'88 ACM, pp. 167-177

Bjerknes, G. and Bratteteig, T. (1988b): Computers—Utensils or Epaulets? The Application Perspective Revisited AI and Society vol 2 no 3, pp. 258-266

Bjerknes, G. & Bratteteig, T. (1995): User Participation and Democracy. A Discussion of Scandinavian Research on System Development, Scandinavian Journal of Information Systems, vol 7 no 1, pp. 73-98

Bjerknes, G., Bratteteig, T., and Espeseth, T. (1991): Evolution of finished systems: The dilemma of enhancement, Scandinavian Journal of Information Systems vol 3, Aug. 1991, pp. 25-45

Bjerknes, G.; T. Bratteteig,: J. Kaasbøll; I. Sannes & H. Sinding-Larsen (1985): Gjensidig læring ("Mutual Learning") Florence Report no 1, Department of Informatics, University of Oslo

Bowers, J. & J. Pycock (1994): Talking Through Design: Requirements and Resistance in Cooperative Prototyping, Adelson, B. et al. (eds): Proceedings of the Human Factors in Computing Systems—CHI'94, ACM/SIGSHI, pp. 299-305

Bratteteig, T. & E. Stolterman (1997): Design in groups—and all that jazz, Kyng & Mathiassen (eds): Computers In Context, MIT Press, 1997 (forthcoming)

Bråten, S. (1973): Model Monomoly and Communication, Acta Sociologica, vol 16 no 2, pp. 98-107

Curtis, B., Krasner, H. & Iscoe, N. (1988): A field study of the software design process for large systems, Communications of the ACM, vol 31 no 11, pp. 1268-1287

Dewey, J. (1958): Experience and Nature, Dover Publ. Inc, New York

Dewey, J. (1963): Experience & Education, Macmillan publ. co, New York

Einarsrud, A.K. & T. Granholm (1986): Spesifikasjon of implementasjon av deler av programmoduler for sykepleiere (Specificationand implementation of parts of program modules for nurses) Master Thesis, Department of Informatics, University of Oslo

Engeström, Y. (1987): Learning by expanding. An activity-theoretical approach to developmental research Orienta-Konsultit Oy, Finland

Fjuk, A. & L. Øgrim (1997): Participatory Design through Problem Orieted Project Pedagogy, working paper, Department of Informatics, University of Oslo

Fjuk, A. & L. Dirckinck-Holmfeld (1996): Problem orientation as Foundation and Method for Computer Supported Collaborative Learning , working paper, Department of Informatics, University of Oslo

Freire, P. (1971): Pedagogy of the Oppressed, Herder & Herder, New York

Gasser, L. (1986): The Integration of Computing and Routine Work ACM Transactions on Office Information Systems, vol 4, no 3, pp .205-225

Grindsted, L.W. & Olsen, J.B. (1994): Problem oriented education (in Danish), TNP series no 34, University of Aalborg

Göranzon, B. (ed) (1984): Datautvecklingens Filosofi — tyst kunskap och ny teknik ("The Philosophy of Computer Development—tacit knowledge and new technology"), Carlsson & Jönsson, Malmö

Handal, G. & P. Lauvås (1983): På egne vilkår ("On your own premises") Cappelen, Oslo

Illeris, K. (1974): Problemorientering og deltagerstyring ("Problem orientation and participants' control") Munksgaard, Copenhagen

Jantsch, E. (1980): Interdisciplinarity: dreams and reality, in Prospects, vol 10 no 3, pp. 304-312

Lave, J. & E. Wenger (1991): Situated Learning Cambridge University Press, Cambridge

Munk-Madsen, A. (1978): Systembeskrivelse med brukere ("System description with users") MA Thesis, DAIMI, University of Aarhus

Schön, D. (1991): The Reflective Practitioner Basic Books, Avebury

Star, S.L. (1989): The Structure of Ill-Structured Solutions: Boundary Objects and Heterogeneous Distributed Problem Solving, Gasser & Huhns (eds): Distributed Artificial Intellingence, Pitman, London, pp. 37-54

Star, S.L. (1991): The sociology of the invisible: The Primacy of Work in the Writings of Anselm Strauss, Maines (ed): Social organization and social process: Essays in Honor of Anselm Strauss, Aldine De Gruyter, New York, pp. 265-283

Strauss, A. (1985): Work and the division of labor The Sociological Quarterly, vol 26 no 1, pp. 1-19

Strauss, A.: S. Fagerhaugh; B. Suczek & C. Wiener (1985): Social Organization of Medical Work The University of Chicago Press, Chicago

Suchman, L. (1983): Office procedures as practical action: Models of work and system design, ACM Transactions on Office Information Systems, vol 1, pp. 320-328

Suchman, L. (1987): Plans and situated actions, Cambridge University Press, Cambridge

Suchman, L. & E. Wynn (1984): Procedures and Problems in the Office, Office: Technology and People, Vol. 2, pp. 133-154

Thoresen, K. (1989): Systems development—Alternative design strategies, Tijdens et al (eds): Women, Work and Computerization: Forming New Alliances, Proceedings of the IFIP TC ( /WG).1 International Conference on Women, Work and Computerization, Amsterdam 27-29 April 1988, pp. 123-130

Walz, D., Elam, J.J., & Curtis, B. (1993): Inside a software design team: knowledge acquisition, sharing, and integration, in Communications of the ACM, vol 36 no 10, pp. 63-77