From lechner@cs.uml.edu  Mon Aug  8 12:27:54 2005
Subject: Re: [re-online] Help finding evidence of user involvement in (fwd)
To: hgoodell@cs.uml.edu (Howard Goodell), Sarah_Kuhn@uml.edu (Sara Kuhn WkEnv)
Cc: lechner@cs.uml.edu (Bob Lechner), lechnerd@wdn.com (David Lechner),
   heines@cs.uml.edu (Jesse M. Heines)
RJLRef: $PH/05f523/GUIReqtsCaseStudy050805.txt

Forwarded message:
> From re-online-bounces@it.uts.edu.au  Mon Aug  8 05:45:26 2005
> To: Requirements Engineering Online Discussion Forum <re-online@it.uts.edu.au>
> From: Soren Lauesen <slauesen@itu.dk>
> Subject: Re: [re-online] Help finding evidence of user involvement in
> 	software projects
> 
> At 19-07-2005  21:37, Helen Sharp wrote:
> >I'm trying to find evidence to support the importance of involving users 
> >in software projects. In the past I have referenced the Standish reports, 
> >but as these have recently been called into question, I am looking for 
> >alternative evidence.
> 
> I think the term "user involvement" is too broad. Users can be involved in 
> many ways, some of them benificial, others harmful (see below). The 
> traditional idea of users as co-developers has never been proved in 
> practice as far as I know. (The traditional "Scandinavian school" claimed 
> it, but never proved it in practice. I am a Scandinavian myself).
> 
> Here is a well-documented example where it failed: Redmond-Pyle and Moore 
> (in their book Graphical User Interface Design and Evaluation, Prentice 
> Hall, 1995) have a wonderful case story of a system that was developed with 
> participatory design and iterative prototyping, yet failed to provide 
> adequate usability. Only the expert users that had participated in the 
> design were able to use the system.
> 
> In my own book, User Interface Design - A Software Engineering Perspective, 
> I summarize my experiences with user involvement in this way (p 474):
> 
> Some designers claim that if you involve the users, the project will be a 
> success. Unfortunately, user involvement is no guarantee of success, as we 
> have seen in several failed projects. True, it is important to involve 
> users in the development process, but how? Here are some roles they can play:
> 
> 1.       Members of design teams or workshops where the user interface is 
> designed. This is sometimes referred to as participatory design.
> 
> 2.       Reviewers who assess the user interface and discuss it with the 
> developers.
> 
> 3.       Test users in usability tests, where they try to carry out tasks 
> with the new user interface.
> 
> 4.       Test users who exercise the system at delivery time to check that 
> everything works correctly. They primarily help finding bugs in the system.
> 
> 5.       Knowledge sources of how tasks and business procedures are 
> currently carried out.
> 
> 6.       Brainstorm participants who produce ideas and identify problems.
> 
> 7.       Members of the steering committee for the project.
> 
> Users can carry out all of these roles, and in roles 3, 5, 6 and 7 they may 
> be instrumental in the project's success. The risky thing is if users in 
> role 1 (designers) also handle roles 2, 3 and 7 where they should represent 
> ordinary users. They are no longer typical users and are so absorbed by 
> their design that they may have a problem in seeing its weaknesses. They 
> may even forget the business goal of the system in their design fascination.
> 
> Soren L.
> 
> _______________________________________________
> Soren Lauesen, professor
> IT University of Copenhagen, room 3E04
> Rued Langgaards Vej 7
> DK-2300 Copenhagen S, Denmark
> Tel, home: +45 39 56 17 48
> Tel, office: +45 72 18 51 53
> Fax, office: +45 72 18 50 01
> E-mail: slauesen@itu.dk
> http://www.itu.dk/people/slauesen/ 
> _______________________________________________
> re-online mailing list
> re-online@it.uts.edu.au
> http://discuss.it.uts.edu.au/mailman/listinfo/re-online
>