Some PD advice

~ D is d i f ferent f rom convent ional design approaches in that users and system experts share the responsibil ity fo r the quality of the design proposal and the implemented system. Thus both system experts and users get new roles in the system development process. The system experts cannot make final design decisions on their own. This is a diff icult position because It requires a great deal of t rust in the users. The users, on the other hand, are responsible fo r the system they get. If they don' t like it, they cannot blame the system experts. In this way, PD brings users and system experts together in mutual commitment. The users must learn about technology f rom the system experts in order to understand what computer technology can do for them, and the system experts have to learn about the applicat ion domain f rom the users in order to build a flexible and eff icient system that fits the users' needs. If a PD process is successful, i t will contr ibute to a new perspective both on one's own work as a system expert, but also on the diversif ied and complex work of the users. However, even if the users have commitments to the project, they are also responsible for doing their jobs. And even though system experts share the responsibil ity with the users fo r the design of a computer system, the system experts will nevertheless be responsible for its implementat ion-o f ten based on deadlines scheduled beforehand. Thus, both users and system experts have commitments that compete with the mutual commitment o f the PD project. This tension can lead to frustrat ions and even conflicts. Therefore, it is important that PD projects also design the environments of the projects to cope with these tensions. Here I provide some advice on how to avoid a failing PD project based on experiences collected during the four-year Florence project. 1