The most expensive research is the kind that answers the wrong question. Not far behind: none at all. When no research exists, the loudest opinion holder in the room usually decides — known in product teams as the HiPPO problem (Highest Paid Person's Opinion). The agenda item "What does the user want?" gets ticked off by gut feeling, and three months later the feature quietly fails after launch, visible only in the analytics curve.
User research is not an academic exercise. It is the tool that ensures your team builds the right thing — before the budget runs out. The question is not whether, but which method when.
Every user research method can be placed on two axes. This framing comes from the Nielsen Norman Group school of thought and is considered the basic scaffolding of applied user research:
Axis 1 — attitude vs. behaviour: What people say vs. what they do. That sounds trivial; it isn't. In interviews users frequently say they would complete a step without difficulty — and then fail at exactly that spot in a usability test. Attitudes are self-reported experience; behaviour is what actually happens.
Axis 2 — qualitative vs. quantitative: Understanding the why vs. measuring the how much. Qualitative methods deliver depth and context. Quantitative methods deliver certainty about scale and prevalence. Both are necessary — alone, each is incomplete.
Combining the two axes produces four quadrants:
| Qualitative | Quantitative | |
|---|---|---|
| Attitude | User interviews, diary studies | Surveys, satisfaction scales |
| Behaviour | Usability tests, contextual inquiry | Analytics, A/B tests |
Before you choose a method, ask yourself: do I want to understand or to measure? And is it about what people think, or about what they do? The answer leads you to the right quadrant.
What it is: a moderated one-on-one conversation with a target-group representative, typically 45–60 minutes. Not a questionnaire — open questions, active listening, follow-ups.
When to use it: early in the project, when you don't really know the target group yet. Also useful after quantitative findings you can't explain ("Why do 40% of users drop off on page 3?").
What it delivers: motivations, mental models, frustrations, the context of use — things no analytics table contains.
Typical effort: 5–8 conversations for first stable patterns. Recruiting, moderation, analysis: 2–4 working days in total.
Most common mistake: leading questions — questions that already contain the answer ("Don't you also think the checkout is too long?"). Good interview questions start with "Tell me about…" or "How do you go about it when…".
What it is: you observe a user doing their real work in their real environment — no lab, no tidied-up desk. The method was developed by Karen Holtzblatt and Hugh Beyer and combines observation with targeted follow-up questions.
When to use it: when you build software for complex workflows (accounting, warehouse management, production control) and don't know how the job is actually done — as opposed to how the process documentation says it is done.
What it delivers: undocumented workarounds, real context factors (noise, interruptions, parallel tools), the mental map behind the workflow.
Typical effort: 3–5 visits of 90–120 minutes each. Factor in travel time.
Most common mistake: switching into product-demo mode and starting to explain how to do it "properly".
What it is: a structured questionnaire sent to a larger user group, completed online. From short in-app micro-surveys (3 questions, 2 minutes) to extensive satisfaction studies.
When to use it: when you already know what you want to ask and scale is what matters. "How many of our users have this problem?" is a quantitative question — right for a survey.
What it delivers: distributions, frequencies, segmentations. NPS, CSAT, CES as well-known metrics.
Typical effort: 50–200 responses for stable statements (depending on segmentation depth). Questionnaire design is underestimated — bad questions produce unusable data.
Most common mistake: running surveys too early, before qualitative insights exist. You can only ask about things you already understand conceptually.
What it is: real users perform defined tasks with a product or prototype while you observe (and take notes). Moderated means a moderator attends live and asks clarifying questions. Unmoderated means the session runs automated (tools like Maze, Lookback, UserTesting.com) and the user records their screen.
When to use it: as soon as there is something to test — even early click dummies. Moderated tests when you need deep understanding, unmoderated when you need speed and scale.
What it delivers: concrete findings: "4 of 5 test participants can't find the cancel-subscription link." No interpretation required. How to plan, run and analyse tests in detail is covered in our complete usability testing guide.
Typical effort: 5 moderated participants identify the majority of severe usability problems, per Nielsen's well-known rule of thumb — to be read as a heuristic, not a law of nature. Unmoderated tests: 20–50 participants for quantitative statements.
Most common mistake: testing only shortly before launch. Then the findings arrive too late to change the architecture — only cosmetic fixes remain.
What it is: participants sort given content cards into groups of their own choosing and name the groups. Open card sorting (free grouping) vs. closed card sorting (predefined categories to sort into).
When to use it: when you are designing or reworking a navigation, an information architecture or a category structure.
What it delivers: your users' mental model of your content — which things belong together, what they should be called.
Typical effort: 15–30 participants for stable clusters. Remote via Optimal Workshop or Maze, roughly 20 minutes per person.
Most common mistake: overloading the sort with too many cards (more than 40 cards overwhelm participants and produce noise instead of signal).
What it is: the counterpart to card sorting. Participants see only the text navigation (no visual design) and are asked to find content in it. No scrolling, no images — just the hierarchy.
When to use it: right after card sorting, to validate the drafted information architecture. Also useful before a relaunch, to benchmark the existing navigation.
What it delivers: a measurable findability result per navigation node. You see where users take wrong turns and where they get lost.
Typical effort: 20–50 participants. The remote tool (Optimal Workshop, Treejack) runs unmoderated. Analysis shows success rates and directness scores.
Most common mistake: tree testing without prior card sorting — then you're testing a structure that was never built on user data.
What it is: analysis of usage data from tools like Google Analytics 4, Matomo, Hotjar or Mixpanel. Funnels show where users drop out of a defined flow (checkout, registration, onboarding).
When to use it: always, when analysing a live product. Analytics are the base instrument of every UX audit — they show you where to look.
What it delivers: a quantitative description of behaviour: bounce rates, dwell time, click paths, conversion rates. It shows the what, not the why.
Typical effort: runs continuously. A targeted funnel analysis for a specific question: half a day to a day.
Most common mistake: treating analytics as the only research source. The number tells you that 60% drop off — not why.
What it is: two (or more) variants of a page or element are shown simultaneously to different user groups. The winner is the variant with the better target metric (click rate, conversion, abandonment rate).
When to use it: when you have a concrete hypothesis ("a red CTA button converts better than a grey one") and enough traffic to reach statistical significance. Rule of thumb: at least a few hundred conversions per variant per week.
What it delivers: a causal statement about the effect of a design change — under constant conditions.
Typical effort: one-time tool setup (Google Optimize is no longer developed — alternatives: VWO, AB Tasty, Optimizely). Runtime depending on traffic: 2–6 weeks per test.
Most common mistake: stopping tests too early ("the red button is ahead!") or testing too many variables at once — then you know something was better, but not what made the difference.
| Situation | Recommended method combo | Why |
|---|---|---|
| We're building something new and barely know the target group | User interviews + (possibly) contextual inquiry | Understand first, then structure. Using quantitative methods now would mean measuring the wrong things. |
| Our conversion is poor and we don't know why | Analytics funnel analysis → usability testing (moderated) | Analytics shows where the problem is. Usability testing shows why it's there. |
| The team is arguing about the navigation | Card sorting + tree testing | Brings user data into the discussion instead of opinions. Ends arguments through evidence. |
| We have two design variants and need to decide | Unmoderated usability testing or A/B test (depending on traffic) | Little traffic / no live product: usability test. Lots of traffic, clear metric: A/B test. |
| Relaunch coming up, analyse the existing site | Tree testing of the old IA + analytics audit + 5 user interviews | Benchmarks what's broken; delivers prioritisation. Part of a full UX audit. |
| We want to know whether our users are satisfied | In-app micro-survey (CSAT/CES) + NPS survey | Quickly scalable; shows trends over time. Qualitative follow-up when scores drop. |
| New feature — measure its effect after launch | A/B test (if traffic allows) or analytics funnel before/after + short user interviews | Prevents a feature's success from resting on backslapping alone. |
1. Interviewing friends and colleagues Your network is always too close to the product or the agency. Colleagues say what they consider sensible, not what real users experience. Recruiting genuine target-group representatives takes more effort — but the difference in data quality is enormous.
2. Asking leading questions "Would you use this feature?" — almost everyone says yes. People are polite, especially towards strangers who explain what they built. The question must capture concrete past behaviour or behaviour in a task, not a hypothetical future.
3. Drawing quantitative conclusions from small qualitative samples
5 usability test participants are good enough to find severe problems. They are not good enough for the claim "80% of our users find X difficult". Deriving that number from n=5 is a category error.
4. Doing research without a decision attached Research whose results end up in a PDF and never influence a design decision is money thrown away. Before you start a research project, it should be clear: who decides what based on these results? Otherwise the document is archived and nothing changes.
5. Doing research only after launch "We'll test after launch" is the most widespread excuse to avoid research. After launch, expensive architecture decisions no longer change. Research pays off most early in the process, when everything is still malleable — even a rough paper prototype is testable.
The short answer: less than you think, but more often than you do it.
Nielsen's well-known rule of thumb says 5 users in a moderated usability test identify the majority of severe problems. It is a rule of thumb — not a law — but it frees you from the idea of recruiting hundreds of participants for every test. Better: 5 participants now, another 5 after the next iteration step.
In our projects we see the same pattern over and over: teams planning one big annual research project reach insights less often than teams running two interviews every four weeks. Research works best when it is part of the product team's rhythm — not a one-off event.
A pragmatic baseline for a mid-market project:
That adds up to perhaps 8–12 working days spread across a project. Compared with the effort of reworking a misconceived feature after launch, that is cheap.
How it all connects — which research insights translate into a customer journey — is covered in our article on user journey mapping as a synthesis tool.
If you are looking for UX design support where research doesn't end as a separate document but flows directly into design decisions, that is exactly the process we offer.
User research is not an academic appendix but the foundation for design decisions that don't rest on opinions. The two axes (attitude vs. behaviour, qualitative vs. quantitative) help you pick the right method for the right question. A few targeted studies early in the process have more impact than one big research project at the end. The most common mistake is not the wrong method — it is research whose results never influence a decision.
Good research doesn't need a big apparatus — but it does need a clear question and the will to actually use the results. In a free 30-minute initial consultation we'll clarify which research methods make sense for your project and how they fit into a lean UX process.
