A prototype should answer one question

I used to build prototypes with too much around the thing I wanted to test. A dashboard would get a sidebar, settings, and carefully styled filters before I'd found out whether the main interaction was useful.

Once those details existed, reviews drifted toward them. People had opinions about navigation labels while the central question remained unanswered.

I now try to write that question before opening the editor.

Name the uncertainty

“Does this idea work?” is too broad to guide a prototype.

“Can someone turn this raw data into a report they would send to a colleague?” is more useful. It suggests a task, a person to try it, and a result to inspect.

A technical question needs a different test. If I'm unsure whether a search approach is fast enough, I need realistic data volumes and a way to measure response times. A polished search box adds little to that experiment.

Some questions can't be answered in one session. A walkthrough can show whether someone understands a workflow. It cannot establish whether they'll return next month or pay for it. That needs observation over time, and often a working product.

Match the prototype to the test

For a comprehension test, a clickable mockup may be enough. If the question depends on typing, timing, scrolling, or accessibility, I usually need something running in a browser.

Fake data is useful when the data source isn't under examination. It needs to resemble the real data in the ways that matter: long names, missing values, uneven counts, or whatever might break the proposed layout.

For a performance test, tiny fixtures can give a dangerously reassuring answer. I want to know how the approach behaves under the load we expect, and what happens beyond it.

The cheapest prototype is the smallest one that can produce credible evidence for the question. Sometimes that is a sketch. Sometimes it takes substantial engineering.

Make shortcuts visible

A local interaction prototype can use a hardcoded account. A public preview handling real customer information can't skip access controls because someone called it a prototype.

I keep the environment and limitations explicit. For example:

• Uses sample data; it does not read customer accounts.
• Saves only for the current session.
• Tests one path; errors and recovery aren't implemented.
• Has not been tested on mobile.

These notes should travel with the link or recording. A comment buried in the code won't help a stakeholder who mistakes the demo for a nearly finished release.

Make it realistic where realism matters

Rough styling can keep attention on the flow. It can also distort a test.

If the question is whether someone trusts a checkout, a temporary-looking page may undermine the result. If I'm testing how people read a dense report, typography and spacing are part of the experiment. They can't wait until after the “real” test.

I spend effort where it affects what I'm trying to learn, and leave unrelated parts plain. A prototype doesn't need to look unfinished to be disposable.

Record the result before adding anything else

After a session, I write down what happened separately from what I think it means.

“Three people asked whether the save action had completed” is an observation, if that's what occurred. “We need a toast” is a proposed response. Keeping those separate leaves room for a better explanation or solution.

For technical work, I record the test conditions alongside the numbers. A response time without the dataset size, device, or cache state is hard to use later.

The result may support building, suggest a narrower approach, or leave the question unresolved. An inconclusive test needs a better test, not a confident slide.

Once I can make the intended decision, I stop extending the prototype. I keep the findings and assess the code separately. A useful result doesn't automatically make its implementation ready for production.