Software Technology for Evolutionary Participatory Design Development

STEPS (Software Technology for Evolutionary Participatory Design Development) is an early methodological framework originating from Technical University of Berlin and combines PD and software engineering with a focus on the custom development of new software (Bratteteig et al, 2013:121). It embodies a paradigm shift in software engineering from a ‘product-oriented’ to a ‘process-oriented’ paradigm (Floyd, 1992).

This method facilitates the co-development of usage and software as a joint design and exploratory learning process (Bratteteig et al, 2013:121). The main perspectives are

objects. The gradual establishment of requirements take place in “an interplay of anticipative, constructive and evaluative steps” (Floyd, Reisin & Schmidt, 1989:53) developed through the interactions of developers and users.

Figure 5.13: STEPS framed through Activity Theory

Within STEPS there are certain stages that are carried out by a blended design team of developers and users, termed participative activities, and other stages where the two work in parallel. In these parallel work activities we see expansive design taking place, where developers and users negotiate a way forward based in findings from each group’s activity. Floyd, Reisin & Schmidt (1989) refer to these negotiated objects as new reality domains. Figure 5.13, adapted from Floyd, Reisin & Schmidt (1989) presents the STEPS model framed through AT. Here we see the starting point as Project Establishment where users and developers collaborate on concepts of software development, with users deciding on which options to take forward. These options are then taken forward into the initial production phase of System Design, again a collaborative activity between users and developers. The object of this activity is the

development of proposed system designs, arrived at through mediation by dialogue and prototyping and other tools. The product of this activity is the system specification, which is then constructed by developers while users prepare the context for embedding of the software. These two parallel activities come together to produce a system version, which is then tested by users and maintained by developers. This expansive design phase requires continual negotiation of the object of design, which emerges and evolves through use. Once testing has taken place the cycle begins again with either revision or refinements taking place. STEPS, therefore adopts an evolutionary approach to design, comprising various forms of prototypes and the development of system versions (Floyd, Reisin & Schmidt, 1989:53). Within each cycle there is the combination of development and application of the software, with activities by designer/

developers, users and collaboration between both groups. Through the acknowledgement of joint and role-specific responsibilities, STEPS aims to incorporate heterogeneous perspectives from users and designers in the design of software systems for the workplace (Bratteteig et al, 2013:122). Floyd, Reisin & Schmidt (1989:53) note that ‘multiperspectivity’ is a basic prerequisite for cooperative work.

The following framing of STEPS through the interpretive lens of AT elaborates on Figure 5.13:

• Subjects: Developers and Users come together at the project establishment phase. Here, this collective group makes up the subjects component of the activity. During the development process though, this group splits into their two original groups of subjects, each acting on their own activity’s object. Subjects in the STEPS process can therefore be seen as a converging and diverging component of the development activity system, coming together when a joint decision needs to be made, and separating when domain-specific knowledge is required.

• Object: Users and developers act together on the co-development of the software artefact, as well as the design and development process itself. The result or outcome of which is mutual learning between the users and designers. Objects in STEPS are acted upon by the collective group of developers and researchers, or negotiated by the two groups in expansive design phases.

• Tools: This method does not specify any tools or techniques, relying rather on the selection of these by designers and users as and when they are needed STEPS is compatible with any technique, tool or other method, provided they allow for evolutionary modelling (Bratteteig et al 2013: 123). The outcome of this process is the development of tools, in the form of programs. These tools will go on to mediate the user’s objects well beyond the project.

• Community: The community of activity is the workplace, with developers embedding themselves in the user’s space. Different activities throughout the design process require different communities of activity. The two community

gets developed, and the developers. During the establishment of the project and subsequent revisions, users and developers work collectively in a community of practice, however, once the system is specified users and developers work in parallel on complementary activities, embedment preparation and software realisation. This parallel activity is seen again in the application stage.

• Rules: These include the joint participation in system development, user-oriented quality criteria favoured over technical quality criteria and the fact that design decisions rest with the users (Floyd, Reisin & Schmidt, 1989). As the process is made up of a series of activities, collective and expansive, certain rules and guidelines are developed for these by those involved, that is, they are domain specific. For example in the application phase, the rules that apply to developer work activities would different to the rules that apply to the user work activities.

That is not to say they are always mutually exclusive, as overlap is possible.

• Division of Labour: STEPS specifies both aspects of joint-responsibility and role specific actions. The overarching labour concept however is that of equality, where the designers and users decide on the scope and structure of the object together.

5.4.2 Theories of and Methods for Initial Analysis and Design Activities