Let Your Customers Build Your Business(ducttapemarketing.com)
ducttapemarketing.com
Let Your Customers Build Your Business
http://www.ducttapemarketing.com/blog/2007/07/03/let-your-customers-build-your-business/
4 comments
re let users loose: --watching what a user does tells me whether i match up with their expectation.
and thanks for the links!
and thanks for the links!
"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.
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.
This is the power of feedback. Nice post!
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