---
title: "How to Run Usability Testing on a Budget | Utkarsh Panwar"
description: "How to run usability testing on a budget: a five-user test plan for one week, task wording that doesn't lead, free recruiting, and a worked FamPay example."
url: https://www.utkarshdesign.com/guides/usability-testing-startups
author: Utkarsh Dhairya Panwar
updated: 2026-10-08
---

# How to run usability testing on a budget

Guide · 5 min read · By [Utkarsh Dhairya Panwar](https://www.utkarshdesign.com/about) · Updated 8 Oct 2026

**Recruit five people who match your users, give each three or four realistic tasks on a prototype or the live product, and watch over a video call without helping. Fix whatever trips up more than one person, then test again. It costs a week and a few small thank-you gifts.**

## Five users, then fix, then five more

Jakob Nielsen made the case in 2000 and it still holds: small tests, repeated, beat one big study. The first few people show you most of the obvious problems; after that you mostly watch the same mistakes again. Fix them and spend the next five sessions on the new version instead.

B2B products complicate this because you rarely have one kind of user. A developer setting up a tool and the admin approving it behave differently. With two groups, test three people from each rather than five from one.

## The week, day by day

1. **Monday: one question, three or four tasks**: Write the question the test must answer ("can a new user recover from a failed payment without contacting support?") and the tasks that will show it. Build or fix the prototype frames those tasks need.
2. **Tuesday: recruit**: Message recent signups, people on the waitlist and customers who wrote to support. Book 30 to 45 minute slots. Over-book by one, because someone always cancels.
3. **Wednesday and Thursday: run the sessions**: Video call, screen shared, recording on with permission. One person moderates, one takes notes. Ask them to think aloud. Don't help, even when it hurts to watch.
4. **Friday: sort and decide**: Put every observation in one sheet, count how many people hit each issue, and pick what to fix before the next round. Share a one-page summary the same day.

## Worked example: testing payment failures at FamPay

FamPay is a payments app for teenagers in India, and I worked on its iOS payment error states: a timeout, a bank decline and a retry. You can't wait for a real bank to decline someone during a session, so the prototype had to include every failure frame, wired to the tasks.

- I wrote tasks as situations rather than instructions: you're told the payment is still processing; what do you do now?
- The sessions showed retry gaps and feedback problems: places where the app didn't make clear what had happened or what retrying would do.
- The redesign gave each failure its own message inside one shared error pattern. What that did to drop-off is in my payment failure guide.

[Read the FamPay case study](https://www.utkarshdesign.com/work/fampay): The voucher flow and the payment error work, with the numbers.

## Writing tasks that don't give the answer away

| Leading task | Better task | Why |
| --- | --- | --- |
| Click Retry to pay again | Your payment didn't go through. Get your order paid for. | Names no button, so you see what they look for |
| Use the Invite button to add your admin | You need your company's GitHub admin to approve this. What would you do? | Tests whether the path is visible at all |
| Find the one-time-use label | Buy a ₹200 voucher for an order of ₹150. | Shows whether they notice the rule before it costs them |
| Do you like this dashboard? | Find which repository needs attention first. | What they do tells you more than what they say they like |

If a task contains the label of the thing you want them to click, rewrite it. The test is whether people can find it.

## Recruiting with no budget

- Your support inbox. People who wrote in about a problem are glad to see it fixed.
- Recent signups who didn't activate. They're the most useful and the hardest to book, so ask briefly.
- Friends of customers in the same role, not your own friends in different jobs.
- A small gift card or a free month is enough thanks for 30 minutes.

If there's nothing to test yet, talk to people instead. Ask about the last time they did the task, not what they'd want; my user interview questions template has a session guide for that.

## The findings sheet

Keep one row per issue, not one row per participant. Five columns are enough:

| Column | What goes in it |
| --- | --- |
| Issue | What happened, in plain words, with the screen name |
| Seen by | How many of the five hit it (one is a note, two or more is a finding) |
| Effect | Did they fail the task, slow down, or recover alone? |
| Fix | The smallest change worth trying |
| Retest | Whether the next round must check it |

When there are no users to hand at all, a heuristic evaluation is the cheaper first pass; my guide to heuristic evaluation for SaaS covers it. If you'd rather hand the whole thing over, the usability testing service page explains how I run it.

## Questions people ask

### How many users do I need for a usability test?

Five per round is a good default for one type of user. With two distinct groups, such as developers and admins, test about three from each, then run another round after fixing.

### Can I run usability testing on a Figma prototype?

Yes. Share the prototype link on a video call and watch. To test errors, build the failure frames too, because a prototype can only show what you've designed.

### Moderated or unmoderated?

Moderated, for a startup's first rounds. You can ask why someone hesitated, and you don't need a paid platform.

### Should I pay participants?

A small thank-you is fair and more people turn up. Customers are often happy with a free month or a gift card; recruited strangers usually expect cash.

## Sources

1. [Why You Only Need to Test with 5 Users](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/), Nielsen Norman Group
2. [Thinking Aloud: The #1 Usability Tool](https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/), Nielsen Norman Group
3. [Heuristic Evaluations: How to Conduct](https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/), Nielsen Norman Group

## Working on this?

Tell me what you're building and where it's stuck: [book a 30-minute call](https://cal.com/utkarsh-design/30min), email [work@utkarshdesign.com](mailto:work@utkarshdesign.com) or [send a brief](https://www.utkarshdesign.com/contact).

## Related

- [Usability testing script template](https://www.utkarshdesign.com/templates/usability-test-script)
- [Usability testing for startups](https://www.utkarshdesign.com/services/usability-testing)
- [Heuristic evaluation for SaaS products](https://www.utkarshdesign.com/guides/heuristic-evaluation-saas)
- [Payment failure UX for timeouts, declines and retries](https://www.utkarshdesign.com/guides/payment-failure-ux)

---

Utkarsh Dhairya Panwar, Founding Product Designer and Design Engineer (IIT Roorkee; Founding Designer at CodeAnt AI, YC W24). Email: work@utkarshdesign.com · Book a call: https://cal.com/utkarsh-design/30min · Hire: https://www.utkarshdesign.com/hire · About: https://www.utkarshdesign.com/llms.txt