Usability Testing
Five people watching their own confusion out loud will tell you more than a month of analytics. Ivan Sp runs qualitative usability research, pairing user interviews and think-aloud testing with the quantitative data from heatmaps and session recordings. Quantitative tools show what happened. Qualitative research is the reliable way to learn why it happened.
User Interviews
Direct conversations with real users gather usability feedback, demographic and psychographic detail, and input that feeds persona-building work. Interviews are relatively inexpensive to run given the insight they produce. A handful of well-run conversations often surfaces friction no analytics dashboard would show.
Think-Aloud Protocol Testing
In a think-aloud session, a user narrates their thinking out loud while completing a specific task on the page. This reveals confusion or hesitation in real time, rather than only as a final drop-off number. The Nielsen Norman Group’s widely cited finding holds here: usability trends emerge after roughly five users per audience segment.
Testing across four distinct segments needs approximately twenty total participants under that guideline, a practical target rather than a rule to hit exactly. Fewer participants still surface real issues, and confidence in a pattern grows as the count approaches that threshold.
Session Analysis Tools
Dedicated usability research tools record and help analyze full usability studies, focus groups, and field research sessions. They diagnose specific reasons visitors leave a site, rather than only that they left. This work goes deeper than a standard session recording, since it is moderated around a specific research question rather than passively captured.
Why Quantitative and Qualitative Get Paired
Quantitative tools, covered under heatmaps and session recording, show behavior patterns across many visitors without explaining motivation. Qualitative methods explain motivation without scaling to every visitor. Neither replaces the other, and a CRO engagement without both is missing half the picture.
Combining With Evidence-Based Design Practice
Investing in evidence-based design decisions reduces the risk of wasting further resources after a site has already been designed and built. Usability testing gathers that evidence before a redesign commits budget to a direction nobody has actually validated with real users.
Run One Session This Week
I suggest a session that needs one person and half an hour.
- Find somebody outside your team who has never used your site.
- Give them a goal, without naming any page or button.
- Ask them to say out loud what they are thinking, continuously.
- Say nothing at all while they work, however uncomfortable it becomes.
The silence is the hard part and it is where the finding lives. Answering a question removes the exact observation you were there to collect.
Where the Standard Usability Advice Breaks Down
When did somebody outside your team last try to complete your main task?
- The usual advice
- Run a large usability study so the findings are statistically valid.
- What holds up in practice
- Usability testing is not a sampling exercise. It finds problems rather than measuring their frequency, and problem discovery saturates quickly. Several small rounds with fixes between them beat one large round that ends in a single report.
Consider a team commissioning a twenty-participant study to be sure of the findings. The study takes eight weeks and produces a thorough report.
Participants six through twenty found almost nothing the first five had not already surfaced. The extra fifteen sessions bought certainty about frequency, which nobody needed.
Ivan Sp runs small rounds and fixes between them. The second round then tests the fixes rather than rediscovering the same problems.
One large study delivers a report at the end. Small rounds deliver a fixed product along the way, for the same total cost.
Every visitor who could not work out what to do next left without telling you why. Five people in a room will tell you in an afternoon.
Four Things Commonly Assumed About Usability Testing
Which of these has kept usability testing off your roadmap?
I meet these four assumptions whenever usability research is proposed.
| Commonly assumed | What actually holds |
|---|---|
| It needs a lab and specialist equipment. | A screen share, a recording, and a defined task cover most of it. Remote sessions work well for web tasks. |
| Colleagues can act as participants. | Anyone who knows the product cannot experience it as a first-time visitor. Their confusion is not the confusion you need. |
| Analytics already shows where people struggle. | Analytics shows where people stop. Motivation, misreading, and false assumptions only surface when somebody narrates them. |
| Five participants is too few to trust. | Testing finds problems rather than measuring frequency. Problem discovery saturates quickly, which is why small rounds work. |
| Users can be asked what they want. | People are unreliable narrators of their own future behaviour. Watching them attempt a task is what produces usable findings. |
The gap between what your team believes about your interface and what a stranger experiences is usually large, and it is invisible from inside.
How Usability Research Is Run
- Think-aloud protocol
- A participant narrates their reasoning while attempting a defined task.
- Participant count
- Nielsen Norman Group publishes that a small round surfaces most usability problems.
- Round structure
- Several small rounds beat one large round, since each round produces fixes to test.
- Task design
- A goal stated without naming the interface elements needed to reach it.
- What it produces
- The reasoning behind a behaviour, which quantitative tools cannot supply.
- What it does not produce
- Statistically representative figures. Five people are not a sample.
- Common pairing
- Heatmaps show what happens at scale, and usability sessions explain why.
- Recruiting
- Participants matching the real audience, rather than colleagues who know the product.
A Worked Example: What Five Sessions Surface
Consider five think-aloud sessions on one booking flow. The findings below are illustrative, written to show what narration adds. No client engagement is described here.
| Observation | What analytics showed | What the participant said |
|---|---|---|
| Stopped at the pricing section | Exit at 68 percent scroll depth | I could not tell if this included the callout fee |
| Hovered on the form for 40 seconds | Long time on page | I was looking for how long this takes |
| Opened a second tab | Session appeared to continue | I went to check if they were licensed |
| Abandoned at the date picker | Form abandonment event | It would not let me pick a Saturday |
| Completed the booking | Conversion recorded | I almost gave up at the price bit |
I treat the right column as the finding. The left column recorded five behaviours and explained none of them.
Analytics is a security camera with no sound. You can see exactly where somebody turned around, and never why.
The final row matters most. A converting visitor who nearly left names a problem that costs you everyone less patient than they were.
How a Usability Round Runs
I define the task before recruiting anyone, since a vague task produces a vague finding.
- Write the task as a goal, without naming the buttons or pages needed to reach it.
- Recruit roughly five participants who match the real audience rather than the internal team.
- Set up screen sharing with recording, and get explicit consent before starting.
- Ask the participant to narrate their reasoning continuously while attempting the task.
- Avoid answering questions during the session, since the answer removes the finding.
- Note the exact moment of hesitation, and the words used, rather than a summary of it.
- Write findings as observations rather than as solutions, so the fix stays a separate decision.
- Group findings by how many participants hit them and how badly each was blocked.
- Fix the blocking problems before running the next round.
- Run the next round on the same task, which tests the fixes rather than rediscovering the problems.
How This Engagement Is Scoped
I scope usability work by the number of tasks tested rather than by participant count.
- What arrives
- Session recordings, a findings document grouped by severity, and a fix priority list.
- Typical duration
- Two to three weeks per round, including recruiting.
- What the client supplies
- Access to the interface, and participants or a recruitment budget.
- Included
- Task design, recruiting support, session facilitation, and the findings document.
- Not included
- Design and development of the fixes, and statistically representative sampling.
- What changes the estimate
- Hard-to-reach audiences, several tasks, or interfaces behind a login.
- How it is quoted
- After a short scoping call, once the tasks and audience are defined.
Tools and Primary Sources
The references below cover the method and the recruiting. Each opens in a new tab.
- Nielsen Norman Group on participant numbers publishes the reasoning behind small round sizes.
- Nielsen Norman Group on think-aloud testing documents how to run a narrated session without leading the participant.
- Microsoft Clarity supplies the quantitative side, showing whether an observed problem occurs at scale.
- WCAG 2.1 overview covers the accessibility requirements a usable interface also has to meet.
Common Questions
How many users need to be interviewed for reliable results?
Around five users per distinct audience segment is the commonly cited threshold for surfacing consistent usability trends. Fewer still produce useful signal, and confidence builds as the count grows within a segment.
Is usability testing only useful before a redesign?
It carries the most value there, and it also applies to an existing site with a specific underperforming page or flow, where testing narrows down the actual cause rather than guessing at a fix.
How does usability testing differ from a general customer survey?
A survey gathers stated opinions at scale with little depth per response. Usability testing observes actual behavior on a specific task, in far more depth, with a much smaller number of participants.
How many participants are actually needed?
Nielsen Norman Group publishes that a small round surfaces most usability problems, because discovery saturates quickly. The purpose is finding problems rather than measuring how often they occur.
Discuss This Work
The first call is a free 30-minute consultation with no pitch attached. You receive an honest assessment of where the site stands and what can realistically be built.