
Let Your Customers Build Your Business - donna
http://www.ducttapemarketing.com/blog/2007/07/03/let-your-customers-build-your-business/
======
bootload
_"... 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. ..."_

Following the theme of _"build what people want"_ but I disagree in someways
with this statement. Can we really be more specific here?

\- _let users loose on entire app, specific features or just tasks?_

\- _how many is a group?_

\- _how often?_

\- _can you use even less people?_

Sometimes just observing users figuring out what to, do rather than _just_
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.

When it comes to testing Nielson advises 5 is enough using this formula
_N(1-(1-L)^n)_ where "N" is usability problems, "L" is 'proportion of
usability problems while user testing' and "n" is the number of users.
Graphing this yields _'usability problems found'_ over _'number of test
users'_. ~ <http://www.useit.com/alertbox/20000319.html>

Joel goes further in his _"12 Step testing"_ and optomises Nielson`s method.
Joel reckons you should try to grab _anyone_ (one person, when you have
completed some code) who happens to be in the hallway to test your current
code ~ <http://www.joelonsoftware.com/articles/fog0000000043.html>

~~~
donna
re let users loose: --watching what a user does tells me whether i match up
with their expectation.

and thanks for the links!

~~~
bootload
_"watching what a user does tells me whether i match up with their
expectation"_

True I get this bit, "Where do you start?" I guess what I'm trying to get at
is _"How do you choose which area a user should look at and why?"_. Sometimes
it's good to let testers work undirected to see what problems they have & what
they use most often, first. Other times you might want specific areas of code
or functionality tested.

_"... thanks for the links! ..."_

The Joel 12 step is a classic to read & apply. It's based on reality and works
as a quick Yes/No tool to see how good a process is (good old _paratrooper_
Joel). It either works or it's defective & needs to be fixed.

------
rainsill
This is the power of feedback. Nice post!

