Prototyping
The wireframes look right to the team. But will a subscriber at 7:10 a.m., half awake with a meeting just moved, find the Change button and trust that the cook got the message? Static screens cannot answer that. People trying something can. A prototype lets you find out before anyone writes production code.
The rule
Build only enough to answer the question you are asking.
A prototype is a stand-in for the product that people can try. Its purpose is learning, not delivery, so its fidelity should match the question:
- Paper prototype: "Do people understand the idea at all?" Sketched cards you swap by hand, made in minutes.
- Clickable prototype: "Can people find their way and finish the task?" Linked screens in a design tool.
- High-fidelity or coded prototype: "Does it feel right with real timing, data and motion?" Slower to make, so save it for questions that need it.
- Concierge test: "Will the service work in the real world?" People do by hand what the software would do later, for real customers, for a short time.
To test, give people a task, not instructions: "Your 1 p.m. meeting just became a lunch meeting. Sort out today's tiffin." Then watch quietly. Around five people per round is usually enough to surface the most common problems.
Then fix and test again. Three rough rounds teach more than one perfect prototype, because each round starts from what the last one found. This is iteration over perfection.
The shortcut
Write the question first, then pick the cheapest prototype that could answer it. If a cheaper one would do, the expensive one is waste.
Question 1: do people get the idea?
Paper cards of the Today card, shown to five subscribers. Four understand "Change until 7:30 a.m."; one reads it as the delivery time.
A common mistake is testing with teammates. They already know what the design is meant to do, so they cannot show you where a newcomer gets lost. Test with people who match the persona, and do not explain the screen when they hesitate: the hesitation is the finding.
Drills
Answer fast — trust the rule.
You want to know whether subscribers understand the idea of a morning change window at all. Which prototype fits?
What is the main purpose of a prototype?
Which is the best task to give someone in a prototype test?
The team wants one perfect prototype before testing anything. What is the risk?
Remember
- Build only enough to answer the question you are asking.
- Shortcut: write the question, then choose the cheapest prototype that could answer it.
- Trap: giving instructions instead of tasks, and polishing before you have tested anything.