A grey wireframe can contain a remarkably realistic decision, while a polished prototype can offer almost none. If the wireframe includes the actual prices, restrictions and choices someone needs, it may support a better test than a beautifully branded screen filled with placeholder text. Prototype fidelity describes how closely a prototype represents the intended product, and that resemblance has several dimensions.

Visual appearance is one of them. Content, interaction and the amount of the product represented matter too. Calling a prototype “high fidelity” without saying which of those qualities is high leaves the team with an imprecise description of what it can learn.

Look beyond the finish

Visual fidelity concerns layout, typography, colour and other aspects of appearance. Interaction fidelity concerns what happens when someone acts: whether a menu opens, a form accepts input or an error can be corrected. Content fidelity concerns the words, data and options that give those interactions meaning.

Breadth and depth describe a further distinction. A prototype may show many parts of a service superficially, or represent one journey in detail. Nielsen Norman Group’s discussion of prototype fidelity treats appearance, interaction and content as separable choices, which is more useful than assuming that fidelity rises uniformly as a design becomes prettier.

Consider a fictional subscription service testing a cancellation journey. A plain page with credible renewal dates, refund terms and account states may be enough to investigate whether customers understand the consequences. If the question concerns whether they notice a warning before confirming, spacing and visual hierarchy become central. If it concerns recovering from an accidental cancellation, the sequence and available actions must work.

Choose the details that could change the answer

Before prototype testing, write down what the team needs to learn and what would make the test misleading. For the cancellation example, placeholder dates might remove the very uncertainty the study needs to examine. An unrelated dashboard illustration probably would not.

This exercise also exposes interactions that are easy to overlook. A mobile input method, a loading delay or an error state can affect behaviour even when every screen looks finished. A prototype that accepts any input cannot establish whether validation messages are understandable, and an image of a form cannot establish whether its fields work with assistive technology.

Build the necessary detail, then stop when further work ceases to improve the evidence you need. There is no obligation to begin with sketches if the question depends on realistic behaviour, just as there is no obligation to produce finished visual design before testing the structure of a flow.

Avoid treating roughness as a guarantee of candour

An unfinished appearance can help communicate that a design is open to change. It does not ensure that participants will criticise it, and polish does not make useful feedback impossible. The research introduction, relationship with the moderator, task and participant’s circumstances also shape the session.

Tell people that the design is being examined and that difficulties are useful to understand. Then give them an activity to attempt. Observed problems are more informative than relying on a prototype’s appearance to produce the right attitude towards feedback.

For structural questions, wireframe testing can be appropriate where the essential content and routes are represented. For questions about findability across a hierarchy, tree testing may remove visual detail more deliberately than a conventional prototype would.

Carry the limitations into the conclusion

A report should say what the prototype represented and what it omitted. “Participants completed the cancellation” means something different when they could enter real test details, change their mind and encounter errors than when they clicked through a single prepared path.

Those omissions do not make the study worthless. They define the conclusion it can support and the work that remains. When the implemented product adds real data, latency, permissions or assistive-technology behaviour, test those conditions rather than assuming that an earlier prototype has already answered for them.