27.11.2012 Views

User Centered Design in Practice - Problems and Possibilities

User Centered Design in Practice - Problems and Possibilities

User Centered Design in Practice - Problems and Possibilities

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

they together with the eng<strong>in</strong>eers evaluated different designs <strong>and</strong> sketched new <strong>in</strong>terfaces.<br />

We spent two months <strong>in</strong> this way ’play<strong>in</strong>g’ with the new product, deliberately soften<strong>in</strong>g<br />

the borders between the expertise of the different groups <strong>in</strong>volved. The results were<br />

good. In a relatively short period of time we had been able to surface concerns with<br />

respect to e.g. <strong>in</strong>jection mold<strong>in</strong>g or assembly that has earlier distorted similar conceptual<br />

design (for a general treatment of this theme see end (Buur & Andreasen 1989)). The cost<br />

was that some suggestions had to be given up, but the fact that e.g. the manufactur<strong>in</strong>g<br />

people had also been <strong>in</strong>volved <strong>in</strong> discussions with the users meant that the design we<br />

f<strong>in</strong>ally went for, came out almost unaltered <strong>in</strong> the end.<br />

Workshops throughout the development process<br />

Beyond reach<strong>in</strong>g out for collaboration with the eng<strong>in</strong>eer<strong>in</strong>g team <strong>and</strong> the users <strong>in</strong> the<br />

conceptual phase we see also a need for keep<strong>in</strong>g users <strong>in</strong>volved dur<strong>in</strong>g the more detailed<br />

eng<strong>in</strong>eer<strong>in</strong>g phase. Particularly <strong>in</strong> larger development projects options <strong>and</strong> constra<strong>in</strong>ts<br />

tend to pop-up cont<strong>in</strong>uously all the way through to manufactur<strong>in</strong>g. In these projects we<br />

have argued for a cont<strong>in</strong>uos <strong>in</strong>volvement of the users, <strong>and</strong> we f<strong>in</strong>d the workshop format<br />

useful for br<strong>in</strong>g<strong>in</strong>g together users <strong>and</strong> eng<strong>in</strong>eer<strong>in</strong>g team. In a large development project on<br />

a new series of water hydraulic components a group of mach<strong>in</strong>e manufacturers <strong>and</strong> endusers<br />

from the food <strong>in</strong>dustry were <strong>in</strong>vited to follow <strong>and</strong> take part <strong>in</strong> the detailed<br />

eng<strong>in</strong>eer<strong>in</strong>g of the new product program. The group participated <strong>in</strong> four full-day<br />

workshops over a one-year period. Our role was to facilitate the process <strong>and</strong> f<strong>in</strong>d suitable<br />

representations of the on-go<strong>in</strong>g design (Br<strong>and</strong>t & B<strong>in</strong>der 1997). Two th<strong>in</strong>gs came out of<br />

this process that has later become part of user centered design ’repertoire of resources’.<br />

First we found that stretch<strong>in</strong>g the conventional representations of design work was both<br />

necessary <strong>and</strong> possible. In eng<strong>in</strong>eer<strong>in</strong>g design most design representations are directed<br />

<strong>in</strong>wards towards people with the same competency, but <strong>in</strong> order to engage <strong>in</strong> dialogue<br />

with other groups, design suggestions has to have a richness that makes it possible to<br />

span the gap between the concerns of different groups. We found wooden mock-ups to<br />

be particularly useful <strong>in</strong> this project, <strong>and</strong> learned to use the mock-ups as shared anchor<strong>in</strong>g<br />

po<strong>in</strong>ts for the dialogue between users <strong>and</strong> eng<strong>in</strong>eers (E. Br<strong>and</strong>t 1998). The second th<strong>in</strong>g<br />

we learned was that the workshop sessions were as highly valued for the <strong>in</strong>ternal<br />

coherence it created <strong>in</strong> the eng<strong>in</strong>eer<strong>in</strong>g team as for the <strong>in</strong>put it provided from outside. In<br />

development projects the collaboration between many different competencies seems to call<br />

for a type of dialogue <strong>in</strong>ternally that is basically not unlike the dialogue between users <strong>and</strong><br />

designers (B<strong>in</strong>der & Nielsen 1996).<br />

Work<strong>in</strong>g with ’rich design materials’ <strong>in</strong>-between decision<br />

po<strong>in</strong>ts<br />

When try<strong>in</strong>g to overcome the apparent isolation of our HMI-competency by becom<strong>in</strong>g<br />

more full-blown players <strong>in</strong> the stag<strong>in</strong>g of product development activities, we had to give<br />

up our exclusive right to <strong>in</strong>terpret the ‘voice of the user’. Further more we had to f<strong>in</strong>d a<br />

way to position the type of activities we engage <strong>in</strong>, with respect to the more formal<br />

38 (85) CID-40 • <strong>User</strong> <strong>Centered</strong> <strong>Design</strong> <strong>in</strong> <strong>Practice</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!