Cheap Prototypes Answer Expensive Questions

Your team keeps polishing screens before anyone has checked if the flow even works. It feels like progress. It looks great in the review. But you are spending real hours on shadows and type when the thing you actually need to know is simpler: does this path make sense to a person who has never seen it?

The fix is not a rule about when to go rough or when to go polished. It is a habit of asking one question first: what do I need to learn right now? Fidelity follows the question. Get that order right and your team learns faster and throws away less work.

The deep cut

• Fidelity follows the question, not the calendar. Kara Pernice frames a prototype as a hypothesis, so match the detail to what you are testing.
• Polish too early and you marry the wrong idea. Nielsen Norman warns designers get wedded to a design once they sink hours into it.
• Sketch it, test it in ten minutes, then raise it. Jesse Showalter shows a full prototype-and-test round takes less time than one polished screen.

A prototype is a question, not a deliverable

The cleanest way to think about this comes from Kara Pernice at Nielsen Norman, who calls a prototype "a hypothesis, a candidate design solution." You are not making a thing to show. You are asking a question and watching a real person answer it.

That reframe changes how you pick fidelity. If your question is "does this flow hold together," a paper sketch answers it. If your question is "can people read this type at this size, does this menu feel right," you need the visuals to be real. The question picks the tool. Polish is never the goal by itself.

So before your team opens a file, ask out loud: what do we need to learn from this round? Write it down. Then build the cheapest thing that answers it.

Why polish is a trap when you start

Ripping up code is expensive. Ripping up a piece of paper costs nothing. Pernice lays out the real risk of going hi-fi too soon, and it is about people, not pixels. "Once we invest more time and sweat in a design, it's harder to give it up if it does not work well." You get married to the idea.

There is a second trap. When a design looks finished, stakeholders treat it as finished. An executive sees the polish and says ship it. A rough sketch tells everyone the work is still open and changes are coming. That lowers the pressure on users too, since a sketchy screen signals you are testing the design, not them.

So early polish costs you twice. It makes your team defensive about bad ideas, and it makes everyone else think the decision is already made.

Flow first, then screens

Before you pick any fidelity, know what layer you are working on. Silvia Vitali argues the flow matters more than pixel detail early on, and this is where teams get stuck. They polish one screen in isolation while the path between screens is still broken.

Lo-fi is built for the flow question. You can lay out ten rough screens and walk a person through the whole task. Hi-fi is for the detail question that comes after: this specific component, this hierarchy, this piece of real content.

Make the order a rule on your team. Flow holds up first. Details second. If someone is deep in a polished screen and the flow has not been tested, that is the signal to stop and back up.

Fake the computer and move faster

You do not need a clickable build to test a flow. Pernice describes the "Wizard of Oz" method, where a person who knows the design sits in another room and serves up the next screen by hand when the user clicks. No code. The human is the computer. It even works for testing AI features before the AI exists.

This is how you get to the speed Jesse Showalter is after, a full prototype-and-test round in ten minutes or less. The point is not to skip research. It is to answer the small, fast questions on the spot and save the real research project for the questions that deserve it.

When it is time to raise fidelity, do it on purpose. Moyosore Ale frames the jump from rough to polished around research goals: you raise the detail when your new question needs it, not when the clock says so. Pair that with Ivano Aquilano's idea of breaking the process into small repeatable chunks, and you get a loop a small team can actually run: ask, build the cheapest answer, test, then decide if the next question earns more polish.

Three questions for your team

• Before this next round of work, what is the one thing we need to learn, and is the flow already proven or not? If the flow is not proven, you are not ready for polished screens.
• Which questions in our backlog could we answer with a paper sketch and ten minutes, instead of waiting for a research project? Pull those forward this week.
• For the design we are most attached to, have we actually tested it, or are we defending the hours we already put in? If it is the hours, drop the fidelity and test the idea cold.