Existing Users First
Recruiting from your own product is faster and more relevant than any panel.
SaaS UX Research
SaaS UX Research With the Users You Already Have
A SaaS product has something most projects do not: a population of people using it right now, whose behaviour is recorded and who can be contacted. SaaS UX research exploits that — continuous, in-product, aimed at what to build next and why people leave, rather than the one-off discovery study that happens before a product exists.
We Research With Real Users, Continuously
A one-off study answers the questions you had that quarter. A running practice answers them as they arise.
Behaviour Plus Interview
Usage data locates the question; conversation answers it.
Churn Interviews
The most informative conversations available and the least often held.
Feature Validation
Before building, on something people can react to.
Findings That Reach the Roadmap
Research that nobody acts on is a cost.
What makes a research finding trustworthy
Research is only useful if its conclusions hold. These checks are about whether a finding reflects what users actually do, or an artefact of how the study was run — which is the difference between evidence and expensive confirmation of what the team already believed.
Question defined firstWhat decision this research exists to inform, agreed before recruiting
Participant fitWhether participants match the actual user, not merely the demographic
Recruitment biasWhether the sample over-represents engaged or available users
Task realismWhether participants did real work or performed a scripted demonstration
Leading questionsWhether the script suggested the answer it received
Stated versus observedWhether conclusions rest on what people did or what they said they would do
SaturationWhether new sessions stopped producing new findings
Disconfirming evidenceWhether anything contradicted the hypothesis, and what happened to it
Finding traceabilityWhether each conclusion links back to specific observations
Decision impactWhat the team will do differently as a result
Stated versus observed is the distinction that invalidates most product research. What people say they would pay, use or prefer is a poor predictor of what they do. Findings drawn from observed behaviour are worth acting on; findings drawn from stated intention need treating as a hypothesis rather than a result.
SaaS Research, Explained
What Questions Does It Answer?
Four, and all four are about a product that already exists.
Discuss Your Research →- 1
Why Do People Leave?
Answered by asking them, which almost nobody does.
- 2
What Should We Build?
From observed friction rather than from feature requests.
- 3
Does This Work?
Validating a concept before it is built.
- 4
Who Actually Uses It?
Which frequently differs from who it was designed for.
What SaaS Research Covers
A running practice rather than a one-off study.
Pre-build discovery for new products is covered by UX research. Pre-build discovery is UX research; the activation problems this usually surfaces are addressed in SaaS UX design.
How We Run SaaS Research
Establish a cadence rather than a project. The value is in continuity.
Set the Questions
What the team needs to know this quarter.
Recruit From the Product
Real users, segmented by behaviour.
Combine Data and Conversation
Usage to locate, interview to explain.
Report Small and Often
Findings while they are still actionable.
Keep It Running
A cadence, not a study.
What question the research is answering
The method follows from the question. Confusing the two produces studies that are well run and answer something nobody needed to know.
Teams deciding what to build
Where the question is what problem is worth solving. This needs observation of how people work today, including their workarounds, rather than asking what features they want — users describe solutions and are usually right about problems.
Teams deciding whether something works
Where a design exists and the question is whether people can use it. Usability testing on realistic tasks answers this directly, and a small number of sessions surfaces most of the significant problems.
Teams with conflicting internal opinions
Where the argument has stalled and each side has plausible reasoning. Research resolves it only if both sides agree in advance what evidence would change their mind, which is worth establishing before any sessions are run.
Products with unexplained analytics
Where the data shows what is happening and not why. Watching a small number of users at the point the data goes wrong usually explains it faster than further analysis, because the cause is often something no metric captures.
Teams entering an unfamiliar domain
Where the product serves specialists whose work the team does not share. Here the research is largely about learning the domain well enough to design for it, and it should precede any UX strategy decisions rather than validate them.
Churn
Why Nobody Interviews Churned Users
It is the most informative conversation available and the most uncomfortable to arrange.
What do churn interviews produce?
Specific, unflattering, actionable reasons. Not "it was too expensive" — which is what a cancellation form collects — but the workflow it never supported, the integration that was missing, the report they had to build by hand every month.
Cancellation surveys collect a category. A conversation two weeks later collects the story, and the story is what tells you whether it was fixable.
People are generally willing to explain, particularly if they liked the product and left for a specific reason. The barrier is almost entirely that nobody wants to make the call.
Why do feature requests mislead?
Because users describe solutions rather than problems, and the solution they name is shaped by whatever software they used previously.
A request for a particular kind of export is usually a symptom of something upstream — a report that cannot be read in the product, a workflow that lives in a spreadsheet.
Building the requested feature satisfies the request and leaves the underlying problem intact. Asking what they were trying to do, before building, is the difference.
Users are reliable about problems and unreliable about solutions
Asking people what they want produces requests for features, and those requests are usually a description of a solution the person has imagined rather than the problem underneath it. Building the requested feature frequently fails to help, because the request was a guess made by someone without visibility of the alternatives.
What users are reliable about is their own experience: what they were trying to do, what got in the way, what they did instead. That information is factual and observable, and it is the material a designer can actually work from. The discipline is to keep asking what happened rather than what would help.
This is why observation outperforms interviewing for product decisions. Watching someone do their work reveals the workarounds they have stopped noticing — the exported spreadsheet, the second window, the manual check — and each one marks a place where the product failed and the person compensated.
How much research is enough
The most common objection to research is that a small number of participants cannot be representative. For usability problems that objection misapplies statistical reasoning: the goal is not to estimate a proportion but to find defects, and a small number of sessions surfaces the majority of significant problems because most users hit the same obstacles.
Where sample size genuinely matters is in questions about prevalence — what share of users do this, how often does that occur. Those are quantitative questions, and qualitative sessions cannot answer them regardless of how many are run. Analytics answers them better and more cheaply.
Confusing these leads to two symmetrical errors: running twenty interviews to establish a number that analytics already contains, and drawing a percentage from six conversations. Matching the method to the question is what keeps research proportionate to its value.
Research that changes nothing
A significant amount of research is conducted, reported and then has no effect. The reasons are usually structural rather than a failure of the research itself, and they are predictable enough to design against.
The most common is that the question was never tied to a decision. Research commissioned to understand users generally produces findings that are interesting and unactionable, because no specific choice was waiting on them. Agreeing in advance what decision the results will inform is the single strongest predictor of whether they get used.
The second is timing. Findings delivered after the relevant decisions have been made arrive as criticism rather than input, and teams reasonably ignore them. The third is format: a long report is read by fewer people than a short set of specific findings, each tied to an observation and a recommended response.
Questions, answered.
SaaS UX research is continuous research with existing product users — usage analysis, interviews, churn conversations and concept validation — aimed at what to build next rather than pre-build discovery.
General UX research is usually discovery before something is built. This works with a live product and a population of users whose behaviour is already recorded.
Yes, and almost nobody does. A cancellation form collects a category; a conversation two weeks later collects the story, which is what tells you whether the reason was fixable.
Not directly. Users describe solutions shaped by software they used before. Asking what they were trying to do usually reveals a different and more general problem.
On a cadence rather than as a project. A running practice answers questions as they arise; a one-off study answers the questions someone had that quarter.
For finding usability problems, a small number per user type surfaces most of the significant issues, because users tend to hit the same obstacles. For questions about how many or how often, no realistic number of sessions is enough — those are quantitative questions and your analytics answers them better. Matching method to question matters more than sample size.
Yes, and some of the most valuable forms are entirely internal: reading support tickets by theme, watching session recordings, and observing a colleague attempt a task. The main risk is leading — teams close to a product tend to explain rather than observe, and unintentionally coach participants past the exact problems they were trying to find.
The lightweight forms almost always are, because they cost very little. Watching five people attempt your core task will find problems no internal review will. What is harder to justify at small scale is a formal research programme with recruitment and analysis overheads, when the same budget could fix the problems already visible in support tickets.
That is the situation research exists for, and it only works if the terms were agreed beforehand. Deciding in advance what evidence would change the decision converts the finding from an opinion into a result. Where nobody was prepared to be wrong, research becomes an expensive way of confirming a decision already made.
Analytics tells you what is happening across everyone; research tells you why it happens for someone. They answer different questions and neither substitutes for the other. The most efficient sequence is usually analytics first to locate where the problem is, then a small number of sessions at that point to understand the cause.
Still deciding if saas ux research is right for you?
Talk to UsThe Cancellation Form Said "Too Expensive"
Every SaaS product collects a reason at cancellation, from a dropdown with five options. The most selected is usually price, and it gets reported as a pricing problem.
Price is what people select when the real reason is longer than a dropdown allows: the workflow that never quite fitted, the report rebuilt by hand each month, the integration that was promised and never arrived.
A phone call two weeks later gets all of that in fifteen minutes. It is the highest-value conversation available to a SaaS company, and it is avoided because nobody wants to ring someone who just left.
Free Research Review
Talk Through What You Need to Know
Tell us what decisions your roadmap is waiting on. We will propose a research cadence that answers them with your own users.
Claim Your Free Marketing Audit
Enhance Your Brand Potential At No Cost!
- Expect a response within 24 hours
- NDA available upon request
- Dedicated product specialists