Prototype realism: honest tests need real interaction

A usability test is only as honest as its prototype. Ask people to complete a form that accepts no typing, tap through a click-path that allows only one route, or imagine a payment step that does not exist, and you get results that look like validation but measure nothing. The prototype smoothed away exactly the friction the test was supposed to find. Teams walk away confident; the confidence is manufactured.

Why it matters to the business

False validation is worse than no validation because it converts assumptions into certainty and certainty into shipped product. The delivery gap shows how easily organizations fool themselves: Bain found 80% of companies believed they delivered a superior experience while only 8% of their customers agreed. Self-report makes it worse: research from 84.51 found 75% of respondents misstated their own purchase behavior when checked against loyalty-card data. Watching realistic behavior is the corrective, but only if the behavior is actually realistic. And when manufactured confidence meets production, PwC's finding applies: 32% of customers will leave a brand they love after one bad experience.

How to use it

• Test only what participants can genuinely perform: working inputs, real data entry, plausible content.
• Match the prototype's interactions to what will ship; if the real flow has seven fields, test seven fields.
• Brief moderators to stay silent when participants struggle: the struggle is the data.
• Ban mid-test rescues and leading hints; log every request for help as a defect.
• If the prototype cannot support genuine interaction yet, delay the test until it can.

Where teams get it wrong

The deadline is close and the prototype is thin, so the team tests anyway and narrates the gaps: imagine this field works, you would get an email here. Participants nod, tasks pass, and the report says validated. Everyone was kind, nobody was honest, and the first genuine test happens at launch, run by customers who do not narrate. They leave.

Ask your team

• In our last usability test, could participants actually type, submit, fail, and recover, or did we narrate over the gaps?
• How many times did the moderator help, and was each rescue logged as a finding?
• Have we ever delayed a test because the prototype was not ready to be tested honestly?

False validation is worse than no validation.