UX Research That Answers a Question Worth Asking

How many users do you need to test with?

For finding usability problems, five participants per user group typically surfaces the majority of significant issues. For questions about preference, proportion or statistical confidence, five is nowhere near enough.

The distinction matters and gets confused constantly. Qualitative usability testing asks "can people complete this task, and where do they struggle?" — problems repeat quickly across participants, so a small group finds most of them. Quantitative questions like "what percentage of users prefer A?" need sample sizes large enough to say anything meaningful.

Testing with five people and then reporting percentages is the most common misuse of small-sample research. Five out of five is not ninety-five percent of anything. We will not present it that way.

Is UX research worth it for a small business?

Often more so than for a large one, because a small business has less margin for building the wrong thing and usually cannot afford to discover it after launch.

The version that works at small scale is not a research program. It is five usability sessions before committing to a redesign, or six customer interviews before building a feature. Both are inexpensive relative to what they prevent, and both routinely change the plan.

What is not worth it at small scale is comprehensive discovery research with no specific decision attached. That produces a thorough document, a sense of having been rigorous, and no change in what anyone does.

What is the difference between UX research and analytics?

Analytics tell you what happened at scale. Research tells you why it happened. Neither substitutes for the other and using only one is where most teams get stuck.

Analytics will show you that forty percent of users abandon a form on step three. That is precise, complete and useless on its own — it does not tell you whether the field is confusing, the requirement is unreasonable, or the page is broken on a common device.

Research answers that in an afternoon of watching people attempt it. Equally, research alone cannot tell you how many people are affected or whether a problem is worth fixing at all. Using analytics to find where to look, and research to find out why, is considerably more efficient than either in isolation.

Why does research so often get ignored?

Because it arrives as a document rather than as a decision, and because the people who needed convincing were not in the room when the evidence appeared.

A report describing eleven findings of varying severity, delivered after the deadline for the decision it was meant to inform, will be read once and filed. This is not a failure of the research — the fieldwork may have been excellent. It is a failure of framing and timing.

What changes this is unglamorous: agree the decision before starting, get stakeholders watching sessions live rather than reading about them, prioritize findings so the top three are unmissable, and deliver while the decision is still open. Watching one real user fail at something your team believed was obvious does more than any slide summarizing it.

What can research not tell you?

Whether people will pay. Stated intent and actual purchasing behavior are famously different, and no amount of careful questioning closes that gap.

It also cannot reliably tell you what people want that does not exist yet. People describe improvements to what they know. That is genuinely useful for identifying current problems and unreliable as a guide to novel solutions.

Small qualitative studies cannot tell you how common something is. Finding that three of five participants struggled with a step tells you the step is worth examining. It does not tell you what proportion of your users would — that is a different question needing different methods.

Saying this plainly is part of the job. Research presented as more certain than it is causes worse decisions than no research, because it carries authority it has not earned.

How do you recruit the right people?

By defining the behavior that matters rather than the demographics that are easy to filter on.

The useful screener asks what someone has done recently, not who they are. "Have you booked something like this in the last three months" identifies relevant experience; an age bracket and a job title usually do not.

Your own customers are the obvious source and carry a specific bias: they already chose you and made it past whatever obstacles exist. That is exactly the right group for improving an existing product and exactly the wrong group for understanding why others did not get that far.

Incentives should be enough to respect someone's time without selecting for people motivated primarily by the incentive. And the screener needs to be written so people cannot easily work out which answers get them in, because some will.

Why does research get ignored?

Usually because it arrived without a decision attached, or arrived after the decision was already made.

A report delivered at the end of a project competes with momentum. The design is agreed, the build is scheduled, and a finding that implies rework will lose that argument regardless of how sound it is. Research has to happen while the decision is still open.

Format matters more than it should. A sixty-page document is a monument; nobody reads it and it changes nothing. A short list of findings ranked by severity, each with the evidence behind it and a concrete suggestion, gets acted on.

And the team needs to have watched some of it. A stakeholder who has seen one person struggle with their product for ten minutes is more persuaded than one who reads about it. Getting people into the sessions is the most reliable way to make findings land.

What is the difference between research and analytics?

Analytics tells you what happened at scale. Research tells you why it happened, in depth, for a small number of people. Neither substitutes for the other and both are weaker alone.

Analytics has complete coverage and no explanatory power. It can tell you eighty percent of people abandon at a particular step, which is valuable and actionable only up to a point — it cannot tell you whether the cause is confusion, cost, missing information or a broken button on one device.

Research has explanatory depth and no coverage. Five sessions can tell you exactly why that step confuses people. They cannot tell you whether that reason accounts for most of the abandonment or a minority of it.

The efficient sequence is analytics first to locate the problem, research second to understand it, then analytics again to verify the fix worked. Skipping the first step means researching things that do not matter much; skipping the second means guessing at causes.

What does a research output look like?

Short, ranked, and specific enough to act on without a follow-up meeting.

Each finding needs three things: what was observed, how often and with what severity, and what evidence supports it. A clip or a quote does more than a paragraph of description, because it is harder to argue with and easier to remember.

Ranking is what makes it usable. A flat list of twenty issues gets skimmed and shelved. The same twenty ordered by how badly each blocks the task, and how many participants hit it, becomes a work plan.

It should also say what was not found. Areas that were tested and worked are genuinely useful information — they stop a team spending effort on something that is already fine, which is a common and invisible waste.

How do you research with almost no budget?

By using what you already have before recruiting anyone, which is more than most organizations realize.

Support tickets are a continuously updated record of what confuses your customers, written in their own words. Reading a few months of them, categorized roughly, identifies more real problems than most commissioned studies.

Site search queries are the second free source. What people type into your own search box tells you what they expected to find and could not, and empty-result searches are a direct list of gaps.

Your sales and front-line staff hear the same objections repeatedly. Asking them what people always ask is a research method, and it costs a conversation.

And five people is genuinely enough for most usability questions. Recruiting from your own customers, running sessions remotely, and watching rather than asking will surface the significant problems without any budget beyond time — which is why we would rather tell you to do that than sell a study you do not need.