User Testing Whirlwind Tour

672 views

Published on

A beginners guide to user testing, prepared for the National Digital Forum conference, Auckland, NZ, Nov 2008.

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
672
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

User Testing Whirlwind Tour

  1. 1. User testing – a whirlwind tour Courtney Johnston Web Editor / User Experience Analyst National Library of New Zealand courtney.johnston@natlib.govt.nz
  2. 2. BUILD ON USER RESEARCH
  3. 3. User research forestalls usability problems <ul><li>Ideally, user-testing should improve the design, not fix problems. </li></ul><ul><li>User-testing also shouldn’t be used to solve disputes within the project team </li></ul><ul><li>If you’re overhauling an existing site, run a survey, and ask respondents if they mind being contacted for a more in-depth interview </li></ul><ul><li>This will also help you recruit testing participants </li></ul><ul><li>Keep this info onhand for when you’re building a new site/service </li></ul>
  4. 4. DECIDING WHO TO TEST
  5. 5. Recruiting test participants <ul><li>Some is ALWAYS better than none, but 5/6 people should help you spot trends </li></ul><ul><li>Target audience is ideal, not necessary </li></ul><ul><ul><li>Colleagues not working on the project, friends, family, random people walking round your building </li></ul></ul><ul><li>Having said that, exceptions are: </li></ul><ul><ul><li>If you have a specific audience and can select from that group, do it </li></ul></ul><ul><ul><li>If you have several, divergent, audiences, try to get a representative sample </li></ul></ul><ul><ul><li>If topic knowledge is important to using the site </li></ul></ul><ul><li>Keep your invitation friendly, and make a small gesture of compensation </li></ul>
  6. 6. I LIKE TESTING ON PAPER
  7. 7. Testing with paper designs <ul><li>You can test an HTML version of your designs </li></ul><ul><li>But testing paper design work (or even wireframes) is just as effective, and much faster and cheaper </li></ul><ul><ul><li>Print off all the pages you’ll need </li></ul></ul><ul><ul><li>Give the participant a pencil & ask them to point where they’d click </li></ul></ul><ul><ul><li>Start them off on the first page, then supply pages as necessary </li></ul></ul><ul><ul><li>Give your recorder a set of pages, and annotate as you test. </li></ul></ul>
  8. 8. WRITING THE TEST SCRIPT
  9. 9. Writing a test script <ul><li>Pick a small number of key tasks and features to test </li></ul><ul><li>Keep leading words out of your questions (esp. if you’re testing whether people understand your labels) </li></ul><ul><li>Use scenarios: ‘Imagine you’re an X and want to do Y…’ </li></ul><ul><li>Start with a general intro to what you’re doing </li></ul><ul><li>Get some general info about how the participant uses the web and (if applicable) what their job/hobby/etc is </li></ul><ul><li>End by asking for any further observations, offering to answer any questions, and saying thank you </li></ul>
  10. 10. RUNNING THE TEST
  11. 11. Running the test <ul><li>Take at least two people along </li></ul><ul><ul><li>One to run the test, and one to record. An observer or two is fine, but don’t freak your participants out </li></ul></ul><ul><li>Remind participants they are testing the design for you (not being tested themselves) </li></ul><ul><li>Give tasks to participants one by one on bits of card. Ask them to read the task aloud before performing it. Make sure they’ve grasped the question. </li></ul><ul><li>Encourage participants to talk you through what they’re doing </li></ul><ul><li>Record both what participants SAY and what they DO </li></ul><ul><li>Let people ask questions, but hold answers off to the end if these will pre-empt later tasks </li></ul>
  12. 12. REVIEWING THE RESULTS
  13. 13. Debrief, discard, do stuff <ul><li>Don’t agonise over writing up the results. </li></ul><ul><ul><li>The issues that matter the most will become crystal clear during testing. Get together and talk about them as soon as possible. </li></ul></ul><ul><li>Focus on task completion </li></ul><ul><ul><li>Don’t worry too much if participants went a little astray, if they self-corrected quickly </li></ul></ul><ul><li>Don’t over-react to requests for new features </li></ul><ul><ul><li>Stick to what you know the site/service is there to do </li></ul></ul><ul><li>Do pay attention to the words people want to see </li></ul><ul><ul><li>e.g. ‘Sign up’, not ‘Get involved’ </li></ul></ul><ul><li>Rinse and repeat: fix problems, and test again. </li></ul>
  14. 14. Image credits <ul><li>Lego tower by Gran Neufeld http://www.flickr.com/photos/grantneufeld/16619185/ </li></ul><ul><li>Lego people by Joe Shlabotnik http://www.flickr.com/photos/joeshlabotnik/305410323/ </li></ul><ul><li>Hamlet by kevinthoule http://www.flickr.com/photos/kevint/89385801/ </li></ul><ul><li>Exam room by Kewima http://www.flickr.com/photos/kewima/19177334/ </li></ul><ul><li>Discussion group by fling93 </li></ul><ul><li>http://www.flickr.com/photos/fling93/206517587/ </li></ul>

×