After conducting thousands of usability studies over the past two decades, I’ve become comfortable saying these phrases over and over again:
“Imagine that button works.”
“Pretend this page would update.”
“Let's assume those filters would return the right results.”
Every UX researcher has said some version of this.
We say it because prototypes have limitations. Early designs aren’t fully coded. Timelines are compressed. Budgets are finite. Testing something is almost always better than testing nothing.
But there’s an uncomfortable truth I’ve been thinking about after a recent project. Every time we ask a participant to pretend, we’re introducing a confounding variable into the research. The more assumptions participants have to make, the further we move away from observing real behavior.
It’s the usability testing equivalent of the legal concept “fruit of the poisonous tree.” If the evidence is influenced by assumptions we asked participants to make, then those assumptions inevitably pollute the findings. Not enough to invalidate the research—but enough to influence the design decisions that follow.
Of course, experienced researchers know this. We mitigate it. We acknowledge it. We increase fidelity over time. We qualify our recommendations. And we recognize that iterative testing, even at low fidelity, is vastly better than waiting until development is complete. But I don’t think any of us can honestly say that lower-fidelity prototypes don’t affect participant behavior. Sometimes they absolutely do.
And that’s why a recent client engagement feels like a genuine inflection point. What we learned and our confidence in those findings, particularly in the variable-heavy checkout process, would not have been possible just months before.
We were redesigning the digital experience for Overseas Adventure Travel (a leading small-group adventure travel company serving the 50+ market) focusing on the entire product discovery journey—from arriving on the homepage, to browsing and filtering hundreds of trips, evaluating detailed itineraries, and progressing through a multi-step booking flow.
Historically, this would have ended with a sophisticated Figma prototype or, before that, Axure. And while our team has always been world class in using the most advanced tools to bring a design to life, there is always an element of pretend.
For OAT, we dove in head first to AI-assisted coding and built a fully-interactive prototype once our design work matured. Not because we wanted to impress anyone with AI. Because we wanted to stop asking people to pretend.
Participants weren’t clicking through a carefully choreographed sequence of static frames. They were interacting with real trip information.
Real prices.
Real photography.
Real filtering logic.
Real sorting behavior.
Large result sets.
Edge cases.
The interface behaved like a real website, not an approximation of one. That changed the dynamic of every research session.
Instead of constantly narrating caveats—
“Imagine this...”
“Pretend this updates...”
“Assume these filters work...”
—we simply observed.
Participants explored naturally. They made mistakes naturally. They discovered things naturally.
Their feedback felt less hypothetical and more grounded in actual experience because of the heightened fidelity level. A couple example benefits of this “real” prototype:
- Users were able to configure almost any trip available on the live site. This created an attachment to an itinerary they actually wanted instead of a contrived one with less emotional connection.
- In checkout, users could enter promotional codes and accurately apply them at any point in the process. This enabled us to understand the impact of the feature within each step of the flow.
Interestingly, AI didn’t replace our design process. It accelerated it.
As our Figma designs approached completion, AI could translate those designs into working code remarkably quickly. Instead of waiting for final design approval before beginning prototyping, design refinement and prototype development happened in parallel. Small design changes that once would have delayed the prototype became inexpensive to implement.
Even more importantly, we could populate the experience with hundreds of real travel products, prices, and images—something that would have been prohibitively time-consuming to recreate inside Figma.
The result wasn’t just a prettier prototype. It was a dramatically more believable one.
I don’t think this means Figma prototypes disappear. They remain incredibly valuable throughout product design.
Nor do I think every project now requires a coded prototype. There will always be moments where sketching, wireframes, and lightweight prototypes are the right answer. But I do think we’ve crossed an important threshold.
For years, the gap between prototype and production has been one of the unavoidable limitations of usability testing. That gap just became much smaller.
And when the prototype behaves more like the final product, the research behaves more like reality.
As researchers, our job isn’t to validate designs. It’s to understand human behavior. The closer we can get participants to behaving the way they would with a real product, the more confidence we should have in the insights we bring back to our clients.
That, more than AI itself, is the real breakthrough.