Why User Research Keeps Getting Skipped Until It’s Too Late
Most software teams can point to a feature nobody uses. Ask why it was built and the answer is usually some version of “we thought it would help.” That gap, between what a team assumes users need and what users actually do, is exactly what user research exists to close, and it’s the step most commercial software projects quietly skip in favour of moving straight to building.
Key Takeaways
- Skipping user research doesn’t remove assumptions from a project; it just leaves them untested until launch.
- Interviews and usability testing answer different questions: what people say they want versus what they actually do when using the product.
- Small-sample qualitative research, five to eight users, reliably surfaces most major usability problems.
- Research done after a product ships is diagnostic, not preventive; it explains failure rather than avoiding it.
- The method matters less than doing it early enough to change a decision that’s still cheap to change.
Business leaders commissioning software often treat user research as a nice-to-have that gets traded away when a timeline tightens. That trade looks efficient in a project plan and expensive six months later, when the finished product doesn’t match how the people using it actually behave.
The two kinds of research that get confused
A lot of confusion in this space comes from treating “user research” as one activity when it’s really several, answering different questions. The Nielsen Norman Group’s long-running breakdown of UX research methods draws a useful distinction between attitudinal research, what people say about their needs and preferences, and behavioural research, what people actually do when using a product. Interviews and surveys sit in the first category. Usability testing and analytics sit in the second.
The two frequently disagree, and that disagreement is the point. People are reliably poor at predicting their own future behaviour, especially with software they haven’t used yet. A business that only asks customers what they want, without watching what they do, tends to hear a polished version of the truth rather than the messier reality that actually shapes product decisions.
A researcher taking notes while observing someone use a laptop application
Small samples do most of the work
One of the most persistent myths in this area is that research needs a large sample to mean anything. Jakob Nielsen’s original research with Thomas K. Landauer in 1993, later summarised in his widely cited 2000 Nielsen Norman Group article, found that testing with around five participants uncovers the large majority of a product’s usability problems, because most serious issues aren’t rare edge cases; they’re things most users hit in roughly the same way. The UK government’s own service manual on user research, first published in 2013 and built from running research across public services used by millions, treats small, frequent rounds of testing as the default approach rather than occasional large studies.
This matters for smaller businesses that assume proper research is out of reach without a dedicated research team or budget. It generally isn’t. A handful of structured sessions, watching someone try to complete a real task with a working prototype, catches more than most businesses expect, and catches it early enough that the fix is a design change rather than a rebuild.
The cheapest point to discover a product doesn’t match how people actually behave is before it’s built, not after.
What gets missed by skipping straight to building
Software commissioned without upfront research still embeds assumptions, they just go untested. A form assumed to take two minutes takes ten because the fields don’t match how the business’s actual customers think about their own information. A dashboard assumed to be checked daily gets opened once a month because it doesn’t answer the question the user actually has in that moment. None of this shows up until real people are using the finished product, at which point changing it costs considerably more than it would have during design.
This is part of why question-led design, structuring a product around the actual questions a user is trying to answer rather than a generic form, tends to outperform assumption-led design. Arch’s work on a fall and near-miss logging app for people with Parkinson’s took this approach directly, structuring entries around the questions clinicians and patients actually needed answered rather than a standard data-entry form, informed by research with the people who would use it. More of that thinking is set out on Arch’s own site, including how the same principle applies outside healthcare software.
Sticky notes and a whiteboard mapping out a user journey
Making research part of the process, not a phase
Research works best woven through a project rather than treated as a single upfront phase that gets signed off and forgotten. The Interaction Design Foundation’s overview of user research frames it as an ongoing input to decisions throughout a build, not a one-off deliverable that justifies the initial brief. A short round of testing on a clickable prototype, before a single line of production code is written, catches problems research done only at the concept stage would miss.
For a business without in-house research capability, the practical version of this is simple: talk to a handful of real or representative users before committing to a design direction, watch them attempt real tasks rather than asking hypothetical questions, and treat what surprises the team as more valuable than what confirms the existing plan. Confirmation feels reassuring. Surprise is where the useful information actually is.
None of this needs to be formal. A founder sitting beside a customer while they try to complete a task on a rough prototype, taking notes on where they hesitate or misread a label, is doing real research even without a script or a report to show for it afterwards. What makes it count is watching closely enough to notice the moment something doesn’t work the way it was assumed to, and being willing to change the plan because of it rather than defending the original design.
Frequently Asked Questions
How many users do you need for useful research?
A small number, often five to eight participants in a single round of usability testing, typically surfaces most major usability problems. Larger samples matter more for quantitative questions like conversion rates than for identifying where a design confuses people.
What’s the difference between what users say and what they do?
What people say reflects their stated preferences and predictions about future behaviour, which are often inaccurate. What people do, observed through usability testing, reflects actual behaviour with the product in front of them. Both are useful, but they answer different questions and shouldn’t be treated as interchangeable.
Is user research only necessary for large or consumer-facing products?
No. Internal tools and business software benefit just as much, arguably more, since a confusing internal tool creates ongoing friction for staff who have no choice but to keep using it. Smaller user bases just mean smaller, quicker rounds of research rather than none at all.
When in a project should user research happen?
Ideally before design decisions are locked in, and again on a working prototype before production build begins. Research conducted only after launch still has value, but it explains what went wrong rather than preventing it.
Can user research be done without a dedicated research team?
Yes. A structured round of five or so sessions, run by whoever is designing or commissioning the product, following a clear task-based script, catches the majority of major issues. It doesn’t require specialist tooling, just a willingness to watch rather than assume.
