Paper Prototyping: User Testing Right Out of the Box

I was obsessed with cardboard as a kid. I could build anything.

Forts, trucks, spaceships… Swords were definitely a favourite.

Cardboard was a medium I could use to build whatever I wanted. More importantly, I could build it QUICKLY.

With some questionably safe exacto-knifing, a door appeared in a large box that became a fort, a spaceship got flaps and hatches, or the cardboard sheet turned into He-Man’s Power Sword.

But I think the best part was when I held the finished product in my hand.

I could climb into the fort and shut the door. I could lift the spaceship and it would fly. I could challenge my friends with my freshly forged cardboard sword. For many reasons, the latter was my favourite.

My friends and I would wage war on each other with our corrugated creations. Inevitably they would break — so it was into the recycling bin for the weapons and back to the drawing board for us. We’d spend hours reinforcing this piece, cutting off that part, and then back into the fray we went.

So, I guess it isn’t shocking that I love paper prototyping.

I was introduced to paper prototyping in my Interactive Multimedia post-grad at Sheridan College. In one of our first UX classes, our instructor showed us how quickly we could create an app with a marker and a notepad.

I was hooked.

I had a preconceived notion about design being a long, drawn-out process with rough drafts, concepts, approvals, etc. This approach did away with all that. All that mattered was finding the best way for the user to accomplish a specific goal.

So, what is a paper prototype?

A paper prototype is a disposable design that is built to solve a problem. It is a series of frames roughly drawn out in such a way as to represent an application at its most basic level. When you’re creating a paper prototype, you’re building the interaction — not focusing on the design.

Each page represents a different screen or step in a flow. So if you were creating a prototype for a registration process, you might do something like this:

There, you’ve got a basic flow. Each page gets only the essential elements it needs — buttons, text, a quick shape to represent an illustration. Now it’s time to test it.

Your first “test” is when you, yourself, are creating it. When you’re holding a paper prototype, you can feel it in your hand. Take yourself through the whole flow, interacting with the prototype as you would with a real device. Each time you tap a button, swap out the current screen for the next one that you’d expect in the flow. Repeat the process until you’re comfortable with how everything is coming together.

Now, grab some extra materials and find some users to test your prototype.

Show users your prototype. Ask them to interact with it. As they tap, scroll and swipe, bring in the next piece of paper. You are the operating system. At the same time, you get to see the problems the users are having.

Between each user test, go through your flow again. Find the screens your users had trouble with. Pull them out. Break them down. Simplify. Scribble out a new screen and swap it in. Does it make sense? Do you need to adjust any other screens because of this change? Now, test it again.

The beauty of this approach is how quickly you can add and remove elements. Paper prototypes don’t need to be uploaded or deployed. They don’t rely on internet access and they don’t crash. They help find problems in real-time with very little time and cost outlays.

So grab a marker and a notepad and get started!