Rapid prototyping

A prototype is not a small finished product — it is a question made visible. The goal is to learn something concrete as quickly and cheaply as possible. The uglier and simpler the prototype, the less attached you are to it, and the easier it is to hear honest criticism.

Low-fidelity prototypes

Start as simply as you can. Low-fidelity prototypes are fast, cheap and easy to throw away:

• Paper sketches: Draw the screens by hand. You can test a whole user flow with a stack of sheets.
• Paper prototype: Cut out "buttons" and lay new sheets on top when the user "taps." You play the computer.
• Clickable mockup: Simple digital screens linked together, with nothing actually working underneath.

The point is to test the idea, not the craftsmanship. If you spend weeks on a polished prototype, you have built too much before learning anything.

Fake-door and landing-page tests

Sometimes the most important question is simply: will people want this? Then you can test demand before you build.

A landing-page test is a simple page describing the offer with a clear button — "Sign up" or "Pre-order." You measure how many click and leave an email. A fake-door test goes a step further: you place a button for a feature that does not exist yet. When someone clicks, they get a polite "coming soon" message — and you have measured real interest without building the feature. Use fake-door tests carefully and honestly, so people do not feel tricked; a short explanation and a chance to register interest keeps it clean.

The concierge and Wizard-of-Oz methods

These two let you deliver real value before you build technology.

With the concierge method you do the job entirely by hand and out in the open, like a personal butler. Ingrid, considering a subscription service for reusable packaging, can pack and ship the first crates herself, collect them back by hand and note what works. She learns everything about the logistics before automating anything.

With the Wizard-of-Oz method the service looks automated to the customer, but behind the scenes a human does the work. The customer experiences "the system," while you learn about their behavior without having coded anything.

Build just enough to learn

Before you make anything at all, ask one question: what is the one thing I want to learn from this? Then build the smallest thing that answers that question — no more. Every extra feature you add "while you're at it" makes the prototype more expensive to change and harder to interpret.

A good prototype is finished when it can give you a clear yes or no on your assumption. Anything beyond that is decoration you cannot afford yet.

Climb up in fidelity

A common mistake is jumping straight to a polished, digital prototype. Better to climb a ladder: start with a rough sketch, move on to paper, then to a clickable mockup, and only build something "real" once the cheaper steps have answered what they can.

Each rung costs more and is harder to change. As long as a sketch on a napkin can teach you the same as a finished app screen, choose the napkin. The rule is: use the lowest fidelity that still gives you an honest answer to your question. Before Maria built any booking flow, she drew the five screens on paper and let a dog owner "tap" through them. In two minutes she discovered that people looked for "price" before "book" — a change that would have cost hours in code, but seconds on paper.

Do this now

Take the most dangerous assumption from the previous lesson. Choose the simplest prototype that can test it: a paper sketch, a clickable mockup, a landing page or a manual concierge delivery. Give yourself at most one day to make it. Before you start, write down exactly what you hope to learn — so you know what to look for when you test it in the next lesson.