What Do People Think of Your Site Design? Here's How To Find Out.

Usability testing is an essential part of the web design diet. In a nutshell, it's a technique for soliciting feedback on the design of a web site. Usability testing is usually conducted on one participant at a time, and attempts to have participants use the site in as close to a real-world setting as possible. Different people have different approaches to usability testing but two things remain consistent—the documents describing what you'll do during the test (the plan) and what came out of the test (the results report). This chapter describes the test plan—the document you prepare in advance of testing—.

This chapter is from the book

The usability test plan describes the goals, method, and approach for a usability test. The test plan includes several different components, from profiles of participants to an outline of a discussion with users. The test plan described here incorporates test objective, test logistics, user profiles, and the script.

Usability testing is an essential part of the web design diet. In a nutshell, it's a technique for soliciting feedback on the design of a web site. Usability testing is usually conducted on one participant at a time, and attempts to have participants use the site in as close to a real-world setting as possible. Different people have different approaches to usability testing but two things remain consistent—the documents describing what you will do during the test (the plan) and what came out of the test (the results report). This chapter describes the test plan—the document you prepare in advance of testing—and the next chapter describes the report.

There are several aspects of a usability test that need planning, and some people give each its own document. Other usability researchers create a single test plan, addressing all aspects of the test in a single document. This chapter will treat usability test plans as single documents, but will indicate where you might split the document if you need to have several deliverables.

Test Plans at a Glance

Test plans contain three main types of content: the purpose of the test, the logistics and methodology, and the script.

Unlike some of the other documents in this book, the test plan is usually long because it needs to be explicit about your method and what you're going to ask participants.

Figure 3.1 This table of contents for a simple test plan shows the high points: objectives, logistics, and essential scenarios. This plan may be appropriate for an informal test with a handful of users.

Figure 3.2 When usability tests become more complex, so, too, must their plans. This test plan has separate sections for facilities, methodology, and user profiles. It also distinguishes between user profiles—high-level descriptions of the target audience—and the screener, as well as from a series of questions for recruiting participants. Finally, this test plan also has two sets of scenarios, one for each group of users.

Test Plan Overview

Purpose—What are test plans for?

As much as we'd like to grab a few people off the street, sit them in front of our work, and shove a microphone into their faces, usability testing requires a little more planning. The purpose of the test plan document is to lay out the approach for a usability test. Test plans help set expectations for the kinds of feedback the design team will receive and help everyone agree on the aspects of the design that need testing. The test plan also prepares the team member who will be conducting the test, establishing a direction for his or her conversations with end users.

Audience—Who uses them?

Everyone on the team benefits from usability test plans. The person conducting the test gets the most benefit by far because the test plan will direct conversations with end users in a meaningful way. Even if you're not conducting the test yourself, your involvement in preparing the test plan will ensure that your concerns will be addressed during testing.

Scale—How much work are they?

The usability test plan is one of those documents that always takes longer than anticipated to prepare. You can put a simple one together in a couple of hours, but feedback from the team will inevitably identify additional concerns—everything from logistical problems to additional questions for users. Because usability testing directly involves customers, stakeholders usually want to get involved, which can extend the timeline for putting a plan together.

Context—Where do they fall in the process?

The real question here is when to do usability testing, and that can vary depending on your methodology. Most people save usability testing for the end of the project, or do it at strategic points throughout the design process. The bottom line: Whenever you schedule usability testing, you must allocate some time to put a plan together. Keep in mind that the organizational roadblocks to planning a test are significantly lower than those for conducting a test—the prospect of talking to customers can give some stakeholders cold feet—so it might be weeks or months between the planning and the doing.

Format—What do they look like?

For better or worse, the usability test plan hasn't evolved much in the last 10 years. Unless you're working with a particularly innovative team, you'll find that usability test plans are straight prose documents, usually prepared in a word processor.

Challenges

Though planning a usability test is fraught with challenges—logistical decisions, keeping the scope of the test in check, varying the script for different user groups—the main challenge with the test plan itself is creating a multipurpose document. This document will be used for discussing the plan with stakeholders and team members, and for conducting the actual test.

Perhaps the easiest way around this challenge is to prepare two separate documents—the test plan and the test script. Preparing two documents, however, comes with its own set of risks. Two documents means related content in two different places and two version histories to track. Perhaps these are trivial issues for you. Over the years, however, I've found it easier just to combine the documents.