Field note · UX engineering

Prototype the uncertain parts

A useful prototype spends fidelity where the question lives and stays deliberately loose everywhere else.

A prototype is an instrument

A prototype is not a small production build, and it is not a performance of certainty. It is an instrument for learning.

That sounds obvious until a prototype starts collecting requirements that do not help answer its question. The data layer becomes durable. Every edge case gets implemented. The visual treatment becomes too polished to criticize. Soon the artifact is expensive enough that the team feels pressure to preserve it, whether or not it produced useful evidence.

The better starting point is simple: what uncertainty are we trying to reduce?

Put fidelity where the question lives

Fidelity is not one slider from rough to polished. A prototype can be visually precise and technically fake. It can use real data with placeholder presentation. It can model one interaction deeply while every path around it is a painted door.

Choose fidelity dimension by dimension.

If the question is whether motion communicates a new brand, animation timing and rendering performance need to feel real. The content-management architecture probably does not.

If the question is whether people understand an AI-assisted creation flow, generated content, waiting, revision, and recovery may matter. Account settings probably do not.

If the question is whether a new palette remains accessible, the relevant surfaces and brightness relationships need accuracy. Navigation to unrelated pages can remain absent.

This discipline keeps the prototype honest about what it can teach.

Build controls for collaborators

Many experiments become more valuable when the people studying them can change meaningful variables directly.

A motion designer who can swap color themes in a Lottie asset can explore more treatments without waiting for a code change. A researcher who can prepare dynamic content through a small CMS can create better study conditions. A designer who can compare contrast across new color families can adjust the system while it is still fluid.

These controls are not extras. They move iteration closer to the expertise that should guide it.

The UX engineer’s job shifts from producing every variation to designing the environment in which useful variation can happen.

Realism is valuable and dangerous

Realistic prototypes invite realistic reactions. That is useful when a team needs to understand behavior, pacing, comprehension, or trust.

But polish can also conceal uncertainty. People may assume that a convincing interface represents a settled product direction, a production-ready capability, or a complete understanding of risk.

I like to make the prototype’s boundaries legible. Name what is simulated. Identify which flows are complete. Explain where the content comes from. Tell collaborators what kind of feedback the artifact is designed to support.

Clarity about limitations does not weaken a prototype. It improves the evidence gathered from it.

Shared foundations increase experimental range

Prototype code is disposable; prototype capability does not have to be.

A shared React framework, stable interaction primitives, lightweight authentication, realistic content tools, and repeatable deployment can reduce the cost of starting the next experiment. The important distinction is between reusable infrastructure and accidental product architecture.

The foundation should make common research needs easy without forcing every exploration into the same shape. It should help teams reach the uncertain part sooner.

Stop when the question changes

A prototype has done its job when the original uncertainty has been reduced enough to make a better decision. The next step may be another prototype, a research study, a technical spike, a product plan, or a decision not to continue.

That last outcome matters. A prototype that prevents a weak idea from becoming an expensive project is successful.

The best prototypes do not merely make an idea look possible. They reveal what the team needs to learn next, give the right collaborators control over meaningful variation, and remain light enough to change when the evidence asks them to.

Keep looking closely

More observations about frontend systems, interface quality, and the work around the work.

All notes