Pick random people? Use a service like usertesting.com? What do you do?
5 Answers
The type of users you need to recruit for your tests are defined by your previous establishment of personas. You need to first research and establish the market you'll be addressing, and then define the profiles of the users that will be using them. Having this profiles or personas, you can start recruiting users.
You can read more about it here:
http://www.uxmatters.com/mt/archives/2010/10/using-personas-during-design-and-documentation.php
I just recently learned about the UserTesting.com service and it seems like an interesting option, but never underestimate the value of face-to-face testing. If you have the time, I suggest you conduct the test personally. If not, well, some testing is always better than none.
-
1I can't agree more, doing the test yourself mean that when it comes to writing the report and presenting the findings you have a detailed knowledge of all the participants comments and actions. Commented May 24, 2011 at 7:39
-
If you have the budget you can outsource the actual recruitment of users to market research recruiters, who will be geared up for recruiting specific types of users.– PhillipWCommented Jan 4, 2013 at 20:39
Steve Krug states in Don't Make Me Think that the dirty secret to recruiting users is that you can use almost anyone. Unless domain expertise is needed to understand the interface, testing it with almost anyone (within reason) will still give you valuable insights. If you have personas then test with people who represent those personas.
-
Hi cookingupsomethinggood. Welcome to the UX Stack Exchange! I appreciate the idea in your first post (+1), but it's generally a good idea to cite your source. I've gone ahead and edited your post for you (pending approval) to include a link to the source; you can edit it more yourself if you'd like. Commented Jan 5, 2013 at 0:25
Picking a few random people here n there is a good thing. It helps validate any personas you may have created.
I've had lots of success with the family and friends approach. Invite your family, your friends, colleagues etc to invite their family and friends. Provide a small incentive, like a book voucher and you can generally get enough users to do the test.
- I would recommend testing the product with the team involved in building (or developing) it. This performance measure can serve as a useful baseline for near-perfect performance with actual users. For example, if a developer involved in designing/building the UI takes 10 mins to accomplish your usability tasks whereas another user (in the field) takes 20 mins, then this user is performing at 50% efficiency when compared to an 'expert' user.
- Testing with developers will generate buy-in for the testing and for accepting the test results. There's always someone in the room (viewing user's struggling with an interface) who'll comment that a participant is too stupid to figure out the task.
- I also recommend maintaining a database of users who've participated in your tests for future studies.
- You can also host simple UIs for evaluation on Amazon's Mechanical Turk, especially if the tasks are self-contained.
-
Welcome to the UX StackExchange! Having a look over our FAQs (ux.stackexchange.com/faq) should help you to get familiar with the site. Commented Jan 4, 2013 at 19:46
-
I like your second suggestion. Do you have any source to support the numbers in your first one? I find that testing with people who are already familiar with software can give a very skewed picture of how other users might interact with that software, not just impact their efficiency. Commented Jan 4, 2013 at 19:46
-
I agree with you about performance metrics that might get skewed when you use the team that builds the product. The main advantage is that you can capture the most "ideal" usage as a baseline. The product builders (developers) tend to know the system inside out and generate very efficient workflows. I don't have published articles to support this approach but I've used it in multiple user studies and I've found that it gets better buy-in from developers .– anilCommented Jan 10, 2013 at 21:57
-
+1 for adding the comment about how recruiting from your own developers can generate buy in. Consider incorporating it into your main post. Commented Jan 11, 2013 at 1:02
I would strongly not recommend entirely random participants.
Consider:
Domain knowledge
e.g if it's a service for medical professionals, you will legitimately expect some knowledge of the medical jaron that random participants may not possess.
Mental models and preconceptions
e.g. if your service is for older people where use of digital social networks is less prevalent, testing with younger participants may not expose your older users lack of understanding of 'Share' buttons etc.
Credibility
Finally, if you have to convice other stakeholders to action findings from your tests, I'd reccomend using particpants they percieve as matching thier customer demographic. This eliminates the "well, they aren't our audience" objection to accepting legitimate findings.
Sourcing
Regarding where to actually find these people; I've had most success by advertising through my personal network on social media (the average persons has ~5 million 3rd degree FB a LinkedIn connections) and forums roughly corresponding to your user demographic, though of course you must become a trusted member of such communities first.