The cheapest prototype you can make this week
How to build a low-cost prototype in days, not months: pick the question, choose paper, role-play, Wizard of Oz or concierge, and test it with real people.
The cheapest prototype you can make this week
The cheapest prototype is the roughest thing that answers your single most important question with real people watching. For most ideas that means paper, a role-play, a person pretending to be the system, or doing the service by hand for a few people. You can make any of these in a day and test it by Thursday. The steps below show how to choose and run one.
This article is about making the thing. For the wider question of how to plan tests and read evidence, see our sibling piece on how to test an idea before you build it.
Why cheap beats good at this stage
A prototype is a question in physical form. Early on, the only questions worth asking are the ones that could kill the idea: will people understand it, will they use it, will they use it the way you expect. A polished prototype answers these no better than a rough one, and has two disadvantages. It costs more, so the team becomes attached to it. And it looks finished, so people are polite about it. Rough work invites honest criticism; it is plainly not too late to change.
Five cheap prototypes and when to use each
| Prototype | What it is | Best for testing | Time to make |
|---|---|---|---|
| Paper prototype | Sketched screens, forms or letters on paper | Whether people understand and can navigate it | Hours |
| Storyboard | A comic strip of the experience, six to eight frames | Whether the idea makes sense and appeals at all | An hour or two |
| Role-play | People act out the service with simple props | Conversations, handovers, in-person moments | Half a day |
| Wizard of Oz | Looks automated; a person secretly does the work behind it | Whether people use a "smart" or digital feature | A day |
| Concierge | You deliver the service openly by hand to a few people | Whether the value is real enough to keep using | A day to set up |
A note on names: the Wizard of Oz term was coined by John F. Kelley in his work on natural-language computing at Johns Hopkins, and first appeared in print in his 1983 thesis. Carolyn Snyder's book Paper Prototyping (2003) remains a good practical reference for the paper kind.
How to make and test one this week
1. Write the one question (Monday morning). List what has to be true for the idea to work, then pick the assumption that is both most important and least proven. Turn it into one question: "Will first-time applicants find the right document list without help?" If you have three questions, you have three prototypes. Start with one. An assumption map is a quick way to choose.
2. Write what would change your mind. Before building, agree what you would need to see to keep going, and what would make you stop or change direction. "If most people can't find the list without asking, we redesign the entry point." Writing this down first stops the team reinterpreting results afterwards. The hypothesis test guide has a simple format.
3. Choose the form from the question (Monday afternoon). Use the table above. Understanding and navigation: paper. Overall appeal: storyboard. Human interaction: role-play. A digital or automated feature: Wizard of Oz. Whether the value is real: concierge. If in doubt, pick the one you can make fastest.
4. Build only what the question needs (Tuesday). Make the part of the experience the person will touch during the test, and nothing else. A paper prototype for a form needs the form, the error message and the confirmation, not the whole portal. A Wizard of Oz chat needs a person on the other end with a few prepared answers, not a chatbot. Use pens, printouts, a shared document, a phone. If building takes more than a day, you are building too much.
5. Recruit five or so real people (Tuesday). Find people who match the person you are designing for, not colleagues. Front-line staff can often introduce you to them that day. Five sessions will usually show you the big problems; you are looking for patterns, not percentages.
6. Run the sessions: watch, don't explain (Wednesday and Thursday). Give the person a task, not a tour: "You need to renew your permit. Show me what you'd do." Then stay quiet. When they get stuck, ask "What are you looking for?" rather than pointing. Have a second person take notes in a feedback capture grid: what worked, what didn't, questions raised, new ideas. In a Wizard of Oz or concierge test, the person doing the hidden or manual work keeps a log of every request, because that log is your specification later.
7. Decide and record it (Friday). Compare what you saw with what you agreed in step 2. Choose one of four outcomes: carry on, change and test again, change direction, or stop. Write one paragraph recording the question, what you saw and the decision. That paragraph is worth more than the prototype.
Do's and don'ts
Do
- Test one question per prototype.
- Keep it visibly rough: hand-drawn lines, crossed-out words, sticky tape.
- Test with the people who will actually use it, in or near the real setting.
- Be honest afterwards in concierge tests: people know a person is helping them. In Wizard of Oz tests, tell participants at the end that a person was behind it, and follow your organisation's rules on research consent.
- Keep the prototype, the notes and the decision together.
Don't
- Ask "Do you like it?" Watch what they do.
- Explain the idea before they try it.
- Fix the prototype between every session unless a problem stops the test entirely; you lose the pattern.
- Let a cheap test become a hidden pilot. Wizard of Oz and concierge work at small scale only, by design.
- Show a polished mock-up to senior leaders as if it were the product. Show what you learned.
Illustrative example
Illustrative. A city council in Australia had an idea for a "parking permit assistant" that would answer residents' questions online and fill in the application for them. The digital team estimated several months to build it.
Instead, the team asked one question: would residents actually use a chat to apply, or would they still phone? They agreed beforehand that if most testers abandoned the chat and asked for the phone number, the idea would be dropped.
They built a Wizard of Oz version in a day: a simple chat window on a test page, with a permits officer on the other side typing answers from a short script. They printed a paper version of the final application summary. Over two days they ran sessions with residents recruited at the council's service centre.
Most residents used the chat without trouble, but almost all of them asked the same two questions the script had not covered, about visitor permits and moving house. The officer's log showed those questions plainly. The team decided to carry on, but to rewrite the eligibility page first, because many of the chat questions would disappear if that page were clearer. The build estimate shrank because the assistant no longer had to handle questions a better page could answer.
Questions people ask
What is a low-fidelity prototype? A rough, quick version of an idea, such as a sketch, paper mock-up or role-play, made to test whether the idea works before investing in a detailed version. Low fidelity refers to how finished it looks, not how useful it is.
Can you prototype a service, not just a product? Yes. Services are often easier to prototype than products, because you can act them out. Role-plays, storyboards and concierge tests are all ways of prototyping a service with people, a script and a few props.
How many people do I need to test a prototype with? For an early, rough prototype, a handful of sessions is often enough to reveal the biggest problems. If several people stumble at the same point, you have your answer. Test again with a new group after you change it.
Where to go next
The paper prototype guide, Wizard of Oz test and concierge test each walk through one form in detail, and the storyboard is the fastest way to test whether an idea makes sense at all. For where prototyping sits among other tools, read which innovation tool should I use, and see the 10 tools every innovation team should know.