The SAIK project was carried out as an experimental system design project, trying out new as well as established ways of supporting the design process.
The methods used can be divided into three groups: qualitative methods for understanding cooperative work, design methods for creating visions of future computer support based on an understanding of the present work, and object-oriented methods for modeling and creating the computer system.
2.2.1 Qualitative Methods
Understanding the users’ work practices is clearly a pre-condition for design-ing computer systems. This has been emphasized extensively in the tradition of Participatory Design as evident in the “Design at Work” book (Greenbaum
& Kyng, 1991) and in the MUST method, which relies on ethnographic ap-proaches to understanding work practices (Kensing et al., 1996). In the SAIK project qualitative methods were the methodological basis for investi-gating the work at the different departments and hospitals. Furthermore, as
stated above, an important part of re-designing the Green System involved understanding the benefits and problems of the existing version. Qualitative methods were used for this purpose as well [4].
Traditional qualitative methods, such as semi-structured interviews with sub-sequent transcription were used (Patton, 1990). Furthermore, inspired by the extensive focus on ethnographic workplace studies as the basis for CSCW design, the bulk of the investigations were carried out as detailed workplace studies2. This involved participant observation, in-situ question-asking, the investigation of written documents and other artifacts, the study of specific work-settings, patterns of communication and coordination, photographic and video recording, etc.3 Most of this participant observation was done in a white coat.
2.2.2 Design Methods
A central methodological focus in the SAIK project, has been to try to com-bine methods of understanding with methods of designing. Hence, emphasis was put on describing the insights obtained during the workplace studies in ways, in which such descriptions could become useful in the design of computer support. For this purpose, the work practices in the different de-partments were documented usingscenarios4, which later were directly used to support design decisions and hence constituted the design rationale for the Patient Scheduler[5]. However, these scenarios were not only used in de-sign but also in different PD sessions with users. Hence, scenarios describing different cooperation and coordination problems were used as a background
2The word ‘inspired’ is important here. I do not by any means claim that I have been doing ethnography. Field studies within ethnography takes years and ethnographers are trained in doing this. Furthermore, ethnography is not about data collection, but about representing the observations grounded in the empirical data (c.f. Anderson, 1994; Strauss
& Corbin, 1994).
3References to descriptions of ethnography, which has provided the background for the work done in the SAIK project includes: Anderson (EEM), Blomberg et al. (1993);
Strauss & Corbin (1994); Hodder (1994); Jordan (1996); Hughes et al. (1994); Suchman
& Trigg (1991); Sommerville et al. (1993); Vidich & Lyman (1994).
4Normally the work scenarios is used to denote hypothetical descriptions of future work practices. However, I use the word scenario to cover descriptions of concrete instances of current work practices as well.
for future workshops (Kensing & Madsen, 1991). Furthermore, scenarios were used in different prototyping sessions (Bødker & Grønbæk, 1991) where the scenarios together with the prototype documented new work practices. How-ever, traditional prototyping sessions normally address single-user situations, where the designer cooperates with one user concerning the applicability of the prototype for certain work practices. Since the aim for the present work was to design for collaborative work settings, a new prototyping method – called organizational prototyping – was developed and applied twice in the SAIK project [1,2].
2.2.3 Object-Oriented Methods
Object-Oriented methods were used in the SAIK project to create the Pa-tient Scheduler. In particular the Danish method of OOA&D (Mathi-assen et al., 1993; 1995) was applied combined with inspirations from OMT (Rumbaugh et al., 1991). Object-Orientation is basically used to model the computer system. Object-Oriented Analysis (OOA) aims at “building a model of the object system, i.e. of the future users perception of their work practices.” (Mathiassen et al., 1993; p. 11, my translation). OOA starts from a “precise, overall definition of a specific proposal for a computer system, expected to be present from a pre-analysis” (ibid.). Object-Oriented Design (OOD), on the other hand, aims at modeling the computer systems as such, i.e. the technical construction of software (Mathiassen et al., 1995). In other words, OOA models the computer system from the outside, OOD from the inside. There are some conceptual overlaps and confusions to watch out for here. The concept of ‘design’ in this thesis means to outline the overall structure and appearance of a computer system, and to address its future use and embedding within some organizational work practices. Hence, the use of the concept of ‘design’ in the present thesis does not align with the use of the concept in OOD. Design, as used in this thesis, points to activities taking place in what is called pre-analysis above and during OOA. However, more technical opportunities and limitations, normally. modeled in OOD, can in-fluence the design of a computer system, and are therefore also considered in design activities.
As a pilot project trying to develop design principles for the design of coop-eration at hospitals in Denmark in a more general sense, two ambitions were
central to the SAIK:
1. In order to create a system to be used at several hospitals in Denmark, it was important to generalize experiences obtained in the different hospitals involved in the project.
2. In order to inform the design of computer technology at KMD, it was important to be able toreuse the design principles in other projects at KMD.
To meet these objectives, the design of the anal version of the Patient Scheduler was documented using Analysis Patterns [5]. Analysis Pat-terns resemble the widespread use of Design PatPat-terns in the OO-community (Gamma et al. 1995). But in contrast to Design Patterns, an Analysis Pat-tern is a solution to a recurrent problem within anorganizational context, not within construction of software. An Analysis Pattern is an object-oriented solution that represents a common construction in some business modeling – in this case within hospitals as an organization (see also Fowler, 1997). The real-world problem, that each Analysis Pattern is attempting to solve, is rep-resented as a generic scenario, which works as an inspiration for the analyst in the future. Examples of such generic types of activities are paper-based requisition of radiology examinations and scheduling incoming requisitions.
These generic scenarios provided the background for extracting the general design knowledge embedded in the Patient Scheduler, which could be reused in other projects at KMD. The Analysis Patterns used in the Pa-tient Scheduler are documented in Technical Report no. 4. The use of scenarios in Analysis Patterns, as suggested in [5], is new and it turned out to be a useful way to document OOA knowledge for later reuse. The idea of Analysis Patterns coupled with rich scenario descriptions are currently being adopted in other projects at KMD.
∗ ∗ ∗
In total, 109 scenarios describing current work practices, 43 of these describ-ing work practices surrounddescrib-ing the use of the Green System, and 23 scenarios describing future work practices were constructed. 4 future workshops were conducted. The Patient Scheduler went through 3 main cycles of iter-ations, involving 14 prototyping sessions and 2 organizational prototyping
sessions. 3 technical reports (numbered 2 through 4) have documented the design of the Patient Scheduler, the final report containing in total 12 analysis patterns.