How to Run a Usability Test on Your Indie SaaS With Five Users

To run a usability test on your indie SaaS, pick three or four tasks that matter (getting from signup to a first result, doing the core job, upgrading), write each one as a short realistic scenario that does not hint at where to click, and watch five people who match your buyer try them on a screen-share call while they think out loud. You stay quiet, write down every place they hesitate, misread or give up, then rate each problem by how bad it is, fix the worst ones, and test again with five new people. One round takes about a week of part-time work, costs little more than a few thank-you gifts, and usually shows you problems you would never spot yourself, because you already know how the product works.

What is a usability test, and what is it not?

A usability test is simple: a real person tries to do a real task with your product while you watch. You are not testing the person. You are testing whether someone who did not build the product can get the job done with it. It is easy to confuse with other things, so:

• It is not a survey. Surveys collect opinions. A usability test collects behaviour, which is usually more reliable than people predicting what they would do.

• It is not a demo. If you drive the screen, you show the product in the hands of the one person who knows every shortcut. The participant drives.

• It is not "do you like it?" Most people are polite to a founder's face. "Looks great" tells you nothing. Watching someone click the wrong menu three times tells you a lot.

• It is not a customer interview. Interviews explore someone's problem before your product. A usability test assumes they have the problem and checks whether your product solves it without help.

• It is not an experiment. Five people cannot tell you which version converts better. They can tell you why people get stuck. If you are trying to pick a winner between two versions with little traffic, that is a separate job, covered in running A/B tests when your product has low traffic.

Why are five users enough for one round?

The number comes from Jakob Nielsen's article Why You Only Need to Test with 5 Users (Nielsen Norman Group, 2000). Based on earlier research with Tom Landauer, he describes a curve: the first user shows you almost a third of the usability problems in a design, each extra user repeats much of what you already saw, and by the fifth you are mostly watching the same problems again. He writes that once a first study with five participants has found 85% of the usability problems, you will want to fix them in a redesign.

The part founders skip is the next point: run several small tests, not one. Nielsen's example is that if you could afford 15 users, spend it on three studies with five each. The second round checks whether your fixes worked, catches problems the fixes introduced, and gets past the surface issues that blocked people in round one.

Know the limits before you quote "five users" at anyone:

• It assumes similar users. The article says the formula only holds for comparable users who use the product in similar ways. If you have very different groups (say, the person who sets up the account and the people who only use it), Nielsen recommends 3 to 4 users from each group when testing two groups, and 3 from each when testing three or more.

• It is about finding usability problems. It says nothing about conversion rates, pricing, demand or whether people will pay. Five people cannot give you a percentage you should trust. And the 85% figure is a model built on averages from past projects, so treat five as a practical default, not a law.

• It is not "test with one". The article warns that a single person can mislead you with accidental or unusual behaviour.

A running example (made up)

To keep this concrete, the rest of the post uses a fictional product. Sprigroster is a made-up tool that helps volunteer organisers of community gardens assign plots, share a watering rota and remind people when it is their turn. It has a free plan and one paid plan for gardens with more than 30 plots. Everything about Sprigroster, its users and the notes and numbers in the tables below is made up to show the method.

Which tasks should you test?

You get about 30 minutes with each person, so you can test three or four tasks, not your whole product. Pick the paths where a failure costs you the most. For most indie SaaS products that means:

1. Signup to first value. From the landing page to the first moment the product does something useful for this person. For Sprigroster: sign up and set up a garden with a few plots.

2. The core job. The thing people pay you for, done once from start to finish. For Sprigroster: create a watering rota for next month and share it with the gardeners.

3. A common second step. Something people need in their first week that is not obvious. For Sprigroster: swap one person's watering day with someone else's.

4. Upgrade or billing (optional). Can someone find the paid plan and understand what changes? You do not need anyone to enter a real card. Stop them at the payment form.

If you are unsure which paths matter, look at where people go quiet. Signups who never finish setup, support emails that start with "how do I", and trial users who log in once and never return are all pointing at a task worth testing.

How do you write tasks that do not give away the answer?

Task wording decides whether the test teaches you anything. Nielsen Norman Group's article on turning user goals into task scenarios gives three rules that hold up well: make the task realistic, make it actionable (ask them to do it, not to tell you how they would do it), and avoid giving clues or describing the steps. That includes not using the exact words on your buttons and menus. If your button says "Create rota" and your task says "create a rota", you have only tested whether people can read.

The same article also warns against the opposite mistake: avoiding clues does not mean being vague. Give people the details they would really have, like a date, a name or a number, so they are not stuck guessing what you want.

Before any real session, read your tasks to a friend or try them yourself in a fresh account. If a task needs you to explain what you meant, rewrite it.

How do you recruit five people this week?

The five people need to match your buyer. A designer friend testing a tool for garden organisers will find different problems from an actual garden organiser. In rough order of usefulness:

• Recent signups who stalled. People who signed up in the last two weeks and did not finish setup. They have the problem and already hit a wall. Do not use the session to sell to them.

• Trial users or free-plan users. Good for testing the core job and the upgrade path.

• Your waitlist. If you have not launched, these people asked to hear from you and have never seen the product.

• Communities where your buyers already talk. Ask openly, follow the group's rules, and say plainly what you are asking for. If you have no buyers yet, other builders can still catch the most basic problems, and getting brutal feedback from other makers covers that route.

Avoid colleagues, close friends and anyone who has watched you demo the product. They know too much and they like you too much.

A short recruit message works better than a long one. Something like this:

• Subject: Could you spare 30 minutes to help me fix Sprigroster?

• Body: Hi Sam, you signed up for Sprigroster last week, thank you. I am the founder and I am trying to make setup easier. Would you do a 30-minute video call where you try a few things in the app while I watch and take notes? There are no wrong answers, I am testing the product, not you. As a thank-you I will give you three months of the paid plan for free. Here is my calendar link if you are up for it. If not, no problem at all.

Make the thank-you fair for the time you are asking for. A few months of your paid plan works if they will actually use the product; a small gift card works if they will not. Promise it up front and send it the same day, whatever happens in the session. Ask about eight people to get five, because some will not reply and someone will miss the call.

How do you run a 30-minute remote session?

Use any video call tool with screen sharing, and have people use their own computer or phone in their own browser, because that is how they meet your product in real life.

Nielsen Norman Group's article Thinking Aloud: The #1 Usability Tool sums up a basic study in three steps: recruit representative users, give them representative tasks, and let the users do the talking. The same article is honest about the weak spots: talking non-stop is unnatural, people tend to edit their thoughts to sound smart, and a facilitator's prompts can easily change what the user does. The script below is built around those risks.

A simple session script

1. Welcome (about 3 minutes). "Thanks for doing this. I am testing the product, not you, so if something is confusing, that is exactly what I need to see. I built it, but you will not hurt my feelings. Please share your screen when you are ready."

2. Consent (about 1 minute). Ask permission to record before you press record, and say what happens to the recording (more on this below).

3. Explain thinking aloud (about 2 minutes). "As you go, please say what you are looking at, what you are trying to do and what you expect to happen. Say it even if it feels obvious. If you go quiet, I might ask what you are thinking."

4. A warm-up question (about 2 minutes). "How do you handle watering at your garden today?" Keep it short.

5. Tasks (about 18 minutes). Paste each task into the chat as written, one at a time, and ask them to read it out. Let them tell you when they think they are done.

6. Wrap-up (about 4 minutes). "What was the most confusing part?" and "Was there anything you expected to find and did not?" Then thank them and confirm the thank-you.

What to say while they work

Most of the job is staying quiet. Silence feels long on a call, but it is usually the person thinking. When you do speak, keep it neutral:

• "What are you thinking right now?"

• "What did you expect to happen there?"

• "What are you looking for?"

• When they ask you a question ("Is it this button?"), turn it back: "What would you do if I was not here?"

Avoid anything that teaches or judges: "Good", "Right", "Almost", "Try the menu on the left", or explaining why the screen works the way it does. Every hint you give is a problem you will not see.

What to do when someone is really stuck

Decide your rule before the session. A workable one: if someone has been stuck for about two minutes and is getting frustrated, or says they would give up, mark the task as failed in your notes, then say "That is really useful, thank you. Let me show you where it is so we can try the next part." A task someone finished only with your hint still counts as failed.

Should you record the session, and how do you get consent?

Record if you can, because you will miss things while taking notes. Recording screen and voice is enough. A face camera is optional.

Get consent properly, and before you start recording:

• Say it in the invite and again on the call: what you record (screen and voice), why (to fix the product), who will see it (you, and anyone helping you build), and how long you keep it.

• Ask them to say yes out loud at the start of the recording, so the consent is on the file.

• Ask them to close other tabs, email and chat before sharing, so you do not capture private messages or notifications. Use a test account if real data would be sensitive.

• Store recordings somewhere private, do not post clips publicly without separate permission, and delete them when you said you would. Set a calendar reminder.

This is general good practice, not legal advice. If you record people in a country with specific consent rules, or you handle sensitive data, check what applies to you.

What goes on an observation sheet?

One row per moment of trouble, not per session. Write what you saw and heard, leave the fixing for later, and keep quotes in the person's own words. Here is part of a made-up sheet from a first Sprigroster round:

Fill it in during the session or straight after from the recording. Do not wait until all five are done. By then they blur together.

How do you turn the notes into a fix list?

After the fifth session, group rows that describe the same underlying problem. In the made-up sheet above, P3 and P4 are one problem (people do not know the rota needs sharing), and P1 shows a word problem (your "plot" is their "bed").

Then rate each problem. Nielsen's article on severity ratings for usability problems describes severity as a mix of frequency (how many people hit it), impact (how hard it is to get past) and persistence (does it keep bothering people, or only once), and gives a 0 to 4 scale: 0 is not a usability problem, 1 is cosmetic only, 2 is minor, 3 is major and important to fix, 4 is a usability catastrophe that must be fixed before release. The same article says that, in his experience, ratings from a single evaluator are too unreliable to be trusted, which is worth remembering when you are the only one rating. If you can, have someone else rate the list too, without seeing your scores, and compare.

Fix the 4s and 3s first, and try the smallest change that removes the problem rather than redesigning a whole screen. Some fixes are copy, not code. If people stall on an empty first screen, getting new users past a blank first screen has ideas worth borrowing.

Should you run unmoderated tests instead?

In an unmoderated test, software gives participants the tasks, records their screen and voice, and you watch the recordings later. Nielsen Norman Group's guide to unmoderated user tests lays out the tradeoff clearly:

• Faster, but no one to help or follow up. There are no calls to book and results can come in within hours, but participants cannot ask what a task means, and you cannot ask why they did something. Early or half-built products are hard to test this way.

• Less engagement. Without a person watching, participants tend to engage less with tasks that need imagination or decisions.

• Tasks must be even better written. The guide notes that writing tasks is where most people fail, and unmoderated tasks need to say clearly when to stop.

• Panels have catches. Narrow B2B audiences usually need to be recruited yourself, and frequent panel testers may hunt for things to criticise.

The guide also notes that features and pricing of these tools change often, so compare them against what you need at the time. For a solo founder's first rounds, moderated calls with your own users usually teach more per hour. Unmoderated tests are worth a look once your tasks are solid and you want to check a fix quickly.

When should you test again?

As soon as the top fixes are live. Recruit five new people (not the same five, who now know the product) and run the same tasks. You are checking three things: did the fixes remove the problems, did they create new ones, and what was hiding underneath? The second round often finds deeper issues, like people not understanding what the product is for, that were blocked by surface problems the first time.

After that, a light habit works: a small round whenever you change signup, setup or the core job, or every month or so if things are moving fast.

What are the common traps?

• Helping too much. The most common one. Every rescue hides a problem. Decide your stuck rule before the session and stick to it.

• Testing with the wrong people. Friends, other founders or anyone who has seen your demo will breeze through things your buyers trip on.

• Leading tasks. If the task uses your button labels, you tested reading, not usability.

• Arguing with the result. "They just did not read it properly" is the sound of a real problem being ignored. If one person missed it, others will.

• Turning numbers from five people into stats. "60% failed" from five people is three people. Report what happened, not percentages.

A 7-day plan

The days are a planning guess for one founder doing this alongside everything else, not a measurement.

FAQ

How many users do I need for a usability test?

For one round with similar users, five is a sensible default, based on Nielsen's well-known article. Then fix what you found and run another round of five. If you have clearly different user groups, test 3 or 4 from each instead.

Can I run a usability test before launch?

Yes, and it is one of the best times, because changes are cheap. Use waitlist or community members who match your buyer. A clickable prototype works for early checks if you moderate the session, so someone can explain the gaps.

Should I pay people for a usability test?

Offer a fair thank-you, promised up front and given whatever happens in the session. Never make it depend on finishing tasks or saying nice things.

Where should you start this week?

Open your list of recent signups, find the people who started setup and never finished, and send eight of them the recruit message today. Write three tasks tonight, check that none of them uses your button labels, and book your first call for the day after tomorrow. Once the fixes are live and new people are getting through setup without you, a listing on IndieHunt is a good way to put the improved product in front of founders and early adopters looking for new tools.