[s2If !is_user_logged_in()] [/s2If][s2If is_user_logged_in()] [s2If is_user_logged_in()]

Team member 2: ‘So therefore I really think that it must be nice if one can see that there is an error on one (component) out there, not necessarily how one can solve it.’

Marketing: ‘That’s what I say one can then do on the computer, it is if uh at the time when this system is technologically so developed that all the parts function’

Team: (shuffling, laughter)

Marketing: ‘Then uh its actually uninteresting that it is signalling, because he will anyway see it on his monitor; because that’s where he gets his information inside; in an easily understandable way.’

The conversation is about where an operator will find out if a flow meter has a defect. When presented with a scenario, where the operator handles everything from inside a control room, one team member objects that in her understanding the operators seem to walk the plant at all times; and that they neither ‘feel like’ nor ‘can’ stop doing this. The marketing employee counters that it is only necessary to enter the (dirty, noisy, smelly) facility to ‘sweep the floor’, i.e. that the real work takes place in a control room.

FIGURE 2 The Bioscope; an information display at the basin’s edge

A second team member steps in to support the observation that operators walk the plant, and it must be ‘nice’ to see error messages on the component itself. The marketing employee distances himself by stating that he is talking about a future ‘when technology is so developed’ that parts don’t break down. Then it’s ‘uninteresting’ to visit the plant, because all necessary information is provided ‘inside’ in the control room. Basically, here is a breach in understanding of what work is about at a wastewater plant, and what role technology can play, but it is expressed in a design decision about whether or not a flow meter should have a local alarm display.

Having observed operators at work, our team in this session came to realize that ‘walking the plant’ may be a really important characteristic of operator practice. That operators actually performed ‘control work’ on location was not common knowledge in the business units, and it seemed to upset employees and their understanding of their product and what automation is about. It was also very distressing that the team – even being ten to one – was not able to win the argument in a rational manner. In fact the ‘us’ versus ‘them’ perception was amplified throughout the session, and this contributed to a confrontational atmosphere.

In the course of the next 3 months we struggled to come to grips with the field observations and how they might ‘inform’ new product opportunities. The design process involved scenario sessions, operator workshops, design games in the company and in plants, and many other participatory activities. One of the design concepts that emerged, we called ‘The Bioscope’, a screen placed out in the plant facility. This concept focused on precisely the issue described above: On whether operators in the future will be based in a control room or ‘walk the plant’. The second episode shows how ethnographic knowledge, reified in a product mock-up, provokes a debate directly between operators and product engineers, with the design team acting merely in the role of ‘go-between’.

Episode 2 – Design Mock-up as Provocation. The design team has invited six operators and ten experts from the business units to a final workshop for evaluating the outcome of the 6-month vision project. In mixed groups, participants discuss how various design concepts will change work practices. Then during the presentations, when an operator praises The Bioscope, the following conversation takes place:

Engineer: ‘Wouldn’t it be just as clever to see it (the information) inside from an office chair rather than at the basin’s edge in 10 degrees frost?’

Operator: ‘But maybe there is nobody inside.’

Engineer: ‘Okay?’

Operator: ‘He may be only inside for a quarter or half an hour a day. He doesn’t stand around looking at the screen all the time.’

One of the business unit engineers challenges the very idea of The Bioscope; wouldn’t the operator prefer to be inside in an office? I.e., isn’t the ‘clever’ work happening inside? The operator responds that they do not actually man a control room, but only check the control computer occasionally – because work is located outside in the plant. To him ‘inside’ is not an option, nor a desire. In fact, the same question is repeated three times by various engineers during the next 20 minutes, with the weather conditions becoming worse and worse (rain, frost, snow), but the operators never give in; to them work is about ‘walking the plant’, and a computer screen in an office cannot substitute for that.

THE CONFIGURATION PROJECT

The USEC (User Supportive Embedded Configuration) research consortium is a joint effort between industries and universities in Denmark. It explores opportunities to apply configuration technologies in the industrial field. The consortium is divided into three research areas: software algorithms, product logistics, and user studies. As the user studies group, we collaborate with Danfoss on configuration technologies for refrigeration systems in supermarkets and industrial kitchens.

Whereas the debate in the first Water Vision encounter came as an unplanned surprise to the design team, the third encounter shows an organised debate between engineers and designers in a large, on-going interface design project. By carefully crafting the ethnographic material into videos and storyboards, we aimed to stage a provocative debate similar to the unplanned one in Episode 1.

FIGURE 3 Engineers discuss what configuration means to service technicians based on video and storyboards

Episode 3 – A Staged Provocation. The half-yearly USEC workshops bring researchers from the various university and industry partners together to share results and coordinate progress. The third one took place at Microsoft Business Solutions. For this workshop, we have prepared a group activity for all participants to discuss different perspectives of configuration. This activity was intended to provoke disciplinary understandings while basing the discussion on real and concrete configuration scenarios. By doing this, we were hoping that the various groups would have the opportunity to learn from each other.

In the first part of the activity, the participants watch video stories of configuration practices from three different field sites. Each video is introduced with a brief overview about the location, the technicians and the purpose of the configuration. Then the participants work in groups of two. Each group analyzes a storyboard of one of the videos. We ask them to describe the scenario from their point of view and to identify any configuration issues. We also ask them to describe possible problems and solutions. Finally, participants present their storyboards for general discussion in the large group. The following is a discussion that takes place between several engineers and a designer:

Engineer 1: ‘So, at the end we reject the question and say that this is not configuration. From what we see, it is a natural language problem. This is a problem of logic, which is not a problem in our field. So I wouldn’t describe this one (as configuration).’

Engineer 2: ‘Yeah, well if we were to say that this is configuration, or to support this by configuration, then we would need some more information on this….’

Engineer 3: ‘But could you explain to us that this is not a kind of configuration problem? Because to me this definitely describes some…’

Engineer 1: ‘Well, it is. But it is not the problem that we’re interested in. I wouldn’t really describe this as a configuration problem. I would describe this as a natural language problem.’

Designer 1: ’So you wouldn’t see it as a configuration problem, because it doesn’t say configuration?’

Engineer 1: ‘Well…I would describe this as a natural language. That’s as far as I know.’

Engineer 3: ‘That’s interesting. Because for me, I could see how they would need to configure the system somehow to optimize it. Maybe in a way it is actually a de-configuration example.’

Engineer 4: ‘Well, we had a similar discussion here. We thought that optimization is not a configuration. But we have to do re-configuration to get an optimal condition. So there is a purpose, which is optimization. But it is not the reconfiguration.’

Engineer 3: ‘So reconfiguration is actually the means to optimize such a system.’

[/s2If]