Running a User Day

Testing with a Paper Prototype

The main purpose of a paper prototype is to analyze design ideas with test users as early as possible. The goal is to present a more or less realistic design to the user, while minimizing the cost of creating it, so that the developer is still willing to reject or modify the design if necessary. Paper prototypes are an ideal test medium for iterative design.

The use of paper prototypes requires some skill and much concentration. For this reason there should always be two interviewers whose roles must be explicitly assigned before the interview:

• Interviewer who leads the conversation with the tester and handles the paper prototypes.
• Person who logs the entire interview.

The roles can be swapped after a certain time or depending on the application area, but they should not be mixed randomly.

Creating Tasks

After briefly introducing the product idea and the basic principles for using a paper prototype, you should ask the user to process concrete tasks with the prototype. Prepare written tasks derived from existing scenarios if possible.

Starting with the given scenarios, you can ask the user to execute their own variant of the scenario, as in their usual daily work. As in the contextual interview (see Site Visits), you can ask for concrete work processes that the user performed during the last two weeks.

Interview Technique

During the test, a partner-like discussion should evolve in which together you check how well the tasks can be processed with the prototype.

Three basic principles are important when testing with a paper prototype:

• Try to define scenarios that resemble the testers’ normal working practices as closely as possible.
• Address every problem and suggest a redesign. Do not ask the tester how to do it better. If the tester accepts the suggestion and it can be integrated easily, change the prototype immediately (for example: OK, we will now draw a pushbutton here).
• Constantly try to interpret the (non-verbal) reactions of the user and to question the accuracy of your own interpretation (for example: I have the impression that you would prefer to have these two functions together in one context.)

Log

The person writing the log must record all observations, design suggestions and problems. It is also important to write down basic findings about the tester's working practices. The prototype can be used here as a guide.

Important feedback from the tester should be recorded on the prototype itself.

Source:  User Day Toolkit