User research in the age of instant prototypes
Estimated read time: 8 minutes
What does user research look like when a team can spin up an instant prototype at the drop of a hat? It doesn’t change why we do research – we still need to understand users in the round. But it may change how, when, and what counts as evidence.
The fundamentals remain unchanged: go to the source (real users), observe context and behaviour, combine qualitative and quantitative insight, and iterate accordingly. But because building and releasing prototypes is now quicker and cheaper, we can narrow the gap between “research phase” and “delivery phase”. The cadence can increase, and our path from question to evidence shortens.
In the old days (which was perhaps earlier this year…), code was the expensive part. Research de-risked that: interviews, surveys, journey mapping, paper prototypes – all ways to learn before committing to build.
That logic hasn’t vanished, but the economics has inverted.
Code as a research artefact
It’s still unwise to build a huge system without any evidence of need, but the main constraint is not in the cost and time of producing code. The expensive part is not having evidence – not talking to users, not understanding the system you’re altering, not knowing whether the thing you’ve made makes life better or worse. AI-assisted delivery turns code into a readily available research artefact: high-fidelity prototypes we can create in hours to probe a question, and discard when we’ve learned what we needed to learn.
This flips some assumptions. We can try a small thing simply to see how users react, because we haven’t sunk a lot of time into it and we can throw it away. Code becomes another tool in the researcher’s toolkit, like sketches or diagrams, except it behaves like the real experience, which can reveal frictions that a neat mock-up will hide.
Synthetic scaffolding
This is also where synthetic data becomes genuinely useful – not as a replacement for the voice of a user, but as scaffolding for better research into the contours of reality. Synthetic profiles, journeys, personas and datasets can help teams make the picture more concrete: which variations matter, where operational complexity might bite, what ‘normal’ and ‘edge’ cases look like, and what the service would need to handle. It can help you prepare research, generate hypotheses, design safer tests, and spot obvious blind spots early. But it’s no substitute for lived experience. The discipline is to treat synthetic work as provisional: a way to sharpen questions – and then validate, correct, and deepen it with real people.
The point is not that a synthetic persona is “true”. It’s that it lets you hold more possibilities in view at once. A team can generate a spread of plausible life situations, constraints, and failure modes, and use them to pressure-test a journey before you ever put it in front of someone real. Done well, that can widen empathy rather than flatten it, because it is another opportunity to invite questions about who benefits from our assumptions and our ambitions, and who does not.
A direct consequence of instant prototypes is that research can become continuous rather than phase-based or milestone oriented. Teams can adopt a steady cadence of small learning loops. One week you test a concept with a prototype built in a day; the next week you test the same idea behind a feature flag in the real service; the week after you observe how frontline staff use an admin interface updated based on what you learned. The boundary between “researching” and “building” becomes a tight loop.
This shifts the constraint from production to learning. When the team can build in hours, the limiting factor becomes evidence: finding the right users, running research responsibly, and making sense of the results fast enough to steer. We spend less time waiting for environments to be configured and more time staying close to people and reality.
It should also change how we decide to try things. Previously, before committing valuable engineering time, teams would reasonably want high confidence up front. Now, if a hunch emerges from partial evidence, we can use our services to help us learn more – through controlled, reversible experimentation. Release a change to 5% of users, watch completion and drop-off rates, read feedback, and revert quickly if confusion appears. Instead of lengthy debates about whether a form flow might help, tightly designed tests can let the evidence decide.
Evidence still has to touch people
In the public sector, duty of care remains non-negotiable. We do not run random experiments on people when stakes are high, and we don’t expose vulnerable users to unresearched journeys simply because iteration is easy. But many services include lower-risk elements where experimentation is appropriate: wording, navigation, onboarding, reminders, optional guidance, internal tools, non-critical flows. With the right safeguards, we should make better use of A/B testing and multivariate experiments than we might have done in slower delivery cycles. The opportunity is to be more empirical, not more cavalier.
Faster iteration also produces richer data streams. Every small release generates evidence: analytics, support tickets, contact-centre patterns, live chat transcripts, operational signals. Researchers increasingly weave those quantitative traces together with qualitative insight – working closely with data and performance colleagues to set up measures that help the team learn, not merely report.
This is also where AI can help in a way that isn’t about prototyping at all. It can take on some of the heavy lifting: marshalling long documents and messy datasets, pulling themes across dozens of transcripts, summarising patterns in support logs, and helping teams move back and forth between the qualitative and the quantitative without losing the thread. The risk is obvious: you can get a fluent answer that isn’t grounded. So the discipline is the same as everywhere else in this paper: treat it as a partner for sensemaking, not an oracle, and keep the link back to the underlying evidence clear enough that a human can challenge it.
But speed has a cost if learning doesn’t keep up. Five experiments a month is easy; making sense of them, choosing measures that matter, and turning results into decisions the team can stand behind is not. Synthesis becomes a craft in its own right: filtering signal from noise, connecting what users said with what they did, and telling a coherent story about what changed and why. Researchers help ensure the team actually learns from all this data and doesn’t just drown in it.
Beware ‘vibes without people’
There’s a particular danger in the era of instant prototypes: beware ‘vibes without people’. With all this power to create and test quickly, a team might be tempted to rely too much on their own instincts, simulated feedback, or the model’s reassurance (“the AI says this is good”, “the flow feels nice to us”). A small, multi-skilled team using AI at the expense of their users’ input can become an echo chamber at high speed. The antidote is old-fashioned and still essential: regular contact with real users, in real contexts, as a non-negotiable rhythm. Instant prototypes don’t replace talking to humans; they give humans something real to react to.
AI assistance and vibe coding shouldn’t be confined to engineers and product folk. In a faster world, policy, ops, frontline leaders, analysts, and everyone else can author working models of their assumptions – quickly, cheaply, and early – as part of the same multidisciplinary loop. Policy can express intent as a rules engine and stress-test it with edge cases. Ops can prototype an operating model and walk it through with staff. Analysts can build the monitoring view that defines what success looks like in practice.
The point isn’t to generate authority by producing software; it’s to make the thinking visible so it can be challenged, improved, and validated – with real users externally, and real users internally too. Caseworkers, policy owners, assurance, lawyers, finance and commercial partners aren’t “stakeholders at the end”; they’re part of what makes the service operable, lawful and sustainable, so they belong inside the learning cadence.
So user research in a vibe-coded world becomes more integrated and iterative than ever: we research while we build, and build while we research. The barriers to trying something are lower, which can broaden exploration but only if we keep the work anchored in real people, real contexts, and honest evidence. Faster artefacts are not the same thing as deeper understanding. The task is to use speed to get closer to reality, not further from it.