Sevginur Ak Parlak
Jun 1, 2026
4 min read
You Don’t Need a Huge Study to Find the First UX Problems
User research sometimes sounds bigger than it needs to be.
When my clients hear “usability testing,” I think they often imagine a long process. Many users, formal interview scripts, long reports, weeks of analysis, and a lot of preparation before anything useful comes out of it.
And yes, sometimes we need that level of research.
If we are making a high-risk product decision, validating a new market, comparing different user groups, or trying to measure something with more confidence, a deeper research process makes sense.
But not every UX question needs to start there.
Especially in the early stage of a product, even watching a few real users try to complete a simple task can show a lot.
Many UX problems show up early
Nielsen Norman Group has a classic guidance around testing with 5 users. The idea is not that 5 users will answer every research question perfectly. They will not.
Five users will not give us full market validation, tell us everything about every customer segment or replace analytics, surveys, or larger research studies.
But that is not the point.
The point is that many usability problems are not hidden very deep. They show up quite early when real people try to use the product without the context the team already has.
A label that makes sense to the team, but not to the user.
A button people do not notice.
A form field that makes people stop and think.
A flow that follows the business logic, but not the user’s mental model.
These are the kinds of issues that can become visible very quickly.
Not because the test is perfect, but because the product is finally being used by someone who does not already know how it is supposed to work.
Teams are often too close to the product
This is one of the hardest parts of product design. As a team, we already know the logic. We know why the page is structured that way, what the label means, where the button is, which step comes next, what the edge case is or what the user is “supposed” to understand.
But users do not have that context.
They arrive with their own assumptions, habits, distractions, and expectations from other products they use every day. So something can feel very clear inside the team and still feel confusing for the user.
This is why internal reviews are useful, but limited.
A product team can review a flow ten times and still miss the first layer of friction, simply because everyone in the room already understands the product too well.
Small tests change the conversation
Even a small usability test can change the way we talk about a product.
Before testing, many discussions are based on opinions.
“I think this is clear.”
“I think users will understand it.”
“I think this button is visible enough.”
“I think this flow makes sense.”
After watching users, the conversation becomes more grounded.
We can see where people hesitate.
We can see where they misread something.
We can see where they click the wrong thing.
We can see where they stop and ask, “What does this mean?”
That does not mean every user comment should become a design change. But it gives us something more useful than opinions. It gives us real moments to discuss.
Early research is not about creating the perfect report
For me, the goal of early research is usually not to create a perfect research report.
It is to reduce the first layer of uncertainty before the product goes in front of more people. At this stage, I am not trying to prove everything. I am trying to understand:
Where do users get stuck?
Which parts are unclear?
Which actions are not visible enough?
Which words create doubt?
Which steps feel different in real use than they did in Figma?
This kind of testing does not need to be heavy.
Sometimes it can be a short session with a prototype, a roleplay around a real scenario, watching a user complete one important flow or testing one screen before building the full experience.
The important part is not making the process look impressive and getting closer to how people actually use the product.
Small tests are not small because they are less valuable
I think small research sessions are sometimes underestimated because they look too simple. But simple does not mean weak.
A 30-minute usability test can reveal a problem that would be much more expensive to fix later. A few user sessions can show that we are solving the wrong part of the flow. One confused reaction can make us rethink a label, a step, or a key action.
Of course, we should not overclaim from a small sample. We should not say “all users will behave like this” after watching a few people. But we can say:
“This issue appeared more than once.”
“This part created hesitation.”
“This label was not clear.”
“This action was missed.”
“This flow needs more clarity before we build further.”
And that is already useful.
The goal is fewer blind spots
Good research does not always need to be big.
Sometimes the most helpful thing is to bring a few real users into the process early enough, before the team has already invested too much in one direction.
Small tests, done more often, can save teams from designing in the dark.
They help us move from assumptions to observations and in product design, that shift matters a lot. Because the goal is not to make research look perfect. The goal is to make better product decisions before confusion becomes expensive.
Source: Nielsen Norman Group
https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
