Paper prototypes are low-fidelity prototypes used to understand the system flow from the user’s perspective. A paper prototype is made with paper, pens, pencils, markers, and sticky notes, and reflects a series of use cases that a user or client might want to perform with the system. They are low-cost and easy to develop and modify in real time based on client or user feedback.

It’s Not About The Pretty

As mentioned, a paper prototype is a low-fidelity prototype that allows the designer to communicate their vision of the user interface with the client and the user. A paper prototype allows the designer to demonstrate their understanding of the process flow the user or client will follow to complete a task.

What do we mean by process flow? Consider the example from our discussion on dependencies that presented things one might do before one heads to school in the morning. A process flow is the usual way to complete the activities and achieve a desired goal.

In our waking up in the morning example, the process flow might look like the following:

• Wake up > brush teeth > shower > put on shirt > put on socks > put on pants > put on shoes > go to school

Of course, you might shower before you brush your teeth, so your process flow might differ. You might also put on your pants first, then your socks, followed by your shirt. But, it’s more than likely that you put on your shoes after you’ve put on your socks and pants. And you probably don’t put on any of these things and then have a shower.

There’s a process that you follow in the morning when you are getting ready to head to school. And even though your process flow might be slightly different than another person’s, you can see where we might group things based on common behaviours and use this information in the design of a system.

Similarly, there are likely processes that users and clients follow or expect when they interact with the system you are helping to build. These processes may be based on regular workflows (e.g. add a customer to the system, add their address and billing information, add their order, process their order, send a receipt), or they may be based on user experience (e.g. ask the user only for a username and password so that it can be validated and vetted before asking the user for address and contact information details). Wherever they come from, we must understand these processes to the best of our ability to develop a system that reflects them.

A paper prototype encourages discussion about these processes with the client and users. It allows us to verify our understanding of the system and the process flows by observing the client and users interacting with the prototype directly. Feedback from the users and clients as they interact with the prototype can be used to change the prototype on the fly.

Finally, because the paper prototype is low-fidelity, it means that it can be used to ensure an understanding of the system at all stages of the project. It doesn’t have to be used just once in the early stages. A paper prototype allows us to test the usability of our design because it forces us and our users to confront the process flow. It can also help identify requirements that we may have missed.

Of course, paper prototyping requires more than just a prototype made 
of paper. 
Paper prototyping also involves running a paper prototyping session.

A paper prototyping session allows you to connect directly with your client and users to verify your understanding of the problem. It is also a great opportunity to clarify any misconceptions, build rapport with your client, and identify where you might improve the design based on the client or user feedback.

Running A Paper Prototyping Session

Assign Roles

Before you can conduct a paper prototyping session, every person must have an assigned role. Roles include a facilitator, human-computer actors, observers/note-takers, and the user or client.

Facilitators welcome the user/client to the session, introduce the other team members, and describe the session to the user. They provide the rules for the session, answer any initial questions, and then introduce one use case at a time to the user/client. They are the only team members who will speak directly with the user/client once the session begins.

Human-computer actors respond to the user/client by replacing/adding “screens” or “system responses” based on how they have interacted with the prototype (e.g. “clicked” a button). Note-takers observe and document how the user/client responds to each use case – where they get stuck, assumptions they make, things that work, things that don’t, recommendations, etc.

The user/client interacts with the “system” by speaking aloud their thought process when asked to complete a use case. They will likely initially find this awkward, but it’s an important part of the process. The facilitator is responsible for encouraging the user/client to speak aloud.

Prepare Test Scenarios

Before you host any users or clients you need a paper prototype for each use case you wish to present. While you do this, consider how the user might interact with the prototype and ensure that you have “screens” you can use to provide a “system response”. For example, what will you do if your user clicks on something that isn’t part of the use case you are interested in, and you haven’t developed “screens”? You could, perhaps, create a 404 error page, or an “under construction” page.

As a team, you should test all your use cases to ensure you have all “screens” and “system prompts” necessary. Of course, do not overcomplicate your user interface. Consider the content on each screen, and the process flow, and keep it simple. Further, students in the past have decided to create components in their prototype that you might find in a child’s pop-up book (such as accordion drop-down menus, pull tabs, and more). This is unnecessary and often will cause problems in practice so it is best to avoid these types of fancy features. Remember, your prototype is about the process flow and not whether or not it looks pleasing to the eye or is fun to use.

As you develop your list of use cases, consider how you will present these to the user/client. Begin with the simplest of your use cases, and then grow the complexity as the user becomes accustomed to the paper prototyping session environment. You can also have the user perform the same use case multiple times but with the system providing different responses. For example, if you ask the user to log in, the system could respond assuming the password they entered was correct or incorrect.

Practice, Practice, Practice

Once you have developed your prototype, your next task as a team is to practice. And then practice again. And then practice again.

The human-computer actors on your team need to be able to respond to the user/client as quickly and smoothly as possible. This means you must know where every “screen” is located in your stack of papers. As a team, you may want to have all your “screens” spread out on a large desk organized to allow the human-computer actors to respond quickly. Of course, don’t stress out if you stumble. This happens.

What happens if the user/client does something we weren’t expecting them to do?

Expect the unexpected as much as you can. And for those things the user/client does that are outside of what you expect, feel free to create “screens” on the fly. Work with the user/client to better understand what they expected to happen. The facilitator can do this by prompting them with questions like “What were you expecting to do here?”, “Do you understand the use case you’ve been asked to complete?”, or “What would help you complete this use case?” The note-takers should record all of this as feedback.

During The Session…

As mentioned, the facilitator should welcome the user/client to the paper prototyping session and introduce their team. At this point, the rest of the team can interact briefly with the user/client but will remain silent until the session has been completed. The facilitator is the only voice the user/client should hear after the session officially begins.

After introductions are complete, the facilitator will describe the paper prototyping session; specifically indicating to the user/client that they will be asked to perform certain use cases and that they are asked to describe aloud exactly what they are thinking/feeling as they complete the use cases. A short demonstration of what you expect of the user/clients might be helpful. The facilitator should inform the user/client that no team member will tell them how to complete a task.

At no point should the facilitator (or anyone else on the team) help or lead the user/client. This means that body language also needs to be controlled. Do not get excited if they do what you expect them to do. Do not look deflated if they do something you weren’t expecting. Do not nod, frown, or otherwise give away what the user might need to do. Remember, the goal here is to determine if you’ve developed a system that reflects and supports the process flow. Leading the user/client through the use case will not help you improve your system.

Of course, this does not mean that you can’t be friendly with the user/client, or that you can’t speak with them after the session is complete.

Finally, be sure to document everything the user says and does.

After The Session…

After you have completed your paper prototyping session, it’s a good idea to gather as a team to discuss what happened. In particular, this is the time to synthesize what you have learned. This may include the development of a post-mortem document.

Your discussion/document should include:

• A list of the use cases that were performed.
• A list of the users (which may include demographic information, and/or a description of their computer expertise, and/or other information that might help you weigh the information you’ve received from them).
• A list of what worked, what didn’t, and perhaps things you should stop doing, start doing, or continue doing (by use case). This may include a list of recommendations or additions to the system that you hadn’t expected or considered.
• A list of things (if available) that the user/client loved, hated, or recommended needed to be changed.
• A list of things that the user/client thought were missing.

This information should be compiled and used to identify how you might improve the system you have designed. It might mean introducing new requirements or having further conversations with the client.

Check out the video below, then consider whether or not this is a good example of a paper prototyping session. Why, or why not?

Review Questions