Design as Co-construction of Work Practices

To view design of computer technology as a co-constructive process (c.f.

chapter 3) first of all means that the construction of computer artifacts can-not disregard an obligation to consider the parallel re-construction of work practices. Secondly, it means that design is a distributed collaborative ef-fort, involving a wide variety of different actors, with common as well as conflicting motives.

This conceptualization of the design practice, informs us that the design of computer technology is not only a matter of creating new means of work, i.e. working at the co-operative level, but is (potentially) a process of re-conceptualizing the whole object of work. This basically extents the notion of design as an iterative process involving two interlinked cycles of iterations:

the primary iteration between the design of an artifact and the conditions of work, and the secondary iteration between re-constructing the object of work and designing the artifact mediating this work. In the individual pa-pers, this secondary iteration is referred to as design for the “organizational perspective” [3, 4] or “organizational constraints” [6]. This double level of iteration is illustrated in figure 5.1.

Figure 5.1: The double iterative process of design.

In the primary iteration the process of routinization turns the devised arti-fact into an artiarti-fact mediating work according to its conditions. This process involves situating the newly devised artifacts in a working environment, and establishing their connection to the many other means of work, actors, re-lated activities, rules for work, norm, etc. Routinization is a process of taking the artifact into use, which is a prerequisite for the working ensemble to start applying it in their coordinated work. The suitability of the artifact for

me-diating the work – in connection with the contextual conditions of the work – is only evident at this point of time, or, as put by Bødker (1991): “the [artifact] only reveals itself, fully, in use” (p. 142). The second arrow in the primary iteration is the reflection (deliberate or not) upon the match between the means of work (especially the newly introduced computer arti-fact) and the conditions for the work. This reflection gives way for a further enhancement and change of the means for work. In a traditional iterative system development approach, this means adapting the computer artifact.

However, this needs not always be the case; other means for work can be, or ought to be changed. For instance, new rules for work, new division of work, new scripts and responsibilities, new physical artifacts supplementing the computer artifact, etc.

This primary iteration between constructing means for work (typical a com-puter artifact) and the conditions of work has been the subject for most research on iterative design methodologies. For example, within the Partici-patory Design tradition focus is on “how computers are used, which [is] called theuse situation” (Greenbaum & Kyng, 1991; p. 2). Within a user-centered design perspective, focus is on the interplay between the computer appli-cation and the organization of work (Gould, 1988; Schrage, 1996; Beyer &

Holtzblatt, 1998). Such methods, where designers seek a fine-grained aware-ness of work practices, however tend to becomeconservative (Clement & Van den Besselaar, 1993; Ehn, 1993). Workers involved in design often focus on incremental improvements of existing practices (Grudin & Grinter, 1995).

Discussing the dialectical relationship between tradition and transcendence Ehn (1993) asks: “Should the design support the traditional typographical production or completely new services, such as desktop publishing?” (p. 70).

Close work with traditional typographers in the UTOPIA project led to the former (Ehn, 1988; p. 333). In order to approach this limitation I argue that a focus on the secondary iterative cycle depicted in figure 5.1 should be incorporated to a greater extend in the design process. There are several reasons for taking this view on the process of design.

Firstly, given the investment in time, money, effort, etc., which is needed to design and construct new computer technology, it is an obvious moment to stop and reflect upon the overall structure and purpose of the work and the organization of it. It is preferable to avoid freezing inexpedient work practices in a computer system. This line of argument corresponds to the

view of computer technology as the enabler for new and improved business processes and work organization, which is evident in much of the Information Systems (IS) literature, and the business literature on IT (e.g. Business Pro-cess Reengineering). In general, the age of designing IT for the sole purpose of automating existing ways of working has passed, and has been replaced by a focus on the design of IT, which on a strategic level supports a re-conceptualized way of working. In the SAIK project, for example, the design of the Patient Scheduler was incorporated in the vision of re-organizing Danish hospitals, turning the traditional bureaucratic and functionally spe-cialized hospitals into Patient Focused Hospitals (PFHs), characterized by high cooperation in teams of healthcare workers, distributed radiology and other services, and flexible channels of communication and decision making.

Secondly, you cannot create new means for work without a strong common understanding of the object of work. However, the design process is a highly collaborative and distributed activity, involving a wide variety of actors. In the SAIK project alone – which is but a small project compared to real-world software development projects – such actors included; designers, program-mers, scientists, IT suppliers, organizational development consultants, hos-pital management, healthcare professionals (physicians, radiologists, nurses, etc.), and official healthcare authorities. Each of these actors has different views on the object of work and does not, in any explicit or detailed sense, have the object of work in common with one another. But a fundamental prerequisite for successful design of a computer artifact mediating work must necessarily be that the involved actors agree on the common object of work.

This re-conceptualization can only take place as a co-constructive reflection on the object of work involving these actors.

In this secondary iterationimplementation means implementing the common understanding of the object of work among the actors which are dedicated to the creation of the new means for work, i.e. the computer artifact. Taking the normal division of work between the constructors and the users of IT for granted, this means that the constructors need a profound understanding of the future users object of work and the conditions under which it is realized.

The efficiency of the IT constructors’ cooperative effort is highly dependent upon them having the object of work in common in a way, that they can relate and coordinate their efforts according to this common understanding.

Therefore, methods for ‘implementing’ the object of work in the ensemble

of IT constructors in a way that help sustain a focus on the users future common object of work are needed.

In summary, we can pose the claim that;it is fundamental to understand de-sign of computer artifacts as sitting in the middle of a double iterative process:

on the one side the artifact is constructed in accordance with the conditions of work; on the other side, the artifact is constructed in accordance with co-construction of the object of work. Hence, there is a need for establishing methods for tying the construction of a computer artifact together with the corresponding co-construction of the work practices.

5.3 Methods for Design

In this project I have primarily created and experimented with four types of methods for design of cooperative computer systems: (i) the use of detailed workplace studies in the design process, (ii) the use of scenarios, (iii) the use of prototypes in larger groups of users, and (iv) the use of analysis patterns for documenting recurrent themes in design solutions. Based on the experiences obtained by using these methods in the SAIK project, this section draws some conclusions concerning their applicability in design.