Despite the strength of modern design tools, we still keep a pencil and paper in our arsenal. Sketching is a great way to think about ideas spatially.

They’re quick and cheap to produce and encourage rapid exploration. Scribbling down your ideas is also accessible; anyone can share ideas with people in their team before a designer starts finalising their UI designs.

As ‘creative’ people, designers can sometimes become too focused on making their sketches pretty. I’m guilty myself; after all, gorgeous sketches can make a fine addition to a portfolio case study. But sometimes this behaviour can veer into the time-wasting territory that is paper prototyping.

What are paper prototypes?

Paper prototypes are a way to test your design concepts without mocking up the interface digitally. You sketch how you imagine the screens in an interface to look, then you can move the screens around depending on ‘user input’.

There’s a difference between a sketch and a paper prototype. Sketches are rough and haphazard, used as a way to record your thoughts: paper prototypes are a design asset, crafted and perfected. The more complex ones can be moved and folded to simulate interaction.

An example of a paper prototype. Image source

Although they’re pretty and fun to make, they aren’t the best use of a designer’s time and energy. When you compare paper prototypes to their digital equivalents, you realise how inferior they are:

They aren’t quicker to build. Drawing, cutting, and building are all time-consuming. To build something neat and representative enough to be useful takes care and precision. In real life, there’s no undo function either. Digital prototypes upstage paper sketches when it comes to quality and time to build.
They’re delicate. Paper is easy to crease and tear. It’s prone to folding and spills, which means finding somewhere safe to keep it isn’t practical. And when you do recycle it, it’s gone forever.
They aren’t shareable. The entire point of building a prototype is to get feedback on it. Now that more people are working remotely, how easy is it to share a paper prototype with everyone in your product team?
They discourage realistic design. When you design digitally, you’re constrained by things like existing patterns and libraries. This is often a better strategy for both business and developer needs as it makes building new features quicker and less prone to bugs. A blank piece of paper is too big of an open field and getting creative can distract you from your initial design target.
They narrow your thinking. Your paper prototype will only show a single happy scenario. How do you consider edge cases like a dropped internet connection or an unresponsive phone? What about if someone wanted to take an alternative route to complete their goal?

Several sources I’ve found also encourage designers to bring their paper prototypes into testing sessions to show users. This can be a great ego boost for designers (look at how creative we are!) but the quality of feedback will suffer for it.

An example of a team testing with a paper prototype.

You can see from this video that the user is focused not on the product, but on the show the researchers are performing around him. He chuckles at the loading animation. He playfully wiggles the bits of paper. He pauses to think rather than relying on his natural behaviours, as he likely would do when using his phone.

If you test a paper prototype with your users, they aren’t going to give you any kind of useful feedback. It’s clear that you’ve spent a long time building the prototype and they won’t want to offend you, so their responses will be watered down and complimentary.

Your participant will also have had to imagine the design’s interactions. You’ll never build things like overlays and screen transitions accurately with paper, no matter how much time you spend on it. Your paper prototype will always be too abstract.

The perils of abstraction

In computer science, abstraction is defined as:

the process of removing physical, spatial, or temporal details or attributes in the study of objects or systems to focus attention on details of greater importance

You know that these are all cats, but the photo gives you information you’d never get from the illustrations.

For product design, this means removing details or functions from our prototypes. We usually take the complex features out first. Things like text input and micro-interactions take too much time and effort to replicate. Omitting details for the sake of time is fine, but it’s always a compromise.

Making your prototypes more realistic reduces the amount of extra thinking you need to do to understand the product. Adding basic colours and images gives you an idea of the product’s context and tone. Being able to tap and explore answers questions about functionality and flow.

The previous abstraction principle applied to interface design.

When you look through the examples above, you can see the difference realism makes. It looks about as good and functional as a real product, which makes it easier to compare to systems you’ve seen and used before. When your reactions are grounded in reality, the feedback you give will be more relevant and accurate.

The difference between a paper sketch and a digital wireframe is not just how they look. Seeing something on a phone or laptop rather than on paper can change how you connect with it. Test this out yourself. Print out a webpage and feel how your mind processes it. There’s a level of abstraction when you have something digital on paper, and your brain has to work a little harder to process it.

This one just hits different… Image source.

In a testing session, how your participant interacts with your interface is just as important as what they say aloud. You want to see what they try to do with your interface and how they react when it responds to their touch. The problem with paper prototypes (or any prototype) is that too much abstraction will hide these insights from you.

Paper will never be able to replicate digital behaviours. Holding a device on your hand and tapping is always going to beat jabbing your finger at a printout on a desk. If you’re building an interface for a website, you need to see it on a screen, and so do your users. The closer your prototypes are to the final product, the more accurate your test results will be.

Capture reactions, not feedback

As Jake Knapp said in his article on paper prototyping, high fidelity is a little harder but a whole lot better. When you’re testing your product, it should be as close as possible to realistic.

Your test participants should be convinced that what they’re using could be an actual product so they can give you their genuine reactions rather than telling you what they think.

Realistic doesn’t have to mean visually perfect. Finer details like element styling and typography can be refined further down the line. If you’re only testing interaction then build something basic; you can test again with the final UI later on if you think the results will be significant.

We have so many advantages now when it comes to building things quickly. Design systems and libraries make UI design easier and faster. You can automate basic interactions using tools like Figma.

Platforms like Marvel even allow you to build prototypes using uploaded photos. Even if you’re only on the first iterations of design, making it digital is a must.