Why use paper
Paper is the cheapest way to find out whether an interface makes sense. Because a sketch takes minutes, nobody is reluctant to throw it away, and because it looks unfinished, testers feel free to say what is confusing. A polished mockup tends to produce polite comments about colors. A rough sketch produces comments about what the screen does.
Paper prototyping is not a replacement for testing on real hardware. It answers questions about structure, order and wording. Questions about touch accuracy, brightness, animation and sound need a later test on the actual screen.
What paper can and cannot tell you
Good for:
- Whether the starting screen makes sense.
- Whether visitors find the content they are looking for.
- Whether labels and button names are understood.
- Whether the number of steps feels right.
- Where people expect a back button or a way home.
Not good for:
- How fast the system responds.
- Whether touch targets are comfortable, though you can test rough sizes.
- How the screen looks in gallery lighting.
- Anything that depends on motion or sound.
Materials
The kit is small: unlined paper or index cards, markers, sticky notes, scissors and tape. A template of the screen outline at its real proportions helps. Print or draw a rectangle matching the display’s shape, so layouts are not unrealistic. If you can, make the sketches at roughly the physical size of the real screen, because it affects how much fits.
Building the prototype
- List the tasks. Write down the three or four things a visitor should be able to do, such as finding the story of one object or switching language.
- Sketch each screen. One sheet per screen. Include the title, the main content area and every button, with the real words you plan to use. Avoid dummy filler wording, which hides wording problems.
- Make the parts that change. Pop-ups, menus and highlights can be separate pieces of paper laid on top, so the person running the test can add or remove them.
- Number the screens. This helps the facilitator find the next sheet quickly.
- Do a dry run with a colleague to catch missing screens.
Running a session
You need two roles: a facilitator who speaks and a “computer” who swaps sheets in response to touches. A third person can take notes.
- Explain that you are testing the design, not the person, and that nothing they do is wrong.
- Place the first sheet in front of them and give a simple task. Avoid naming the buttons in the task, or you will give away the answer.
- Ask the visitor to point at what they would press, ideally while saying what they expect to happen.
- The “computer” shows the matching sheet. If there is no sheet for what they tried, note it as a gap.
- Stay quiet when they hesitate. Hesitations are data.
- Afterward, ask what they thought the exhibit was about and whether anything was unclear.
Keep sessions short. Five to ten minutes per person is often enough, and a handful of participants can show the main problems, though more variety in the audience means more people are needed.
What to look for
- Wrong first taps. If several people press the wrong thing, the layout or the label is not working.
- Lost visitors. Someone who cannot find a way back signals a navigation gap.
- Words they misread. Jargon, internal names and ambiguous labels show up quickly.
- Skipped content. If nobody touches a feature, it may not be visible, or may not matter.
- Surprise. What visitors expect to happen after a touch is as useful as what they do.
Choosing testers
Try to include people close to the real audience. For a family exhibit, include an adult with a child. For a general exhibit, volunteers, front-of-house staff and visitors in the cafe can all help, though staff know the collection better than most visitors and may find the wrong things easy. Include someone who does not often use touchscreens, such as an older adult, if they are likely visitors. Remember that paper tests with a few people are informative, not statistically conclusive.
Acting on findings
After each round, list the problems and rank them by how many people were affected and how badly. Fix the biggest ones, redraw the affected sheets, and run again with new people. Two or three short rounds usually do more good than one long one. Record decisions so the development team understands why a screen looks as it does.
Moving from paper to screen
Once the paper version works, a clickable mockup or a first build can test the same tasks, with attention now on touch targets, timing and legibility. This is the point at which fuller prototype testing with real visitors takes over, and where the exhibit brief and project schedule should allow time for at least one round of changes. Plain language labels tested on paper usually carry over unchanged. Paper prototypes are also a good way to bring in colleagues, volunteers and community members who will not read a specification but can easily move cards around and say what they would change.