User research watches real people use what you built, and reports where they stopped and why they stopped. We recruit people who match your users, run moderated sessions on their own devices, and ask what they expected to happen instead while it is still in front of them. You get findings ranked by how often each one happened and what it is likely to cost.
Book a free 30-min callProjects from €399.
The same terms worked in manual entry, so it is a data problem rather than a search problem.
People saw a score on first open, with nothing logged and no scale to read it against.
Found in a path the team did not know was still reachable.
Most teams expect research to find layout problems, and most of the time the layout is fine. People navigate without help and say the design looks good. What breaks is the data behind it, the order things are asked in, and logic that fires before it has anything to work with.
Those faults are invisible in a design review because the screens look correct. They only appear when somebody who has never seen the product tries to do something real with it, which is the entire reason to run sessions rather than opinions.
The exact screen and moment, with the recording clipped to it, so nobody on your team has to take it on trust.
What they expected to happen instead, asked in the moment rather than reconstructed afterwards from a drop-off chart.
Findings ranked by frequency and likely cost, with a specific fix each, written for whoever schedules the work.
The method follows the question. Most projects use one of these, some use two.
One to one, for understanding a problem before anything is designed.
Real tasks on your build, watching where people hesitate and what they misread.
A Figma or Lovable build clicked through cold, before engineering time goes in.
Whether people can find the thing at all, which is often the whole problem.
The first five minutes, where most products lose the people they just acquired.
Repeated prompts over days, for behaviour that does not happen in one sitting.
When you need the size of a problem rather than the shape of it.
Narrow professional audiences, found by direct outreach. See who we reach.
Five to eight moderated sessions per audience, remote and screen shared, 30 to 45 minutes each, run by a researcher rather than handed to an unmoderated tool. Participants arrive cold and are asked to do the things a new user would actually do.
You see who is taking part before fieldwork starts, and recordings and transcripts are delivered as sessions happen rather than all at the end, so the obvious fixes can start before the report lands.
A Figma prototype, a Lovable build, a TestFlight link, a staging URL or the live product. Nothing has to be finished, and rough is useful: the parts you are least sure about are the parts worth watching somebody else use.
Five to eight sessions per audience finds most of what is wrong. The fifth session rarely shows something the first four did not. If you have two distinct audiences, you need five to eight of each rather than ten split between them.
We moderate. An unmoderated tool shows you where somebody stopped. A moderated session lets us ask why in the moment, which is the difference between knowing where people stopped and knowing what stopped them.
No. A Figma prototype, a Lovable build, a TestFlight link or a staging URL is enough. Research before launch is cheaper than research after it, because you can still change what it finds.
Yes. You can observe live, and recordings and transcripts are delivered as sessions happen rather than at the end, so your team can start acting on the obvious things immediately.
Recordings, full transcripts, clipped moments, each finding marked on the screen it came from, a ranked list with how often it happened and what it is likely to cost, a suggested order of work, and a readout call. The raw material is yours to keep. See how we work.
Send us a build or a link and we will come back with a scope, a task list and a figure.