You don’t need a UX researcher to watch real users struggle with your product. You need a clear question, three to five users, and a way to record what happens while they try to complete a task.

That matters because more product teams are now making UX decisions without research support. UX research job postings fell 89% from their 2022 peak, and many teams that used to have researchers now have fewer of them, or none at all. Products still ship. Features still need to work. And the question of whether users can actually use what you built still needs an answer.

Real UX testing means watching actual people try to use your product. Not asking them what they think. Not checking where they clicked in analytics. Watching them attempt a task and seeing where they get stuck.

Analytics tells you users dropped off at step three. A survey tells you they found the flow confusing. Real UX testing shows you where they hesitated, what they clicked instead, and what they said out loud when something didn’t work.

For a full explanation of what UX testing is and how real UX testing differs from other methods, see UX Testing: What It Is and How It Works.

What do you need to get started?

You don’t need eye-tracking hardware, a rented lab, or a research background.

What you do need is a clear product decision you’re trying to inform, three to five users (either from your own customer base or a tester panel), and some way to record what happens on their screen while they talk through it.

The steps below are enough to run a useful first test.

Step 1: Pick one question

Before you do anything else, write one sentence: what decision are you trying to make?

• “I need to know if users can complete setup without getting stuck.”
• “I want to see whether this new feature makes sense before we build more of it.”
• “I need to know why people are dropping off during checkout.”

One question, one test.

Teams that try to answer everything at once end up with observations that don’t point anywhere. A focused test with three users answering a specific question is more useful than an unfocused test with ten.

Step 2: Get three to five real users

Three to five users is enough.

Research by Nielsen Norman Group found that five users reveal most usability problems in a single test. Each extra participant after that tends to add less new information. You’re usually better off running a small test, fixing what you find, and testing again.

Two ways to find users:

Your own users. Works well when you’re testing changes to something they already use. UX testing tools like Userbrain let you send them a link that handles screen and voice recording for them. They just click and run through a task.

A tester panel (a pool of pre-recruited real users you can filter by country, device, age, language, and more). When you need people who haven’t seen your product before, a panel gives you real users matching your criteria, usually back within a few hours.

Don’t test with colleagues or friends. They know too much, they want to be helpful, and they’re more forgiving than real users. Their feedback reflects the relationship as much as the product.

Step 3: Give users a goal, not a script

The task you give users determines what you learn.

If you tell them where to click, you’re not testing the product. You’re testing whether they can follow directions.

Frame the task as a realistic situation with a goal.

Instead of	Try this
“Go to Settings and update your email.”	“Imagine you’ve just changed your email address. Update it in your account.”
“Click the checkout button.”	“Imagine you’ve added items to your cart. Complete the purchase.”
“Use search to find a product.”	“Imagine you’re looking for a blue winter jacket. Find one you’d consider buying.”

The left-hand versions are instructions for how to use your product. The right-hand versions are situations a real user might find themselves in. Only the second kind shows you whether someone can figure your product out on their own.

Step 4: Watch before you analyze

When sessions come back, your job isn’t to take notes. Userbrain’s AI does that for each session automatically. What you bring is the watching. Seeing the moments that matter, the ones a transcript or AI analysis won’t catch.

On the first pass, don’t look for patterns yet. Watch what happened. Pay attention to where users pause, what they click by mistake, what they say when they’re confused, and where the product works without friction.

Don’t draw conclusions after the first session. A problem that seems important after one session may turn out to be a one-off after three. Watch everything, mark timestamps, and save the specific moments that changed how you saw the product.

Step 5: Turn observations into findings

After you’ve watched the sessions, look for what repeated.

One user struggling with a button is an observation. Three out of five users struggling with the same button is a finding.

Write findings in a way that points to a fix.

• Observation: Three users tried to click the order total instead of the “Continue to payment” button.
• Finding: The call-to-action is not prominent enough next to the price summary.
• Next step: Change the button hierarchy on the checkout screen.

Avoid vague findings like “users found checkout confusing”. That doesn’t tell anyone what to change.

Specific observations produce specific fixes.

Step 6: Fix one thing, then test again

Pick the most useful finding and fix that first.

Don’t turn every test into a huge redesign. Most teams get more value from fixing one clear problem, then running another small test, than from trying to solve everything at once.

This is where UX testing becomes a habit instead of an event.

A single test tells you what broke this time. A repeatable testing loop shows whether the product is getting easier to use over time. It also catches new problems before they ship.

Why not just use analytics, surveys, or AI feedback?

Analytics tells you where users stopped. It doesn’t tell you why.

A survey tells you what users say about an experience. That can help, but people are often bad at explaining what they did, what confused them, or what they would do in a real situation.

AI-generated feedback can be useful for a first pass. It can simulate likely reactions and point out obvious issues. But it can’t replace watching a real person hesitate on a screen and say, “Wait, I don’t know what this does”.

That moment is the information. It’s what changes how a product team thinks about what they’ve built.

As synthetic feedback gets more capable, the evidence from real users becomes more valuable, not less. For more on this, see our experiment with synthetic users.

How to make UX testing a habit

The teams that get the most out of UX testing don’t run one perfect study. They test often enough that feedback becomes part of how they build.

Run a test before major releases. Run one after changes that affect how users move through the product. Run one when your metrics look off and no one knows why.

A simple rhythm is enough:

• test before changing a key flow
• fix the clearest issue
• test again after the change
• repeat when the next decision needs evidence

The goal is not to become a researcher. It’s to stop making product decisions without watching real users first.