Paper prototypes are low-fidelity prototypes that are used to better understand the flow of the system you are designing, and more specifically, to understand the flow of the system from the point of view of the users. 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, relatively easy to develop, and easy to 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 a designer to communicate their vision of the user interface with the client and the user. More specifically, a paper prototype allows the designer to demonstrate their understanding of the process flow that the user or client will follow to complete a set of tasks.

What do we mean by process flow? Consider the example from our discussion on dependencies that presented a bunch of things one might do before one heads to school in the morning. A process flow is the usual way in which one might carry out the activities that will allow them to complete that task.

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 be the type of person who typically showers 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.

The point is, 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, you can see where we might group things together 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, it is our responsibility to ensure that we understand these processes to the best of our ability so that we can develop a system that reflects it.

The benefit of the paper prototype is that it encourages discussion about these processes with the client and users. Specifically, it allows us to verify our understanding of the system and the process flows by providing an opportunity for the client and users to interact 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 also provides us the opportunity to test the usability of our design, because it forces us and our users to confront the process flow. It can also be helpful in identifying 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 is an opportunity for you to connect directly with your client and users of the system to verify your understanding of the problem. It is also a great opportunity for you 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, it’s important that every person has 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 members of the team, and describe what is about to happen. They provide the rules for the session, answer any initial questions, and then proceed to introduce one use case at a time to the user/client. They are the only members of the session 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 a very important part of the process. It is the facilitator’s responsibility to encourage the user/client to speak aloud.

Prepare Test Scenarios

Before you host any users or the client, it is absolutely essential to develop a paper prototype for each of the use cases 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 for which 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 of your use cases to ensure you have all of the “screens” and “system prompts” necessary. Of course, do not overcomplicate your user interface. Consider how much content is on each screen, consider 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 to present, be sure to 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 responding in different ways. For example, if you ask the user to log in, the system could respond assuming the password they entered was correct, or that it was incorrect.

Practice, Practice, Practice

Once you have developed your prototype to address each of the use cases and test scenarios that you want to present to the user/client, your next task as a team is to practice. And then practice again. And then practice again.

The point is that the human-computer actors on your team need to be able to respond to the things that the user/client does as quickly and as smoothly as possible. This means you will need to know where every “screen” is located in your deck of screens. As a team, you may want to have all of your “screens” spread out on a large desk that has been organized in a manner that allows the human-computer actors to respond quickly. Of course, don’t stress out if you stumble or if things go a bit off. This happens.

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

To be honest, expect the unexpected as much as you can. And for those things the user/client does that are outside of what you are expecting, feel free to create “screens” on the fly. Work with the user/client to better understand what they were expecting 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 previously, 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 otherwise will remain silent until the session has been completed. That is, 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. If there is time, a short demonstration of what you expect out of the user/clients might be helpful. The facilitator should inform the user/client that no one on the team 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, nor 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 work, 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 recommend 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 that you need to introduce new requirements, or have 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