<i>"... Bring a group of your most passionate customers together for an entire day of 'build a biz' and have them rotate from workstation to workstation completing a series of tasks. ..."</i><p>Following the theme of <i>"build what people want"</i> but I disagree in someways with this statement. Can we really be more specific here?<p>- <i>let users loose on entire app, specific features or just tasks?</i><p>- <i>how many is a group?</i> <p>- <i>how often?</i><p>- <i>can you use even less people?</i> <p>Sometimes just observing users figuring out what to, do rather than <i>just</i> giving them specific goal directed tasks has more benefit. They allow you to observe users as they interpret what is going on rather than you giving them directions. <p>When it comes to testing Nielson advises 5 is enough using this formula
<i>N(1-(1-L)^n)</i> where "N" is usability problems, "L" is 'proportion of usability problems while user testing' and "n" is the number of users. Graphing this yields <i>'usability problems found'</i> over <i>'number of test users'</i>. ~ <a href="http://www.useit.com/alertbox/20000319.html" rel="nofollow">http://www.useit.com/alertbox/20000319.html</a> <p>Joel goes further in his <i>"12 Step testing"</i> and optomises Nielson`s method. Joel reckons you should try to grab <i>anyone</i> (one person, when you have completed some code) who happens to be in the hallway to test your current code ~ <a href="http://www.joelonsoftware.com/articles/fog0000000043.html" rel="nofollow">http://www.joelonsoftware.com/articles/fog0000000043.html</a>