Prototyping — Test Before You Build

What you'll learn

• What a prototype is and why it's powerful
• Clickable prototypes in Figma
• Testing interactions before writing code
• The iterate-fast design loop

A fake that feels real 🎭

A prototype is a simulation of your product that a person can click through — it looks and behaves like the real app, but there's no code behind it. It's a movie set: the storefront looks real from the front, but it's held up by sticks. That fakery is exactly the point — it lets you test the experience before spending weeks building it for real.

In Figma, you turn static screens into a prototype by linking them: "when the user taps this Login button, go to the Dashboard screen." Chain these links across your screens and you get something that feels like a working app on a phone or in a browser — you can tap through the whole flow. You can even add transitions (slide, fade) to mimic real motion.

Why prototypes are so valuable:

• Test real interactions — a static wireframe can't reveal that your checkout flow is confusing; a clickable prototype can. Users do the task and you watch where they get stuck (usability testing from the research lesson — now with something clickable).
• Catch problems for pennies — fixing a flawed flow in Figma is dragging arrows around. Fixing it after developers built it costs weeks. Prototyping moves discovery to the cheapest possible moment.
• Communicate clearly — a clickable demo shows your team, boss, or client exactly what you mean far better than words or static images. It gets everyone aligned before a line of code is written.

The design loop this enables:

Sketch idea → prototype it → test with users → learn → refine → test again → ...

This fast, cheap loop is the heart of good UX design. Each turn of the loop costs little but improves the design a lot, so you iterate your way to something genuinely good — instead of guessing once, building it, and hoping. The best designers aren't the ones who get it perfect on the first try; they're the ones who iterate quickly with prototypes and real feedback.

Only after the prototype proves the experience works do you hand it to developers to build for real — now with confidence that you're building the right thing.

Matching prototype fidelity to the question 🎚️

Not every prototype needs to be a polished, animated Figma flow. Matching the prototype's fidelity (how real/detailed it looks and behaves) to the stage of your question saves huge amounts of time:

• Paper prototyping. Literally sketch screens on paper, cut out a "menu" strip, and have a teammate act as "the computer" — swapping papers as a test user "taps" things. It sounds silly, but it can be built in minutes and is perfect for the earliest question: "does this flow even make sense?" You can run a paper test before opening any software at all.
• Low-fidelity clickable. Grey-box wireframes linked together in Figma — good for testing structure and flow (can people find the right screen?) without the distraction of color and copy.
• High-fidelity clickable. Polished screens with real colors, fonts, and content, closely mimicking the final product — good for testing details (is this button noticeable? is this copy clear?) once the flow itself is already validated.
• The Wizard of Oz technique. Make something feel automated while a human secretly does the work behind the curtain — e.g. testing a chatbot idea by having a real person type the "bot's" replies manually. It validates whether people even want the feature, before anyone builds the real automation.

The rule of thumb: the earlier and bigger the question, the rougher the prototype should be. Testing "should this feature exist at all?" with a beautifully polished mockup is a waste — a paper sketch answers it just as well, for a fraction of the effort. Save high-fidelity prototypes for late-stage detail questions, once you already know the big structural bets are right.

Try it yourself: a 10-minute paper prototype 📝

You don't need Figma or any software for this — grab a pen and paper (or a notes app) right now:

1. Pick one small flow you use often (e.g. "add an item to a cart and check out").
2. Sketch 3 screens as rough boxes: labels for buttons, X's for images, lines for text — no need to draw well.
3. Number the taps: on screen 1, circle the button someone would tap, and draw an arrow to which screen it leads to.
4. Hand it to a friend or family member (or just imagine a first-time user) and ask them to "tap" through it with a finger while you narrate "screen changes" — watch where they hesitate or point to the wrong spot.

If you got confused feedback or they paused at some step, you just found a structural problem for the cost of a napkin sketch — the exact value this lesson is about. That's the whole prototyping mindset in miniature.

Real-world case study: the "Wizard of Oz" search engine test 🔍

A widely told story in product and UX circles describes how early search and AI-assistant style features were sometimes validated before the real technology existed to power them: instead of building a complex automated system upfront, a team would have a person behind the scenes manually reading incoming queries and typing back responses, while the test user believed they were interacting with a fully automatic system. This general technique became known as the "Wizard of Oz" method, named after the movie where a seemingly powerful wizard turns out to be an ordinary man operating machinery behind a curtain.

The insight behind it is exactly what this lesson teaches: before investing months of engineering into an automated feature, teams can validate the much cheaper, much more important question — do people actually want this, and does the interaction feel useful — with a human quietly standing in for the not-yet-built technology. If users love talking to the "smart" assistant, that's the green light to go build the real automation. If they don't, the team just saved months of engineering on a feature nobody wanted, for the cost of a person typing replies for an afternoon.

This is prototyping fidelity taken to its logical extreme: sometimes the cheapest, fastest prototype isn't a screen at all — it's a human pretending to be the software, precisely so you don't have to build the software to learn if the idea works.

Summary

• A prototype is a clickable, code-free simulation of your product
• Link Figma screens to test real interactions before building
• Catch flaws for pennies, communicate clearly, iterate fast
• Match fidelity to the question: paper sketches for big early questions, polish for late details
• The "Wizard of Oz" technique tests demand with a human standing in for unbuilt automation
• Great design = the sketch → prototype → test → refine loop

Next: Design Systems — turning your proven designs into reusable, consistent building blocks.