Art, design & a little curiosity
Design process ↗

Low fidelity vs high fidelity: match the prototype to the question

Choose prototype detail by the uncertainty you need to investigate, comparing paper flows, clickable screens, and working interfaces without treating visual polish as proof of realistic behavior.

An original type poster study exploring low fidelity vs high fidelity prototype.
Type poster / Original digital study

Fidelity has several dimensions

Fidelity describes how closely a prototype represents aspects of the intended product. Those aspects can differ: a polished screen may have unrealistic behavior, while a rough working page may reproduce keyboard interaction accurately. Choose the representation that can answer the current question rather than assuming that every project should climb one fixed ladder of polish.

Match realism to the uncertainty

List the uncertainty before choosing a tool. Paper can help explore sequence and wording. Clickable screens can support some navigation questions. A working interface may be necessary for responsive behavior, actual validation, or assistive-technology checks. State which aspects are simulated and which are implemented so observers do not infer more than the prototype supports. Keep the method subordinate to the question. A familiar workshop format or favorite tool can help with mechanics while still being poorly suited to the uncertainty at hand. Explain why the chosen activity can reveal something useful, and state what it cannot establish. This makes the plan easier to challenge constructively and helps the team choose another approach when the conditions or available evidence change.

Compare three submission prototypes

Compare three prototypes of an artwork-submission task. Use paper to examine the order of questions, linked screens to explore movement between review and editing, and a working form to check file-selection behavior. Keep the content similar. Write a question each prototype can address and one it cannot reasonably answer. Run a short rehearsal before treating the artifact as ready for its intended use. Ask a colleague to follow it with the stated context and note where they need extra explanation. Record those gaps as preparation issues rather than findings about the product or its audience. Revise the artifact, then check that the next person can understand the task, available information, and expected output without having to reconstruct the session that created it.

Explain what polish does not establish

If a polished prototype impresses stakeholders, they may assume the product is nearly complete. Explain its limits explicitly. If a rough prototype makes reading unnecessarily difficult, its low detail is obstructing the question. Increase only the detail needed to examine the uncertainty instead of treating low fidelity as an excuse for unclear content. If discussion becomes repetitive, locate the decision that remains open and the information needed to resolve it. More notes or another round of voting may not supply that information. Pause the activity when necessary and assign a focused investigation or an operational question. Keep the unresolved issue visible in the handoff so another team does not mistake the absence of a decision for permission to improvise.

Keep claims within the prototype's scope

Review the prototype against the planned task and the claims you intend to make. Remove unsupported claims about speed, accessibility, or reliability when those properties are only simulated. A useful prototype has enough realism for its purpose and clear boundaries around the rest. Fidelity is a design choice in service of learning, not a quality ranking for the artifact.

A worked example

Worked decision

A linked screen can simulate upload navigation; a working form is needed to examine actual file-selection and validation behavior.

References & further reading

Examples and exercises in this guide are original teaching scenarios.

Keep following the thread.

More design process ↗
Design process3 min read

Make a paper prototype for a workshop booking

Create and operate a paper booking prototype with state cards, realistic content, a facilitator script, and interruption cases, then record questions without treating the exercise as evidence of implementation behavior.