Why You Need to Test Your Web Site with Real Users | 2 | WebReference

Why You Need to Test Your Web Site with Real Users | 2

12

Why You Need to Test Your Web Site with Real Users

Organizing a user test

I suggest that you choose a Web site (neither your own, nor one you are very familiar with) to practice these steps on, before looking at your own site, with which it's more difficult to be objective.

  1. What is the purpose of this site? Ask yourself what it's trying to do: is it a mixture of expression (of a brand, community or personality), creating relationships with visitors, providing information, and perhaps selling and/or delivering a product or service? Note: Different people will often have different ideas of the site's purpose.
  2. Who are the users of this site? Ask yourself who will visit and what they will want to do; what's their level of knowledge of the subject; will they have visited the site before, etc. Also, think about how quickly they'll need results, whether for business or pleasure, and will they be doing specific tasks or browsing. You may need to consider Web literacy, visual or motor impairments, gender, cultural and age differences. Come up with a profile of one or more representative users - not every visitor, but enough to test realistically.
  3. What should be tested? Taking the results of 1 and 2, devise specific tasks. Begin with a simple one (like finding the street address of the organization), then choose a few realistic tasks. Write a plain description of the required result, not instructions on what to do. For example, "order a bouquet of flowers costing about $35 for delivery on Saturday," or "find out the prices of one-week self-catering holidays in June in Orlando" (not: "click on the search button").
  4. Who should test this site? If the profile comes up with several exclusive types of user, a test must be devised for each. But assuming you have a single user type, imagine how you could recruit people. Sources might be small ads, customers, friends, friends of friends, family, clubs or associations, work colleagues, or internal staff from an intranet. You may consider recruitment or market research agencies, but the response rate is usually better if there is a personal connection between the recruits and the test organizer.
  5. Where should the test be run? You must think about practical details of the venue (hardware, software, seating, internet connection, credit card numbers if requiring a purchase, provision of incentives/rewards, refreshments, toilet facilities etc.) There are companies offering test suites for hire, you can use a meeting room, or you may need to improvise.
  6. What should the observer say to the tester? Devise a simple script like the one below:
    • Greet the tester and explain why he/she is there;
    • Ask for permission to record if you will be doing so;
    • Set the tasks one after the other (hint: write task cards to give to the tester during the test);
    • Afterwards, ask for general reactions and any questions not covered in the test. Review what you have done so far, and ensure that the proposed test will find out what you want to know. So, are you ready to test?
    • Hold on: what happens if it's impossible to finish the tasks in a reasonable amount of time, or you forgot some vital part of the preparation? Ah yes – a rehearsal would be an excellent idea!
  7. How do I run a rehearsal? Find a friend or colleague. Do the whole thing as you would with a test user. Check the timing (tasks shouldn't take longer than an hour), and make any adjustments necessary.

Running the test

It's crunch time - you've done your planning, preparation, and practicing, so it's time to get out there and do it for real! Give yourself a whole day, or better yet, two half days to run the tests - it's difficult to remain fresh when you repeat the test for the fifth time. As well as time for the tasks, you need to allow for welcoming and debriefing, plus a short break to reset the computer and tidy up ready for the next test.

Some points to note:

Writing up the results

Observers' notes must be consolidated into a report detailing the problems encountered by testers, making comments on why they occurred, and perhaps how they could be solved. You'll need to interpret some of the findings using your own understanding of usability and the particular characteristics of individual testers. For example, testers less familiar with the site, or the Web in general, often have different problems than more savvy testers. As well as describing what went wrong for the users, the report can draw attention to similar places in the site where the same problems might be anticipated. On a positive note, it should recordany favourable comments made during the test or the debriefing.

Making use of the results

It's no good doing user tests if nothing happens as a result, so do all you can to make sure that action is taken on the results. You may be able to help by prioritizing items according to how long they'll take to fix and how much they'll improve the site. As with most such things, the 80/20 rule applies.

Conclusion

The ultimate purpose of your Web site should be to help your visitors find the information, product, or service that they want, quickly and painlessly. Professionals of all kinds find it difficult to put themselves in the shoes of ordinary users, so it is essential to ask users what their problems are. Although running usability tests will cost a few thousand dollars, an unusable commercial site will lose far more than that by driving away visitors. So, go for it!

# # #

About the author: Lois Wakeman is an experienced Web consultant and the principal of Site Usability (https://siteusability.com), which provides usability analysis services for Web site owners. Her personal site has a selection of articles and resources for Web developers at https://lois.co.uk/web/

12

This article originally appeared in the Jan. 11, 2000 edition of the WebReference Update Newsletter.

Comments are welcome


Revised: Jan. 12, 2001

URL: https://www.webreference.com/home/web/authoring/design/usability/testing/