User Testing Techniques for Better Products

Every team I’ve worked with has had that meeting. Ten smart people in a room debating whether the “Continue” button should be at the top or the bottom of the screen. Everyone has a strong opinion. Nobody has any evidence.

The fastest way to end that meeting? Put the design in front of five actual users and watch what happens.

User testing sounds like something you need a research team and a big budget for. You don’t. Let me show you how I approach it, especially when time and money are tight.

Five users is (usually) enough

There’s a famous finding from Jakob Nielsen at Nielsen Norman Group: testing with around five users uncovers most of the usability problems in a design. After that, you start seeing the same issues again and again.

The real lesson isn’t the magic number. It’s this: many small tests beat one big one. Test with five people, fix what you learned, then test again with five more. You’ll learn far more than testing with 20 people once.

Pick the right method for the question

Different questions need different kinds of testing. Here’s a cheat sheet:

Your question	Try this
“Can people figure out how to do X?”	Moderated usability test
“Is this page clear at a glance?”	Five-second test
“Which of these two versions performs better?”	A/B test (needs real traffic)
“Why are people dropping off here?”	Session recordings + interviews
“What do people actually need?”	User interviews, before you design anything

The one I use most is the moderated usability test: you sit with someone (in person or on a call), give them a task, and watch them do it.

How to run a moderated test

1. Write tasks, not instructions

This is the part people get wrong most often. Compare:

Don't:“Click on the Transfers tab and then tap Send Money.”

Do:“You owe your friend 50 cedis for lunch. Show me how you’d pay them back.”

The first one is just testing whether they can follow instructions. The second one tests whether your design makes sense. Give people a goal and a little context, then step back.

2. Ask them to think out loud

At the start, say something like:

“As you go, please say whatever’s going through your mind. What you’re looking for, what you expect to happen, anything that’s confusing. There are no wrong answers. We’re testing the design, not you.”

That last sentence matters. People get nervous and blame themselves when they get stuck. Reassure them that when they struggle, that’s useful information about the product.

3. Stay quiet (this is the hard part)

When someone gets stuck, every fiber of your being will want to help. Don’t.

Watching someone struggle is uncomfortable, but that struggle is exactly what you came for. If you jump in, you lose the insight.

If they ask you a question, bounce it back:

• “What do you think it does?”
• “What would you expect to happen?”
• “Where would you look for that?”

Only step in if they’re completely stuck and it’s blocking the rest of the test.

4. Ask good follow-up questions

After each task, a few open questions go a long way:

• “How did that feel?”
• “Was anything surprising?”
• “What were you expecting to see on that screen?”

Avoid leading questions like “Was that easy?” People are polite. They’ll say yes.

Watch what they do, not just what they say

People are notoriously bad at predicting their own behavior. Someone might tell you “Oh yeah, I’d definitely use that feature,” then never touch it in real life.

So pay closest attention to behavior:

• Where did they hesitate?
• Where did they click first?
• What did they scroll past without noticing?
• When did they sigh or frown?

A hesitation is often more telling than anything they say.

Guerrilla testing: when you have zero budget

You don’t always need recruited participants. Some of my most useful tests have been super informal:

• Grab a colleague from a different team (not the people building the feature)
• Show your prototype to a friend or family member over the weekend
• Ask someone at a coworking space if they’ve got 10 minutes in exchange for a coffee

It’s not perfect. These people may not match your target users exactly. But it’s infinitely better than testing with no one, and it’ll catch the obvious problems quickly.

Turning observations into decisions

After a round of tests, you’ll have a pile of notes. Here’s a simple way to make sense of them:

1. Write each observation on its own sticky note (physical or in FigJam). One issue per note.
2. Group similar notes together. Patterns will jump out fast.
3. Count how many people hit each issue. Four out of five people struggling is a big deal. One out of five might be noise.
4. Rate severity. Did it block them entirely, slow them down, or just annoy them?
5. Pick the top three to fix before the next round.

Then share a short summary with the team. A two-minute video clip of a real user getting stuck is more persuasive than any slide deck. I’ve seen a single clip end a week-long debate in seconds.

Common mistakes to avoid

• Testing too late. If you test after it’s built, changes are expensive. Test with sketches and prototypes.
• Only testing with insiders. Your team knows too much. They can’t unsee how it works.
• Asking “would you use this?” People are bad at predicting the future. Watch what they do now instead.
• Testing and then doing nothing. If findings just sit in a doc, you’ve wasted everyone’s time.

Wrapping up

User testing doesn’t have to be a big, formal process. At its heart it’s simple: give real people a realistic task, stay quiet, and watch closely.

Do it early, do it often, keep it small. And the next time your team is stuck in that endless button-placement debate, you’ll know exactly how to end it.