7 myths about paper prototyping
Myth 1: “I can’t draw well enough to create a paper prototype.”
When given a pencil and paper, most people (myself included) will tend to doodle words rather than draw pictures. Art was never my subject at school, so when I see wonderful, artistic renditions of user interfaces, I tend to feel somewhat humble. I can’t draw like that, my inner voice reminds me, so don’t pretend you can sketch a user interface.
But just because its on paper, it doesn’t mean it’s a paper prototype.
A paper prototype is a sketch — a quick visualisation of your idea. The artistic merit of your sketch is irrelevant. The purpose of paper prototyping is to evaluate the idea behind the user interface, not the sketch itself. Paper prototypes are quite literally ‘artless’: simple and unaffected.
This focus on ‘neat and pretty’ is one of the biggest obstacles to overcome with paper prototyping. It has even spawned a real industry. For example, search the web and you’ll find imaginative stencil sets for iPhone, web, iPad and Android. These kind of tools simply feed the paranoia of people who worry their sketches aren’t pretty enough.
Myth 2: “Wireframes are the same as paper prototypes.”
Wireframes show a skeleton view of a user interface. They identify the areas of the screen where content will appear, such as images, text and navigation. Wireframes often include call-outs and notes explaining certain elements of the design in more detail. They are a useful communication tool for design agencies who want their clients to sign off on a design without getting hung up on the colours and images displayed in the user interface.
But wireframes don’t work as paper prototypes for at least two reasons:
- They encourage too much focus on the layout of pages. As a consequence they can attract nitpicky feedback on issues like alignment and fonts. In the early design phase you’re more interested in the navigation, workflow, terminology and functionality than in details of the visual design.
- Wireframes are usually produced towards the end of the initial design phase, not at the beginning. At this point, many important design decisions — about functionality, for example — have already been made.
Many information architects are obsessed with wireframes but in most projects, they aren’t needed: they are just a bureaucratic overhead. You’ll find that an electronic prototype, modified as the project progresses, provides a much more useful design communication tool than a wireframe.
Myth 3: “I can do it just as well with Visio.”
I’ve often heard developers object to paper prototyping because they can mock up an interface in Visio, or another favourite tool, in the same time it takes to sketch one out. Developers point out that electronic prototyping scores over paper because it is easier to cut and paste repeating elements (like navigation bars) rather than go through the exercise of re-sketching them. And electronic prototypes can be shown to users over the Internet and tested remotely.
Ironically, ‘cut and paste’ is exactly what paper is good for — you just need real scissors and glue. You can quickly duplicate elements of a paper prototype with a photocopier or even mock-up the repeating elements in Visio and glue them to your sketched user interface. (If you’d like a starter kit, download and print our paper prototyping helper kit. This provides more flexibility than a stencil yet doesn’t express the same imperative to draw neatly).
Similarly, paper prototypes can be tested remotely: you simply scan in your sketches and chain the screens together in PowerPoint or Keynote. You can even record the sessions with usability testing software like Morae.
There is certainly a time for prototyping with electronic tools — but that time isn’t the early design phase, for a couple of reasons.
- Electronic tools constrain your thinking about what can be achieved. So if you don’t have a ‘carousel’ widget you’ll find you don’t include that interaction idea in your electronic prototype.
- Electronic prototyping blinkers you into thinking only about incremental improvement. In the early design phase you want to generate a number of completely different ideas, test them, and combine the best parts into a converged solution. Bill Buxton makes the point that you first need to get the right design before you move onto getting the design right. Electronic tools aren’t good at supporting the divergent thinking you need to get the right design.
I think there’s a deeper issue here, to do with confidence. Developers feel happy in front of a computer: it’s their domain and it’s what they’re skilled at. Take away their computer and they feel a bit… naked. But this massively undervalues another key skill that developers have: problem solving. As the development team at Red Gate Software point out, more developers should realise that their skills extend way beyond that of the keyboard.
Myth 4: “Whiteboarding is just as effective.”
Many designers I’ve spoken with tell me that they already do paper prototyping — they just do it on a white board or flip chart instead. The design team then discuss the ideas and refine them before moving to implementation.
Whiteboarding, and its close cousin sketchboarding, are terrific creativity tools, used by design heavyweights like Adaptive Path — but they’re not paper prototyping. These techniques remind me of Gerry McGovern’s joke that the worst possible way to design a web site is to have five smart people in a room drinking lattes and discussing branding. The purpose of paper prototyping is to quickly generate design ideas that you can test out with users. It’s not for coming up with design ideas that can be voted on by the design team. This is because paper prototyping isn’t just about design — it’s about iterative design: creating stuff you can test quickly and then discard or improve upon.
Rather than hold a fruitless design meeting where you spend hours arguing over where you should put the navigation, you could spend the time more productively by creating a couple of different paper prototypes and testing out the alternatives with a handful of users. Not only will this help you make a decision quickly, you’ll also have the confidence that the final decision is based on real data rather than on a designer’s intuition, or worse: the HIPPO (the highest-paid person’s personal opinion).
Myth 5: “Users behave differently with a paper prototype than with a real system.”
Paper prototypes use the participant’s finger as the mouse and a pen as a keyboard. Interfaces are roughly drawn and are clearly not finished prototypes. This is clearly different to a real system and so a common objection is that users will behave differently with a paper prototype.
This objection has no basis in fact. A raft of published research shows that paper prototypes are just as effective as high-fidelity prototypes at detecting many types of usability issues.
Myth 6: “It looks unprofessional.”
There is no denying that paper prototypes lack beauty — but this is different from saying that paper prototyping is unprofessional. In my experience, so long as you get participants really using the paper prototype (rather than sitting back and having it demonstrated to them), they quickly get ‘lost’ in the experience of using a paper prototype. This makes issues of professionalism moot.
In contrast, I would argue that your users will think you’re more professional because you’re clearly involving them early in the design process and taking their comments seriously.
If your management is still unsure, run a trial with single participant and ask, “Is your opinion of our organisation better or worse after this experience?” I’ll bet you’ll hear only positives.
Myth 7: “I can’t prototype interactivity.”
It’s true that there are some intricate interaction styles that don’t lend themselves to paper prototyping. Gesture-based interactions on the iPad and iPhone can’t be replicated on paper. Panning and zooming, Google Maps-style, isn’t practical. Similarly, applications that require continuous scrolling or that include long download or response times can’t be properly emulated.
But the vast majority of web and software interaction — even on an iPhone — is still point and click (with a little keyboard too). These can easily be emulated with a paper prototype. Rather than focus on the edge case that won’t work, think of the vast majority of situations where paper prototyping will work. The video below shows just how interactive paper prototypes can be.
Good article on paper prototyping by David Travis. David demystifies 7 common presumtions regarding paper prototyping.