Lya, the answer you seek depends greatly on the type/size of the project, the allocated timeline, available resources, budget, etc.
I prefer doing small groups in sprints of ~five users, one at a time. This can be remote or in person; I prefer in person b/c facial expressions can reveal hesitation or frustration that might otherwise go unrecorded. Two or three sprints per project has worked for me, but again this can vary. I design a script of tasks based upon stakeholder goals, specific pain points and features that have changed since the last version. I ask users to do something and rate the efficiency of the system's response on a scale of 1 to 5. Any opportunity for feedback, advice, criticism, questions, complaints or additional commentary is cheerfully received and encouraged. Paper/pens or a whiteboard should be within easy access. Any predetermined opinions I have are kept well in check - they have no place here. They say it helps if you have a third person around to take notes or whatever, but I find that users will give more honest feedback if they don't feel outnumbered. I try to keep the test as far from a "lab" situation as possible. Number one rule = make sure the folks you're working with understand that you're testing the software/prototype/application, not their ability as a user. And *always* thank them for their contributions; I also like to provide a follow-up email upon release to let them know how things worked out. Hope this helps. Good luck ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Posted from the new ixda.org http://www.ixda.org/discuss?post=25862 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
