Before writing code, it’s important to understand how people will interact with the system you’re designing.

One of the simplest and most effective ways to do this is through paper prototyping.

Paper prototypes are inexpensive, quick to create, and easy to modify. More importantly, they allow clients and users to interact with your design long before any software has been built.

Because changes can be made in minutes instead of hours, paper prototyping helps teams discover problems early, when they are easiest and least expensive to fix.

What Is A Paper Prototype?

A paper prototype is a low-fidelity model of a software system created using simple materials such as paper, pens, sticky notes, and markers.

Each page typically represents one screen of the application, while additional paper components represent menus, dialog boxes, buttons, or other interface elements that appear as the interaction unfolds.

Unlike a finished interface, a paper prototype is not intended to look polished.

Its purpose is to help the design team explore ideas, discuss workflows, and test whether users can successfully complete common tasks.

Focus On The Process, Not The Artwork

A successful paper prototype is not judged by how attractive it looks. It is judged by how well it represents the process that users follow.

Consider your morning routine before leaving for school.

One possible sequence might be:

Wake up → Brush your teeth → Shower → Get dressed → Put on your shoes → Leave for school

Someone else might perform these activities in a slightly different order, but there is still a logical sequence of steps that allows them to accomplish their goal.

Software works in much the same way.

Users follow a sequence of actions to complete tasks such as:

• creating an account,
• placing an order,
• submitting a report, or
• updating their profile.

A paper prototype allows the design team to explore these workflows before implementation begins.

As users interact with the prototype, they often reveal assumptions, misunderstandings, or missing steps that were not obvious during earlier design activities.

Why Paper Prototypes Work

Paper prototypes encourage conversation. Instead of asking clients or users whether they like an idea, you can observe how they actually attempt to complete a task.

As they interact with the prototype, they may:

• hesitate before choosing an option,
• become confused about what to do next,
• expect information to appear somewhere else,
• suggest a better workflow, or
• identify functionality that has been overlooked.

Because the prototype is intentionally simple, changes can often be made immediately during the session.

This rapid feedback makes paper prototyping one of the most valuable design activities in the early stages of a project.

Running A Paper Prototyping Session

A paper prototype becomes most valuable when it is tested with real users.

These sessions are designed to evaluate the prototype – not the user.

Your goal is to learn how well your design supports the tasks users are trying to accomplish.

Assign Roles

Before the session begins, each team member should have a clearly defined role.

Prototyping roles include:

• Facilitator – welcomes participants, explains the session, presents each task, and guides the discussion. Once testing begins, the facilitator should be the only team member speaking directly with the participant.
• Human Computer – updates the paper prototype by replacing screens and interface components in response to the participant’s actions.
• Observers/Notetakers – watch carefully, record observations, and document questions, confusion, comments, and suggestions.
• Participant – attempts to complete each task while describing their thoughts aloud.

Encouraging participants to “think aloud” provides valuable insight into how they interpret the interface and why they make particular decisions.

Prepare Your Scenarios

Before inviting participants, identify the use cases you want to evaluate.

Each use case should have a corresponding set of paper screens that allows the participant to complete the task.

As your team prepares the prototype, ask yourselves questions such as:

• What should happen if the participant selects this button?
• What if they choose an option we didn’t expect?
• Do we have every screen needed to complete this task?

Run through every use case as a team before the session begins.

Doing so often reveals missing screens or unexpected situations that can be addressed before testing starts.

Keep the interface simple.

The purpose of the session is to evaluate the workflow – not to impress participants with artistic ability or elaborate paper mechanisms.

Practice

Before meeting with participants, practice running the session several times.

The Human Computer should know exactly where each screen is located so that transitions appear smooth and natural.

Like any presentation, preparation makes the session feel more realistic and allows the team to focus on observing the participant rather than searching through stacks of paper.

During The Session

Begin by welcoming the participant and explaining what will happen – and what you expect from them – and what they can expect from you.

Ask them to complete each task while saying everything they are thinking.

Reassure them that there are no right or wrong answers.

You are evaluating the design – not evaluating them.

As the participant works through each scenario:

• avoid explaining how the interface works,
• avoid giving hints,
• avoid confirming whether they have made the “correct” choice, and
• avoid using body language that might influence their decisions.

If the participant becomes confused, encourage them to describe what they expected to happen instead of directing them toward the correct action.

Unexpected behaviour often provides the most valuable feedback.

Finally, document everything. If you would like to record the interaction, you must first receive consent from the participant.

Comments, hesitations, mistakes, and questions all help identify opportunities to improve the design.

After The Session

Once testing has finished, the team should meet to discuss what they observed.

Look for patterns rather than isolated comments.

Consider questions such as:

• Which use cases worked well?
• Where did participants become confused?
• Which parts of the workflow seemed natural?
• What functionality appeared to be missing?
• Which suggestions were made repeatedly?

The purpose of this discussion is to decide how the prototype – and ultimately the system – should be improved.

In some cases, the feedback may lead to small interface changes.

In others, it may reveal missing requirements or identify the need for additional conversations with the client.

Activity: A Paper Prototyping Example

Consider the video below – which shows an example of paper prototyping. Based on what you have learned in this chapter, do you believe this represents a good example of a paper prototyping session. Why, or why not?

Looking Ahead

Paper prototypes provide a fast, inexpensive way to explore workflows, validate assumptions, and improve designs before implementation begins.

Although they are intentionally simple, they often reveal problems that would otherwise remain hidden until much later in the project.

In the next chapter, we’ll explore another prototyping technique that allows us to move from hand-drawn sketches toward more structured and interactive interface designs.