Prototyping That Tests an Idea

UI/UX · ~8 min read

A prototype is not a deliverable. It is an experiment. The point is not to show something impressive — it is to answer a question you could not answer with a rough drawing. If you cannot say what a prototype is meant to disprove, you are building a demo, not running a test.

Start from the question, not the screen

Before you open a prototyping tool, write down the one thing you want to learn. Good prototype questions are specific and falsifiable:

• "Will people understand that swiping dismisses a card, without a visible hint?"
• "Does the three-step flow feel shorter than the current five-step one?"
• "Can a first-time user find the export control within 15 seconds?"

Bad questions are unfalsifiable: "does this feel good?", "do people like it?", "is this the right direction?" Those invite opinion, not evidence. Pin down a behaviour you can observe and a threshold you would accept.

Match fidelity to the question

Fidelity is a tool, not a virtue. Higher fidelity is slower to build and biases testers towards praising visual polish. Choose the lowest fidelity that still answers your question.

A useful rule: prototype at the fidelity the decision requires and no higher. If you are testing comprehension of a flow, a clickable greyscale prototype is not a compromise — it is the correct instrument, because it removes the visual noise that would dominate the feedback.

Build only the path under test

A prototype should cover the branch you are testing and stop. Everything else can be dead ends or shortcuts, as long as they look plausible enough that the user keeps going. This is liberating: you do not need a complete product, just the corridor you care about.

• Wire the happy path end to end.
• Add the one alternative path you suspect users will take.
• Stub everything else so it does not break the illusion.

Label your prototype internally — in a title block or a meta note — as a test build, so nobody mistakes it for a spec or shares it as a demo without context.

Prototype interactions, not just screens

Static linked screens test navigation; they do not test the interaction that actually makes or breaks the product. The interesting behaviours to prototype are the ones with timing, feedback and consequences:

• Transitions: does a screen change feel connected to the action that caused it? Aim for motion in the 150–250ms range for small state changes and 250–400ms for larger ones.
• Feedback: what does the user see in the first 100ms after tapping, when the network has not answered yet?
• Gestures: is a swipe, drag or long-press discoverable without a tutorial?
• Errors and recovery: what happens when the action fails, and can the user get back?
• Empty and loading states: the moments that usually get skipped and then feel broken.

Motion deserves a note of its own. Good motion explains a spatial relationship — where a panel came from, where it went. Decorative motion that does not explain anything is usually worth removing, and it should always respect a user's reduced-motion preference.

Instrument the test

A prototype test is a small experiment, so treat it like one. Decide in advance what you will measure and how.

1. Tasks: give the tester a goal, not instructions. "Find your last invoice and download it", never "click the Invoices tab".
2. Metrics: task success, time on task, and where they hesitate or backtrack.
3. Observations: the moment of confusion matters more than the opinion that follows it. Note the timestamp.
4. Debrief: ask open questions after, not during. "What were you expecting to happen there?"

Record the session if you can, and watch it back with the team. People reliably report a different experience than they had; the recording is the ground truth.

Test the flow, not the aesthetics

When you show a prototype, say explicitly that you want feedback on the interaction, not the look — otherwise you will collect a list of opinions about colours and nothing about whether the flow works. Useful prompts are behavioural:

• "Walk me through what you are seeing."
• "What did you expect to happen when you tapped that?"
• "If you could not find it here, where would you look next?"
• "What would you change about the order of these steps?"

Also test on the device the interaction is meant for. A drag gesture feels one way under a mouse and another under a thumb, and a hover state does not exist on a touchscreen. The cheapest way to invalidate a prototype test is to run a mobile interaction on a desktop and believe the result.

Resist the urge to defend

The hardest skill in prototyping is watching someone struggle and saying nothing. Do not explain the interface, do not rescue them, do not hint. When a tester asks "should I click here?", answer with "what would you do if I were not here?". Their confusion is the data you came for. An assistant who helps the user has contaminated the experiment.

Decide, then move

Every prototype round should end with a decision. Otherwise you have collected feelings and called it research. At the end of each round, write down three things:

• Validated: what held up and can be built on.
• Invalidated: what the prototype disproved — the most valuable output.
• Unknown: what you still cannot answer, and whether it is worth another round.

Then iterate on the smallest change that addresses the biggest problem. Prototyping rewards speed of learning over polish of artifact: five rough prototypes that each killed a bad idea are worth far more than one beautiful prototype that confirmed what you already believed.