Cheap User Testing (via Steve Krug)

The book "Don't Make Me Think" has a simple mechanism for doing user testing "on the cheap", we used it to some good purpose and someone asked me about it at TorCHI, so here's a summary:

  • do user testing approximately once per month or once every two weeks
    • recruit users as closely as possible to your target market, but don't worry if you can't get exact matches
    • offer testers an honorarium of $50 or so
  • write descriptions of tasks for users
  • do *not* use any terminology from your application, if possible explicitly use synonyms rather than text that appears in your interface
  • describe what the putative user wants to accomplish, not what steps to take
  • pay attention here, as if you describe *what* to do you will invalidate much of the testing
  • print out the instructions on a piece of paper
  • setup a test machine in a quiet place (e.g. a conference room with a net connection)
    • install vnc server on the machine, share the session with a machine where the devs will be sitting
    • install skype (or similar software), connect between the machines and mute the devs' machine (so that the devs can listen)
  • schedule 1 morning for the entire dev team for the first tests, test the basic functionality of your application
    • after the first test you can likely reduce to a couple of senior (dev) people who can make decisions about prioritizing bugs/issues
    • Note: *not* just QA people, devs/designers need to *see* users struggle to really appreciate how hard it is for people to understand their "perfect" designs
    • you want senior people so that they can decide in a brief meeting after the testing as to which items to prioritize without needing to argue in committees
  • for the actual testing
    • make it clear to the user that the software is the thing that's wrong, and that if they can't figure something out it's *your* fault, not theirs, they are helping you
    • do not step in immediately if there are problems, let the user know that you're going to try to see if they can work through problems, but that you will eventually step in if there are problems
    • ask the user to "think out loud" as they work through problems
    • inform the user that the devs are listening
    • recording isn't of much use, you can skip it (no one ever seems to want to review the recordings)
    • devs listen to the session and watch the user's mouse on-screen
    • devs should take notes

    the results of real-world user testing will surprise you. Particularly when you test with users who are uncomfortable with computers you will be floored at just how much you assume in designing your Web 2.0 interfaces... hip-cool university students understand them perfectly while uncomfortable users just don't understand that a "tab" means there's something "hidden" behind the current page (for instance).


    Comments are closed.


    Pingbacks are closed.