How do I run usability tests with no budget?

Give a real person a realistic task, ask them to think out loud, and watch where they get stuck. That is a usability test. You do not need a lab, a panel, or a paid tool.

A cheap test looks like this:

1. Three to five people who are close to your real users.
2. Three or four tasks written as everyday goals.
3. A prototype or live page, on their device or yours.
4. You, quiet, taking notes, or a recording you review after.

Then fix the worst problems and test again with a few new people. Small and repeated beats big and once.

Jakob Nielsen's article "Why You Only Need to Test with 5 Users" (Nielsen Norman Group, March 2000) is the most quoted source on this. Its main claim: "The best results come from testing no more than 5 users and running as many small tests as you can afford." In its model, one user finds about 31% of problems, and five users find about 85%.

The caveats matter as much as the number, and they are often dropped:

• It is about repeated small tests. If you can afford 15 users, the article says to run three studies of five, fixing problems between each, not one study of 15.
• It only holds for similar users. In the article's words, "The formula only holds for comparable users who will be using the site in fairly similar ways."
• Different groups need their own testers. For two distinct user groups, it suggests 3 to 4 users from each. For three or more groups, 3 from each.
• Never fewer than three. It warns of "the spurious behavior of a single person."

So "test with five" means "test with five similar people, fix, and test again." It is not a promise that five people find everything.

NN/g calls thinking aloud "the #1 usability tool." You ask participants "to use the system while continuously thinking out loud." Nielsen notes that "No special equipment is needed," and that even a poorly run study still gives reasonably good findings.

How to run it well:

• Say it is the design being tested, not them. People relax and talk more.
• Prompt gently if they go quiet: "What are you thinking?" Do not explain the screen.
• Do not rescue them. NN/g warns that interruptions from an untrained facilitator "can very easily change user behavior."
• Note what they do, not just what they say. People "want to appear smart" and may filter their words.

Its limits: it does not give detailed statistics, and talking to yourself is unnatural. Treat findings as clues to fix, not numbers to report.

From NN/g's guide to task scenarios:

• Make it realistic. Ask for something the person would actually do.
• Make it actionable. Ask them to do it, not describe how they would.
• Avoid clues. Do not reuse the label on the button. "Step descriptions often contain hidden clues as to how to use the interface."

Keep it specific, though. NN/g notes that "Avoiding clues does not mean being vague."

Hallway or guerrilla tests. Ask people near you for five minutes with your prototype. Nielsen's 1994 "Guerrilla HCI" essay argues you can test "without sophisticated labs, simply by bringing in some real users." The catch: whoever is nearby may not be like your users. Use it for obvious problems, not fine judgement.

Remote moderated. A video call with screen sharing. NN/g's article on remote testing notes you can still ask follow-ups, but silence is harder to read. Is the person confused, or just reading?

Remote unmoderated. People do the tasks alone, on their own time, through a tool. It is fast, but you cannot ask follow-ups, and NN/g notes think-aloud can fade with "no one there to remind" them. Free options, as checked on 14 October 2026:

Check the pricing page yourself before you plan around a limit. They change.

• List every problem, then rank by how many people hit it and how badly it blocked them.
• Fix the top few, not all of them.
• Test again with new people. This is the loop the five-user article is really about.

A usability test answers a different question from an A/B test. On the ImagineComputer paywall I worked with three A/B-tested variants. An A/B test tells you which version won. Watching people use a design tells you why they struggled. You want both. My paywall guide covers the A/B side.

1. Pick one flow from your best project and write three tasks with no clues in them.
2. Test it with three people this week, thinking aloud, on a call or in person.
3. Fix the worst problem, then test with three new people.
4. Put the before and after in your UX case study.

If you have not talked to users yet, start with user interviews, and check your screens against the accessibility basics before you test.