Key takeaways
- The importance of UX research lies in replacing assumptions about users with evidence before design and engineering time is spent.
- Boehm and Basili (2001) wrote that fixing a software problem after delivery is often 100 times costlier than in requirements and design, and more like 5:1 for small, noncritical systems.
- In Pendo's 2019 data, 80% of features in the average software product were rarely or never used (615 subscriptions).
- Analytics, support tickets and sales calls show where users struggle; research explains why and reaches the users who stay silent.
- The smallest useful study names one decision, for example 8–10 user interviews for a startup or 5 participants per usability round.
For a five-minute user experience (UX) self-audit that tests the importance of UX research on your own product, list the last three features your team shipped and, beside each, how the team decided users needed it. Typical notes read "a user said so in a session", "lots of support tickets", "a stakeholder asked" or "a competitor had it". Only the first is evidence from users.
If most notes name a stakeholder or a competitor, your roadmap runs on assumptions, and testing them before the build is what our UX research services exist to do. Every note that is not evidence is a bet, and this article lists five costs of those bets, answers six myths teams use to keep betting, names the cases where skipping research is fine and sizes the smallest study that still changes a decision.
What is the importance of UX research, in one answer?
The importance of UX research is that it replaces assumptions about users with evidence before a team spends build time, lowering the risk of building the wrong thing.
UX research, which many teams call user research, studies people's goals, behavior and pain points through interviews, observation and tests. Its main goal is a better product decision, not a report. It is the evidence step of human-centred design, which ISO 9241-210 describes as design based on an explicit understanding of users, tasks and environments. That is why UX research matters even to teams with strong instincts: it turns opinions into data-driven decisions stakeholders can check.
Is user research the same as UX research? Yes, so anyone asking "why is user research important?" gets the same answer. Each study works in one research mode: generative research, which uncovers what is worth building, or evaluative research, which checks whether a design holds up; our guide on how generative and evaluative research differ explains when each fits.
What does a user research example look like?
A typical user research example is a round of interviews with people who canceled, run to find why they left; the illustrative case below is made up to show the pattern.
Eight interviews with former subscribers of a meal-kit app show that most left after a surprise renewal charge, a problem the team had filed under "price". The fix is a clearer renewal reminder, not a discount. Pick one churn label in your own dashboard and ask which interviews would confirm it.
Why is UX research important before you build anything?
UX research is important before build because a wrong assumption about users is cheapest to change while it is still a sentence in a plan or a sketch.
Barry Boehm and Victor Basili's Software Defect Reduction Top 10 List (Computer magazine, 2001) opens with the rule that finding and fixing a software problem after delivery is often 100 times more expensive than during requirements and design. For small, noncritical systems they put the factor closer to 5:1. The rule describes fix cost timing for software defects; a wrong guess about users follows it by analogy, because every stage built on the guess adds work to undo.
Illustrative assumption: "users want bulk export".
| Stage | What changes | What it takes |
|---|---|---|
| Research plan | A sticky note is crossed out | One conversation |
| Prototype | One design frame is redrawn | A revision before the next test |
| Build | Tickets and code are reworked | Engineering time already spent |
| After launch | The flow, help content and replies change | The fix, plus retraining users |
Scale: often 100 times after delivery, closer to 5:1 for small, noncritical systems (Boehm and Basili, 2001).
Public standards follow the same logic. Point 1 of the GOV.UK Service Standard says testing assumptions early and often reduces the risk of building the wrong thing, and play 1 of the US Digital Services Playbook, "Understand what people need", tells teams to spend time with current and prospective users early and test prototypes with real people.
So when should you do UX research? Before design, during design and after launch. Research timing matters because the cost of late changes rises at every stage, which is why UX research is important before teams build the wrong thing. Place your next feature on the timeline above.
What does skipping UX research cost a product team?
Skipping UX research costs a product team in five ways: features nobody uses, late rework, wrong product bets, opinion-led roadmaps and support load after launch.
The table compares each cost by what it looks like and the evidence behind it.
| Cost of skipping | What it looks like | Evidence |
|---|---|---|
| Features nobody uses | Menus full of options few people open | Pendo's feature usage data, below |
| Late rework | Flows redesigned after engineers built them | Boehm and Basili's rule, above |
| Wrong product bets | A product for a problem too few users have | CB Insights' shutdown reason data, below |
| Opinion-led roadmaps | Priorities set by whoever argues longest | No published figure; common when no shared personas or journey maps exist |
| Support load after launch | Tickets about one confusing task | No published figure; count your own tickets per flow |
In Pendo's 2019 Feature Adoption Report, 80% of features in the average software product were rarely or never used, across 615 Pendo subscriptions with over a year of data. That measures feature usage across software in general, not teams that skipped research, but it shows how much built work goes unused. Feature adoption, the share of users who take up a feature, is what those features never reach.
- Finding: 80% of features in the average software product are rarely or never used.
- Sample: 615 Pendo subscriptions for customers on Pendo for more than a year.
- Source: Pendo's 2019 report on how software features are used.
CB Insights' March 2026 analysis of 431 venture-backed shutdowns found reasons for 385 and cited poor product-market fit, a product too few people need or will pay for, in 43%; most had several reasons, so shares exceed 100%. The shutdown reason data does not say those companies skipped research, only that the market did not want what they built, which is the risk early research tests.
The reverse is a competitive advantage: the competitor that asks users first learns what users need before it builds. A later guide on UX return on investment (ROI) will price these costs; their mirror image is what research gives back, from higher feature adoption to less development waste. Mark the row that matches your last release, because that row is the importance of UX research measured in your own product.
Is "we already know our users" a reason to skip UX research?
No. "We already know our users" is an assumption, not evidence, and UX research exists to test it, because people overrate how much others think and act like them.
Psychologists call this the false consensus effect, a cognitive bias that Lee Ross, David Greene and Pamela House described in 1977: people see their own choices as more common than they are. Raluca Budiu's 2017 Nielsen Norman Group (NN/g) article on the false-consensus effect applies it to product teams: designers, developers and even UX researchers assume the people who use their interfaces are like them.
Experience does not close the gap. In Online Experimentation at Microsoft (2009), Ronny Kohavi and colleagues put the experiment success rate at only about one-third: of ideas tested in controlled experiments, also called A/B tests, about a third improved the metric they were designed to improve, and the rest were flat or negative. The authors note a bias, because experiments are run when teams are less sure about an idea, but they add that this bias may be smaller than most people think.
Domain experts are especially exposed, in our practitioner view, because deep knowledge makes their own workflow feel universal. Self-report adds a second gap: what users say differs from what they do, which is why watching users work beats asking them. The case for UX research is that it turns belief into checked fact. Teams that doubt the importance of UX research can list every "we know" statement, mark its evidence and treat the unmarked ones as hypotheses.
Which UX research myths keep teams guessing?
Six UX research myths keep teams building on assumptions, from "analytics explain our users" to "artificial intelligence (AI) can stand in for users", and each fails against evidence.
Each myth sounds like a reason to skip research, and its answer is one of the stronger reasons for UX research.
Myth 1, "analytics already tell us why"
Analytics count what users do, not why they do it.
Low feature adoption with healthy traffic shows a feature is ignored, not whether people missed it, distrusted it or never needed it. Use analytics to choose which flow to research, then interview.
Myth 2, "sales and support already talk to customers"
Sales and support hear a filtered sample: buyers and people with a problem bad enough to report.
Daily users, quiet churners and people with workarounds rarely reach either team. On a sales call for a scheduling tool, for example, the buyer asks about pricing tiers and single sign-on, while the coordinator who opens the schedule every morning is not on the call. Treat both teams' notes as leads, not findings.
Myth 3, "research takes months"
A full UX research program takes 4–8 weeks, and a smaller startup study, for example 8–10 user interviews, already shows which problem to solve.
The program duration spans five steps, from framing to a 90-minute readout. For a startup, those interviews come before engineering budget goes into a minimum viable product (MVP); see UX research methods that fit a small budget.
Myth 4, "users do not know what they want"
Users are poor designers of features, which is why research observes behavior and problems instead of collecting wishes.
A request for "an Excel export", for example, can mean the in-app report cannot be shared with a manager; the request is a clue, and the sharing problem is the finding. Ask what someone did the last time a task went wrong; the problem is the input, and the solution stays the team's job.
Myth 5, "we will fix it after launch"
Fixing after launch puts the change at the most expensive point on the timeline above, and a shipped flow already has users who learned it.
Iterative design works best while iterations are still cheap sketches, before retraining and help content enter the bill. We kept that order on TradeZella, whose revamped trading journal visuals went through tests with traders before launch.
Myth 6, "AI can stand in for users"
Synthetic users, AI-generated stand-ins that answer interview questions, cannot replace research with real people.
Maria Rosala and Kate Moran's 2024 NN/g article on synthetic users says they cannot replace the depth and empathy of studying real people. Our stance matches: AI speeds up the work, but the judgment about what to design comes from research and pattern recognition across 200+ products, so use AI to sharpen an interview guide, then talk to people.
What do your existing sources tell you, and what do they miss?
Existing data shows where users struggle and who complains, but UX research supplies the evidence for why, from users who stay silent and workarounds nobody reports.
Start from what you hold, then research the gaps. The matrix compares five evidence sources by what each tells you, what it misses and the method that fills the gap.
| Evidence source | Tells you | Misses | Method that fills the gap |
|---|---|---|---|
| Analytics | Where users drop off | Why they drop off | User interviews |
| Support tickets | Tasks that break badly enough to report | Silent users and workarounds | Contextual inquiry |
| Sales calls | What buyers ask before signing | Daily users | Interviews with active users |
| App reviews | The happiest and angriest users | Everyone in between | Usability testing |
| Stakeholder opinion | What the business wants | Evidence from users | A research plan built on one decision |
Support tickets capture only problems bad enough to report, and surveys share the blind spot when the team's assumptions write the questions.
Our research program is scoped to close those misses with interviews, contextual inquiry, a card sort and tree test, personas, journey maps and a Jobs to be Done (JTBD) opportunity map. Before anyone questions the importance of UX research for your product, circle the misses in the matrix that describe it.
Why is UX design so important, and where does research fit?
UX design is important because it decides whether a product is useful, usable and valuable to its users, and UX research supplies the evidence for which of those it lacks.
A user-centered product needs both: research names the problem, and design turns it into flows and screens. The importance of UX research shows up in every facet below.
What are the 7 pillars of UX design?
The 7 pillars of UX design usually refer to Peter Morville's user experience honeycomb: useful, usable, desirable, findable, accessible, credible and valuable.
Morville published the honeycomb on his Semantic Studios site in June 2004 and calls the seven qualities facets, not pillars. A research method checks each:
- Useful: user interviews show whether the product solves a real problem.
- Usable: usability testing shows whether people complete key tasks.
- Desirable: concept tests show whether look and tone appeal.
- Findable: card sorting for navigation shows where users expect content.
- Accessible: testing with disabled users finds barriers automated checks miss.
- Credible: interviews about trust show what makes people doubt the product.
- Valuable: tying each study to a business decision shows whether the product serves the business too.
Score your product from 1 to 5 on each facet and research the weakest first.
When can you skip UX research, and when does it matter most?
Skip new UX research when a change is small, reversible and A/B-testable, or the evidence already exists; skipping costs most before a new build, market or redesign.
Skipping research is a sound call for:
- A copy or color change that A/B testing can settle on live traffic, because the experiment measures the answer directly.
- A fixed legal requirement, because research cannot change the rule; test the flow that meets it.
- A question an earlier study answered, because a research repository, the searchable store of past findings, holds it.
Research matters most in the five situations that call for a research program:
- A new product whose team has not interviewed target users.
- A new market whose users follow different workflows.
- Low feature adoption that analytics cannot explain.
- A redesign of navigation and information architecture (IA) never tested.
- Teams that disagree on priorities with no shared personas or journey maps.
Continuous research across the product development lifecycle, such as interviews with users who ignored a new feature, explains what analytics report, and UX research studies like these grow the repository. Sort your next three roadmap items into these lists.
What is the smallest UX research study that changes a decision?
The smallest UX research study that changes a decision names that decision, tests its riskiest assumption with the right users and ends in a finding the team will act on.
The card lists five checks to answer in one shared document before the next build.
Before the next build
- The decision this study must change, and its owner.
- The riskiest assumption behind that decision.
- The users who can disprove it.
- The method that tests it.
- The result that would change the plan.
Sample units: 8–10 user interviews for a startup; 10–15 interview participants per user group in a full program; 5 participants per round of qualitative usability testing.
Write the research goals as one sentence that ends with the decision, and name the decision owner, who changes the plan if the finding says so. Size the interview sample and each usability round with the card's units; a round of 5 participants finds most usability problems in a prototype before the next iteration (Nielsen, 2000).
The value of UX research is easiest to prove with one decision it changed, so put research first, as in how Parents Connect started with research into what parents need, the step before its forum and expert content were designed. Our program price is public, $25,000–$60,000 for 4–8 weeks, and the pricing section shows which study sizes sit at each end of that range.
The importance of UX research comes down to where your team learns it was wrong: in a research plan, in a sprint or in the support queue. Every project begins with a free consultation and a fixed-scope proposal, and the most useful thing to bring is the one decision your next build depends on, written as a single sentence.
FAQs
Is UX research being replaced by AI?
No. AI tools can draft an interview guide, transcribe sessions and summarize desk research, but a model answers from patterns in its training data, not from how your users behave in your product. Use AI to prepare a study, then let real participants decide what gets built.
Is UX research different from UX design?
Yes. UX research studies users to decide what to build and whether it works, while UX design turns those findings into flows, screens and interactions. In our programs, the personas, journey maps and JTBD opportunity map are the input our designers work from.
What is the 5-user rule for user testing?
The 5-user rule says a round of qualitative usability testing with 5 participants finds most of the problems that round can find. Jakob Nielsen's 2000 NN/g article "Why You Only Need to Test with 5 Users" advises several small rounds with fixes in between over one large test; interviews in our program need more, 10–15 participants per user group.
How long does UX research take?
A full UX research program takes 4–8 weeks, or 20–40 working days, across five steps. In that program, user interviews run in the generative fieldwork step, which takes 7–15 days of the total.
Should designers do their own UX research?
Yes, for small evaluative checks such as a 5-participant usability test of a prototype. Dedicated researchers matter when recruiting is hard, user groups differ or findings must settle a disputed roadmap, because a neutral moderator and a planned sample are harder to dismiss. Our usability testing services include participant recruitment and moderated usability sessions.
