Cooperative Experimental System Development

The Cooperative Experimental System Development (CESD) method is characterised by its focus on:

• Active user involvement throughout the entire development process,

• Prototyping experiments closely coupled to work situations and use scenarios,

• Transforming results from early cooperative analysis/design to targeted object-oriented design, specification, and realisation, and

• Designing for tailorability (Grønbæk, Kyng and Mogensen, 1995:1).

At this approach’s foundation is its alignment with the ‘tool perspective’, which takes the labour process as its origin, rather than data or information flow (Bratteteig et al., 2013:125; Ehn and Kyng, 1985:1). In the development of tools, Ehn and Kyng (1985:13) refer to the ‘experienced end user’ and the ‘skilled worker’, acknowledging their tacit knowledge, which forms the basis of analysis and design and thus

necessitates their inclusion in the design and development process. That is, users contributing to the design of the tools they use.

To do this CESD moves away from an activity flow model, apparent in the previous PD method examples of STEPS and MUST, toward a conceptual model (Figure 5.17) that analytically separates abstract concerns from concrete activities and techniques. At an abstract level, concerns capture what a project is about, while activities are what actually goes on in a project (Bratteteig et al, 2013:126). This analytical separation of activities and concerns acknowledges that an activity may contribute to several concerns and vice versa, that is, “any one concern is realised through a number of activities” (Grønbæk, Kyng & Mogensen, 1995:5). Figure 5.17 presents this separation in a conceptual model for cooperative experimental system development.

This conceptual model places project activities in the centre of the top layer. CESD activities relate to the early Scandinavian model of Cooperative Design, where the important, distinguishing activities are workshop-based cooperative experiments and interventions. These activities develop in the context of the involved domains, which include the practice of the developers and users, and the technology and visions of technology in use (Grønbæk, Kyng & Mogensen, 1995:4).

The central level shows the concerns, which as illustrated in the internal cone, are realised through activities. Grønbæk, Kyng & Mogensen (1995:4) state that, “One activity typically contributes to more than one concern, but usually an activity has one concern as its main focus.” Figure 5.18 presents a fictional example of how project establishment could be framed as an activity, with end users, developers and designers planning tasks and deliverables, actions mediated by observations and descriptive techniques. The activity here has as its focus the concern of management (M) but also contributes to design (D) and analysis (A), to lesser degrees.

Figure 5.17: CESD conceptual model (adapted from Bratteteig et al, 2013:127)

Figure 5.18: Activity system with management, analysis and design as outcomes of planning phase

Figure 5.17 also illustrates the relationship between the concern and activity levels, such that project management is mainly directed towards the developers practice, analysis towards user’s practice, design towards visions of technology in use, and realisation towards technology (Grønbæk, Kyng & Mogensen, 1995:4). At the base of the model (Figure 5.17) is project assignment, which represents the task as it is understood by the project participants, this also gives direction to the concerns (ibid).

Figure 5.19 presents an example of the CESD conceptual model through the lens of activity theory, where the object of the activity, a collective understanding of the task by

users and developers, is embodied in the activity and acted upon by participants. The Project Assignment component of the CESD conceptual model can be understood as the co-defined object of activity, representing the task or work activity as it is understood by the participants. The object contributes to multiple concerns, which are in turn realised through various activities. The model represents the complex work environment where, through activity, possible tools for the domain are produced and tested, giving rise to emerging artifacts-to-be (Kuuti, 2009:80).That is, through activities focussed on improving tools currently used, new uses emerge. This relates to Grønbæk, Kyng and Mogensen, (1995:9) in their unpacking of analysis, in which they state that, “Challenging the established with alternative possibilities is a primary means to investigate constraints and potentials for change within current practice.”

!

Figure 5.19: Example of CESD framed through an AT lens

The following framing of CESD through the interpretive lens of AT elaborates on Figures 5.17 and 5.19:

• Subject: End users, developers, analysts, designers & programmers all play a role in CESD projects. CESD makes use of ‘user representatives’, users involved in the design process who intermittently discuss concepts, visions and progress with colleagues and other community members not involved in the project. This extends the analysis and design beyond the working group (from subjects to community) and can provide new insights and contributions to the project (Grønbæk, Kyng & Mogensen, 1995:13).

• Object: The overall object of CESD is change within practice with people from practice (Grønbæk, Kyng & Mogensen, 1995:8). Individual activities that make up the process will each have their own object, determined by those involved. The project assignment (lower level in Figure 5.17), encapsulates the concept of a co-defined, shared vision of change driving the activity, and is presented here as the object of design.

• Tools: The basis of the tools and techniques of CESD is their object-orientedness, aimed at mediating change. These include thought provoking artefacts, prototyping and mockups, descriptive techniques, ethnographically-inspired approaches, observational techniques and dilemma games (Grønbæk, Kyng &

Mogensen, 1995:9,10,11,12). The tools and techniques used in CESD are

‘flexible’ allowing them to be modified for different purposes or adapted to participant needs.

• Community: The activity community is a team made up of users and designers in an object-oriented development environment, stated in CESD literature as the best opportunity for cooperation in system development (Grønbæk, Kyng &

Mogensen, 1995:11).

• Rules: Rules in CESD are aimed at ensuring genuine participation by users, fostering tailorability and continued development, and establishing an object-oriented approach to design. They include but are not limited to, specifying that a minimum of one contact person (minimum) per group of end-users be involved;

rules around establishing and sustaining cooperation; and specifying that implementation happens incrementally, giving continued feedback toward analysis and design, and facilitating learning from real use (Grønbæk, Kyng & Mogensen, 1995:7,13,14).

• Division of Labour: Labour is shared equally by all involved, however each participant works to their strengths, ie developers mock up software and users provide tacit knowledge of use in context.