Paper Prototyping is an integral part of the iterative design process that allows website designers the ability to iterate rapidly and inexpensively. In paper prototype testing the user interacts with a paper mockup, or prototype, of the product as if it were real. For the purposes of this article we'll limit the scope of paper prototypes to website interfaces, but paper prototypes can also be used to test the usability of forms, applications, and even 3 dimensional objects. Testing with a paper prototype is appropriate for rapid design iteration: it will allow you to get a good picture of how users will interact with your interface without having to spend any money or time on writing code. Although it is such a fast and easy way to elicit user input many design teams still don't use it. Jakob Nielsen thinks this is because "people don't think they will get enough information from a method that is so simple and so cheap. It feels like you're cheating." (http://www.useit.com/alertbox/20030414.html) This method of usability testing does have some limitations, however: it creates an artificial user environment that can influence the way users interact with the prototype, so it requires a skilled usability tester. Also, it can sometimes be hard to sell test results to stakeholders, especially when using quick and unsophisticated prototypes. Empirical evidence exists, however, that there is little difference in results between high fidelity and low fidelity prototypes. (Virzi, et al., 236) Paper prototype testing is most useful in the earliest stages in the design process, especially in the concept phase. When testing existing web interfaces, live testing is more appropriate.

In most situations, a paper prototype is an unsophisticated sketch of the user interface, with little or no functionality. The most elaborate paper prototypes are fully designed graphic renderings of a real web interface with graphic designs of underlying pages in the website, allowing the usability tester to reveal to the test subject where they will be taken when they "click" on a link, button, or navigate in the site. The usability tester functions as both the tester and the computer, turning pages when there are multiple prototypes. Where there is just a single interface to be tested, the tester asks the subject to elaborate on their choices: "you clicked on this link because? What do you think will happen? Where will this take you?" This helps the design team determine if they have a match between the system and the users expectations, or mental models. While a quick prototype may look unsophisticated in comparison to full color mockups, it can be much more flexible in the hands of an experienced usability tester.

When setting up a paper prototype test you should use the same methodology you use when doing other types of usability tests. There are 4 major steps involved: identify the user groups, define key tasks, test the test (refining if necessary), and present results. Identifying your user groups will help you define key tasks for the website or page. For example, when testing a series of search interfaces for finding scholarly articles there may be more than one intended user group involved: a basic search page may be intended for undergraduates and novice searchers, while an advanced search page may be intended for more advanced searchers like graduate students, faculty and librarians. Obviously the key tasks should reflect the level of sophistication of these users and the tasks we assume they will use these pages to perform; where a basic search interface task may be to find an article on nuclear war, an advanced task may be to find a specific citation to test for the functionality of field searching in the design. Testing the test with other usability team members can help you find flaws in your methodology or technique.

Once you have determined your user tasks and are satisfied with your protocol you can work on the development of your paper prototype. A prototype can be a simple wireframe, or drawing, of your interface sketched out in black marker or pen. You can use a variety of stroke widths for emphasis if those are elements you want to test, otherwise the site can be sketched out with the same pen. You can underline links if that is a feature of your site or you can ask your user to make assumptions by telling you that it is a link when they select text or a screen element. Mathew Klee suggests you use "the 'incredibly intelligent mouse' -- a fancy way to say we let the user decide what's a link simply by following their behavior." http://www.uie.com/articles/prototyping_tips/ (Klee, 3) Buttons can be represented by sketched rectangles, areas of text that are not essential to the design can be represented by squiggly lines, and form elements, such as text boxes and drop-down menus can be sketched in with default values written in. Prepare post-it notes with drop down menu choices ahead of time so that when those elements are selected you can "open up" the menu by pasting the post-it on the page. You can also use fully rendered graphics of the interface, but these take more time to produce. Try to anticipate any possible interaction that a user may have with the prototype so that you can be prepared to make the test as authentic as possible by showing them the result of their action. You may need to make prototypes of a number of pages in your site to get accurate test results.

When testing users with paper prototypes you should use the same techniques that you use with other user tests. Put your users at ease by reminding them that you are testing the interface or design and not their skill at Internet searching or computer use. Actually, the use of paper prototypes can be an advantage in this respect: users with computer anxiety will be relieved not to have to sit in front of a "live" system and there is no possibility of system failure. Try to approximate your system as much as possible to get the most from your test: Use a paper with an hourglass, working symbol or other text or graphic to represent response time when transitioning between screens if your live system has a long response time between actions. Encourage your user to use their index finger or pens to represent their mouse clicks and to describe their actions and assumptions as much as possible: "When I click this link I think I'll go to ...". Try to be as objective as possible; it can be difficult to act as the "computer", especially when users ask you direct questions. Remind them that you are the computer and ask them to continue speaking out loud so you can elicit more information about their problem. For example, in a test where the user asks you "This is searching x database, right?" you could respond; e.g. "I can't answer that now, remember, I'm the computer, but continue to speak out loud and tell me where you think you are and where you're navigating to so we can design a system that matches your expectations".

If you are testing forms you can have them write their text input directly into the forms; Xerox copies of your prototypes will ensure that you have an ample supply of fresh copies for subsequent users. Alternatively, you can have transparencies available for users to cover the prototype so that it will be "refreshed" for the next user. When users select the arrow next to a drop down box you can paste the prepared menu over the text box and have them continue to select menu items. Presenting prototypes of search results pages can be tricky: it can be impossible to predict the search terms entered by users but a prototype of the results page should represent the important elements presented in search results. The average user is usually savvy enough to make the stretch. The Neilson-Norman Group has an excellent DVD available that demonstrates many of these techniques and shows several live tests. http://www.nngroup.com/reports/prototyping/ (Paper Prototyping)

Finally, present results in a way that is most meaningful to the design team. In her book Paper Prototyping author Carolyn Snyder offers some good advice: "It's important for observers to record data in a form that won't be subject to contentious debate later. It's natural for us to filter information through our own set of ideas and prejudices, but this subjectivity means you're now dealing with opinion rather than data...." (Snyder, Chapter 11) Don't report on inconclusive results; it will just diminish the effectiveness of clearly discovered flaws in the design. Additionally, don't infer user actions; ask users for clarification when they pause or hesitate so that you can validate your observations. If you videotape your tests or use usability software with video/audio presentation software components then presenting clips of the most problematic parts of the user experience is extremely effective. Since this is a rapid iteration technique brief reports are appropriate. New prototypes can be designed that address the most important usability issues and the design can be retested. Because testing with a paper prototype allows the design team to iterate rapidly, major design flaws can be caught before they are passed along to the development team, saving both time and money. This is one of the most important reasons to add paper prototype testing to your web development toolkit.