Dishonest prototypes corrupt your UX data before analysis begins. Here's how to fix the signal problem at the source and design with real intelligence.
There’s a moment every UX researcher recognises: a test participant types into a login field, pauses, and glances up — silently asking whether they’re doing it right. That pause is not user confusion. It’s data contamination. The participant has already understood that this isn’t real, and every click, hesitation, and verbal response from that moment forward is filtered through performance rather than genuine behaviour.
Most teams treat this as an unavoidable cost of testing. It isn’t. It’s a pipeline problem — and like any pipeline problem, the corruption compounds downstream.
The Fidelity Gap Is a Data Quality Problem
Smashing Magazine’s Eric Joseph L. documents this clearly: the issue isn’t that prototypes look unpolished, it’s that they behave inconsistently. A button that works on one screen but does nothing on the next destroys the simulation contract. Users don’t disengage from the task — they shift into meta-cognition, evaluating the prototype rather than responding to the product.
From a data architecture standpoint, this is schema drift mid-ingestion. You’re collecting behavioural signals, but the schema changed the moment the user detected the artifice. What arrives in your analysis layer is a mixture of genuine product responses and participant performance — and you have no reliable way to flag which is which after the fact.
The fix isn’t higher visual fidelity. It’s behavioural completeness for the specific flows you’re testing. In ProtoPie and similar tools, this means: every interactive element in a tested flow must respond — even if off-path screens are skeletal. Dead zones break the contract; imperfect visuals rarely do.
For Southeast Asian teams testing on Android-dominant user bases, this has a specific implication: prototype your touch targets and scroll behaviours to match platform conventions, not desktop assumptions. A Shopee or Lazada user has deeply ingrained mobile interaction patterns. A prototype that violates those patterns will trigger the same glance-up moment — not from novelty, but from friction.
What Locality Teaches Us About Design Assumptions
Hiroshi Sato’s essay on designing locality — drawing on Bruno Munari and a Buddhist idea of empty fields holding meaning — makes an argument that sounds philosophical until you operationalise it: the boundaries we draw determine what we’re able to see within them.
This maps directly to research design. When you set the scope of a usability test, you’re drawing a boundary. The prototype represents that boundary made tangible. If that boundary is drawn around your internal mental model of the product rather than around actual user contexts, you’ll gather data that confirms the model rather than stress-tests it.
For marketing teams running UX research in Southeast Asia, the locality problem is structural. A prototype built on assumptions derived from Jakarta may perform well in testing — and fail in Surabaya, Chiang Mai, or Cebu, where connectivity constraints, device capabilities, and cultural interaction patterns differ meaningfully. The empty field in the middle of town isn’t emptiness — it’s the context your prototype wasn’t designed to hold.
The practical implication: define the contextual boundary of your test explicitly before you build the prototype. What device class? What network condition? What language? Each answer is a schema constraint. Violate it in the prototype and you’ve introduced noise before a single participant has sat down.
The Human Signal AI Can’t Fake — Yet
Pablo Delcan’s Prompt Brush 2.0 project, covered by It’s Nice That, started as a provocation: what if an artist personally fulfilled every text prompt that would otherwise be fed to a generative AI model? The result — now a community project where thousands of people draw their own prompts by hand — is instructive beyond its artistic intent.
Delcan’s argument isn’t anti-technology. It’s pro-signal. Human-made marks carry information that synthetic outputs don’t: hesitation, correction, personality, context. The same argument applies to prototype testing. The signal value of a real user navigating a realistic prototype is categorically different from a user navigating a broken one — not in degree, but in kind.
This is where teams conflate speed with efficiency. A lo-fi prototype built in three hours that produces corrupted behavioural data has a negative ROI on the research investment. A behaviorally complete prototype for a single critical flow — login, checkout, onboarding — built in a day, produces data you can actually route into design decisions.
For regional brands managing multi-language interfaces across Thai, Bahasa, Vietnamese, and Filipino, prototype completeness means testing string-length variance and text-rendering behaviour in each language, not just the English master. A checkout flow that works beautifully in English may break visually when rendered in Thai script — and a user who encounters that break has already left the simulation.
Closing the Loop Between Research and Design Systems
The deeper issue is that prototype quality is rarely owned clearly. Design teams build the prototype; research teams run the sessions; product teams interpret the findings. The signal degradation that happens in the prototype layer is invisible to the people making decisions at the analysis layer.
The fix is governance, not just craft. Establish a prototype review checkpoint — separate from visual QA — that specifically audits behavioural completeness for tested flows. Document which interactions are live and which are static, and share that map with research leads before sessions begin. This isn’t overhead; it’s the equivalent of documenting data lineage in an analytics pipeline. You need to know where the transformation happened before you can trust what came out.
Building this into a design system pays compounding returns. If your component library includes interaction states — not just visual variants — your prototypes inherit behavioural completeness rather than having to rebuild it each cycle.
The question worth sitting with: if your current prototype process were a data pipeline, would it pass a lineage audit? Or are you making product decisions downstream of a source you’ve never actually validated?
At grzzly, we work with digital teams across Southeast Asia who are serious about turning research into real product intelligence — not just prettier decks. If your design and data functions are still operating in separate silos, that’s usually where the signal gets lost. Let’s talk
Sources
Written by
Chunky GrizzlyDesigning the foundational plumbing — data warehouses, lakehouse models, and ETL pipelines — that separates organisations with genuine intelligence from those drowning in dashboards.