How to Run User Testing on a Shoestring

You do not need a lab, a research team or a big budget to see where people get stuck in your product. A laptop, a short script and a handful of the right people will show you more in one afternoon than weeks of guessing. Here is how to run user testing on a shoestring and turn what you see into fixes that make a real difference.

Two colleagues standing at a wall covered in colorful sticky notes, discussing ideas together — The real work of user testing happens when you sort what you saw into clear patterns.

Key takeaways

User testing means watching real people try to complete real tasks with your product or prototype.
Small, frequent rounds with a few participants beat one big, expensive study.
Write tasks as realistic scenarios, never as instructions that give away the answer.
Your own customers, waitlist and community are often the cheapest source of testers.
Get clear consent before recording anyone, and store recordings carefully.

Most founders know they should test with users. Fewer actually do it, usually because it sounds slow, formal or costly. The truth is that a scrappy test you run this week is worth far more than a perfect study you never get around to. Even three or four sessions can reveal the confusing button, the missing step or the pricing page nobody understands.

This guide focuses on usability testing: checking whether people can use what you have built or designed. It is different from early problem interviews, where you explore whether a need exists at all. Both matter, but they answer different questions.

Decide what you want to learn

Every round of testing should start with one or two clear questions. Without them, sessions drift into general chat and you finish with opinions instead of evidence. Good questions are specific and tied to a decision you need to make.

Can new users sign up and reach their first useful result without help?
Do people understand what each pricing plan includes?
Can a returning customer find and change their booking?
Which of two onboarding flows feels clearer?

Then choose what to test. It does not have to be finished software. Paper sketches, clickable prototypes, a staging site or the live product all work. Testing early, before you write code, is the cheapest time to discover a problem.

Pro tip

Write down what you expect to happen before the first session, such as "most people will find the export button within a minute." Comparing your prediction with reality is a quick way to spot your own blind spots.

Write tasks people can actually try

Tasks are the heart of a user test. A good task describes a realistic situation and a goal, but never tells the person which buttons to press. Compare these two versions:

Weak: "Click Settings, then Billing, and change your plan."
Strong: "Your team has grown and you need more seats. Show me how you would sort that out."

The strong version lets you see whether people can find the path on their own. Keep each session to three to five tasks so participants stay fresh, and start with an easy one to build confidence.

A simple test script template

Copy this table into a shared document and fill in one row per task. The examples below are made up for a fictional booking app.

Task	Scenario to read aloud	Success looks like	Watch for
1. First booking	"You want a haircut next Tuesday afternoon. Book it."	Booking confirmed without help	Hesitation on the time picker
2. Reschedule	"Something came up. Move that appointment to Thursday."	Booking moved, no duplicate created	Looking in the wrong menu
3. Check price	"Before you go, find out what the appointment will cost."	Correct price found in under a minute	Confusion about extras or deposits

Add a short opening ("We are testing the product, not you, and there are no wrong answers") and two or three closing questions, such as "What was the most confusing part?" and "What would you change first?"

Find participants without a big budget

Recruiting is where many teams stall. The good news is that you often already have access to the right people. Aim for participants who resemble your real customers, not friends who will be polite.

Existing customers. Invite them by email or in your app. Many are happy to help shape a product they use.
Your waitlist or newsletter. People who signed up early are usually curious and motivated.
Communities. Relevant online groups, local business networks and industry forums, where the rules allow it.
Lost leads. People who tried a demo but did not buy can give especially useful feedback.
Hallway testing. For very early prototypes, someone outside your team can catch obvious problems, even if they are not a perfect match.

A short screener form helps you pick the right people. Free or low-cost form builders such as Google Forms, Typeform, Tally or Jotform work well. Ask two or three questions that confirm someone fits your audience, then let them pick a slot with a booking tool such as Calendly.

A small thank-you, such as a gift card or account credit, increases response rates. Keep it modest, and in your own records note who received what. If you plan bigger or regular payments, check with an accountant about how they should be handled.

Common mistake

Testing only with friends, family or teammates. They know too much, want to be kind and rarely match your customers. You end up with a product that works brilliantly for people who will never buy it.

A person sitting with a laptop, hands on the keyboard while working through something on the screen — Remote sessions let you watch someone use your product from their own desk and device.

Run the sessions

You can run tests in two main ways. Many shoestring teams mix both.

Moderated sessions

You sit with the participant, in person or on a video call, and watch them work through the tasks while they think aloud. You can ask follow-up questions, which makes moderated sessions rich in insight. They take more of your time, so they suit early testing and complex flows.

Unmoderated sessions

Participants complete tasks on their own, usually through a testing tool that records their screen and clicks. You review the results later. This saves time and scales well, but you cannot ask "why?" in the moment. Tools such as Maze, Lyssna and UserTesting support this kind of testing. Plans and features vary, so check current pricing, features and privacy policies before you choose.

For moderated sessions, this simple flow keeps things on track.

Set up. Test the prototype link, recording and video call before the participant arrives.
Welcome and consent. Explain the purpose, how long it will take and how any recording will be used, then confirm consent.
Warm up. Ask one or two easy background questions about how they handle the task today.
Run the tasks. Read each scenario aloud and ask them to think aloud as they go.
Stay quiet. Resist helping. If they ask "should I click this?", reply "what would you do if I were not here?"
Debrief. Ask the closing questions and thank them.
Write notes straight away. Spend ten minutes capturing the top issues while they are fresh.

Invite a colleague to take notes so you can focus on the participant. Engineers and designers who watch even one session often fix problems faster than any written report could persuade them to.

Turn observations into fixes

After a round of sessions, gather your notes in one place. A wall of sticky notes or a simple shared document both work. Write one observation per note, such as "3 of 4 people missed the reschedule link," then group similar notes together.

Rate each issue by severity, using a simple scale:

Blocker: people could not complete the task.
Major: people completed it, but with clear struggle or errors.
Minor: small friction or cosmetic issues.

Fix blockers first, then majors. Make the change, then test again with a few new people. That loop of small rounds, quick fixes and retesting is what makes shoestring testing so effective. A common rule of thumb is that around five participants per round surfaces most of the major issues in a single flow, though complex products or very different user groups may need more.

Hypothetical example

Imagine Tomás, who runs a small app that helps freelance photographers send proposals. He recruits four photographers from his newsletter, offers a month of free credit as a thank-you and runs 30-minute video sessions. Three of the four cannot find where to add a deposit to a proposal, because the option sits behind an icon with no label. He renames it "Add deposit," moves it under the price field and tests with three new people the following week. All three find it in seconds. The whole round costs him a few hours and some account credit.

Consent, privacy and storing recordings

Recording sessions is incredibly useful, but it involves personal data. In the UK and EU, data protection rules such as GDPR apply to recordings and notes about identifiable people, and privacy laws also apply in many US states. This is general information, not legal advice, so check the rules where you and your participants are based.

Tell participants what you are recording, why and who will see it, and get clear consent before you start.
Ask them to close personal emails and notifications before sharing their screen.
Use test accounts and dummy data where you can, rather than their real information.
Store recordings in a secure, access-controlled place and delete them when you no longer need them.
When sharing clips internally, use first names only or anonymize them.

Your shoestring user testing checklist

Write one or two questions this round should answer
Choose what to test: sketch, prototype or live product
Draft three to five scenario-based tasks
Build a short screener form and recruit from customers or your waitlist
Prepare a consent note and a simple thank-you
Run the sessions, staying quiet and taking notes
Group observations and rate them by severity
Fix blockers first, then retest with new participants
Store or delete recordings according to your privacy notice

Frequently asked questions

How many people do I need for a user test?

For a single flow, a small round of around five people is a common rule of thumb, and even three can reveal big problems. It is usually better to run several small rounds with fixes in between than one large round.

Can I test before I have a working product?

Yes, and it is often the best time. Paper sketches and clickable prototypes let you find confusing flows before any code is written, when changes are cheapest.

Should I pay participants?

A small thank-you shows respect for their time and improves turnout. Many customers are happy with account credit or a modest gift card. Keep incentives consistent and record them.

How often should we run user tests?

Many small teams test before each significant release or once a month. A light, regular rhythm keeps customer reality in front of the team without slowing development.

The bottom line

User testing on a shoestring comes down to a clear question, a few realistic tasks, the right participants and the discipline to watch without helping. Run small rounds, fix the biggest problems first and test again. Each loop makes your product easier to use and your decisions less of a guess.

Pick one flow that worries you, write three tasks today and book your first sessions for next week. The insights will likely surprise you, and the fixes are often quicker than you think.