Paper Prototypes Versus a Board Presentation
The Riverbend Museum is redesigning ticket booking. Its current site has three ticket types (general, special exhibition, member), timed entry every 30 minutes, and a school-group booking path that generates 40% of revenue but is handled entirely by phone. The designer has finished paper prototypes of the individual booking flow and is about to test them. In week two, the marketing director asks for high-fidelity screens for a board presentation, arguing that "paper looks unfinished". Two developers need to start building in four weeks and have asked for the navigation structure. Front-desk staff, who currently fix most booking mistakes by phone, have not been consulted, and 30% of online bookings are changed or refunded.
1. Recommend a fidelity level and a four-week plan, and defend it to the marketing director.
Read the worked answer
Fidelity is a function of what you are testing, not of how finished the project feels. Paper tests structure: is the flow in the right order, are the labels understood, does the timed-entry constraint make sense. It cannot test visual hierarchy, trust, or perceived speed - which is exactly what high fidelity is for, and exactly the wrong thing to test before the structure is settled.
Four-week plan:
- Week 1: test the paper prototype with five or six people, plus interviews with front-desk staff. Resolve terminology and the timed-entry flow before anything is drawn digitally.
- Week 2: mid-fidelity digital wireframes of the revised flow - clickable, real labels, no brand styling. Give developers the navigation structure now; they need the map, not the paint.
- Weeks 3–4: second test round, then high fidelity for the screens that survive, followed by a visual design pass and accessibility checks.
To the marketing director: the board does not need pixels to be convinced, it needs evidence. Show the research, the failing flow, the revised flow, and a quote or two. If a polished visual is genuinely required for the deck, produce one clearly labelled concept screen - but saying out loud that it is a concept protects you from the board treating it as a commitment. Doing high fidelity in week two invites the board to critique colour and button shape while the navigation is still wrong, and every structural change after that is expensive.
2. Where should school-group booking live in the navigation, and how would you structure that flow? Justify the decision.
Read the worked answer
School groups are not an edge case - they are two-fifths of revenue and currently fall outside the digital product entirely, which means the site is optimised for the smaller share of the business. So they get a first-class entry point on the home page and on the booking landing page, not a link in the footer.
But a first-class entry does not mean merging them into the individual flow. The task models differ fundamentally:
- Unit of booking: one class of 30 versus two adults.
- Inputs: teacher and school details, risk assessments, invoicing, purchase orders, arrival time and coach parking.
- Authority: the teacher usually cannot pay at the point of booking.
- Timing: booked weeks or months out, often against curriculum dates.
Recommendation: a separate optimised sub-flow, entered from a clearly labelled "Book for a school group" card placed alongside the individual booking card. Validate the placement with a tree test or card sort using teachers; validate the labels with five teachers in moderated sessions. The user journey for both should converge on the same availability and timed-entry logic underneath, so the calendar data stays consistent.
Finally, interview the front-desk staff before drawing any of this. They are the de facto subject-matter experts on the 30% failure rate, and their workarounds - the phone calls, the manual changes - are a map of what the current flow fails to capture.
3. How would you plan and run the paper prototype test, and what are its limits?
Read the worked answer
Plan. Write five or six task scenarios as goals, not taps: "You want to bring two adults to the special exhibition on Saturday morning - book that." Recruit participants who resemble the real audience, not colleagues. Run 45-minute sessions with one facilitator and one note-taker; record consent, use think-aloud, and put observations in a table keyed to task and participant so patterns are countable.
During. The facilitator presents each screen and swaps paper on selection - one person plays "the computer" and must not improvise help. When a participant asks "what happens if I tap here?", the answer is "what would you expect?", and the expectation is the finding. Note where they hesitate, misread a label, or ask for something that does not exist.
Limits, stated honestly. Paper cannot test real interaction, loading behaviour, error messages, or scrolling; timing data is meaningless because a human is turning pages. Participants are often polite to a person holding their prototype, so take silence seriously. It cannot test responsive behaviour or accessibility for low-vision users. It is also poor at conveying the emotional tone of a brand.
What it is good at: flow order, terminology, whether people understand timed entry, and whether the split between individual and school booking is legible. Those are precisely the open questions before the developers start, which is why paper first is the right call rather than a compromise.