How to Run a Simple Usability Test for an MVP Prototype
Most founders test their MVP the same way they built it — by staring at it themselves and deciding it makes sense. It does, to them. They wrote the copy, they know where every button leads, and they’ve clicked through the flow forty times during development. That familiarity is exactly why founder judgment is the least reliable usability signal available. A simple usability test with five real people, run before or right after launch, will surface more friction in ninety minutes than weeks of internal debate.
This doesn’t require a research team, a lab, or expensive software. It requires a prototype or working build, five participants, a short task list, and a notebook. Here’s how to run one properly.
Why Usability Testing Matters More at MVP Stage
An MVP has one job: prove that people can use it well enough to get value from it. If a new user can’t figure out how to complete the core action in the first few minutes, nothing else about the product matters yet — not the roadmap, not the pricing model, not the long-term vision. Usability problems at this stage are cheap to fix because the product is still small. A confusing signup flow or a buried primary action is a five-minute fix in a prototype and a much bigger one once the codebase has grown around it.
This is also the stage where teams tend to skip testing entirely, assuming it’s something you do later with “real” users at scale. In practice, the earlier you test, the less expensive every fix becomes. If you haven’t already worked through what the interface should look like structurally, it’s worth reading how to design an MVP before coding starts, since a usability test is only as useful as the flow you’re testing.
What You Need Before You Start
You don’t need a finished product. A clickable prototype in Figma, a staging build, or even a rough working version is enough, as long as the core flow is navigable. Before you recruit anyone, get three things ready:
- A single core task the product exists to solve — not five tasks, one. If it’s a booking app, the task is “book an appointment.” If it’s a budgeting tool, it’s “log your first expense.”
- A short script with 3-5 realistic tasks that lead the user through that core flow without telling them where to click.
- A way to observe, whether that’s sitting next to someone with a laptop or screen-sharing on a call.
If you haven’t settled on which screens the MVP actually needs, that’s worth resolving first — testing an interface that still has unresolved scope creates noise you can’t distinguish from real usability problems. The piece on how to decide which MVP screens can wait until later is a useful gut-check before you lock the script.
Recruiting the Right Participants
You need five people, not fifty. Research from Nielsen Norman Group has shown for years that testing with five users uncovers the large majority of usability problems in an interface — after that, participants start repeating the same issues and the marginal value drops fast. Five well-chosen sessions beat twenty rushed ones.
“Well-chosen” means people who resemble your actual target user, not your co-founder’s spouse or the most tech-savvy person in your Slack. If you’re building for small business owners, test with small business owners. If you don’t have access to your exact audience yet, get as close as you can — someone unfamiliar with your product who fits the general profile is far more useful than someone who already knows what you’re building and why.
Writing Tasks That Actually Reveal Problems
The most common mistake in a first usability test is writing tasks that lead the witness to the answer. “Click the blue button to create an account” isn’t a task, it’s a set of instructions. A real task describes a goal and lets the person find their own way there: “You want to start tracking your expenses. Set that up now.”
Keep each task tied to a real goal, not a feature tour. Avoid asking “What do you think of this screen?” — vague opinion questions produce vague opinion answers. Instead, watch what people actually do when given a goal, and ask questions afterward. If your product touches onboarding, forms, or account creation, it’s worth comparing your task list against a UX checklist for MVP before the session, since those are the areas where MVPs tend to accumulate friction that never gets tested. The same checklist logic applies more broadly in ux checklist for mvp what to get right before launch, which covers the structural basics worth confirming before you start collecting sessions.
Running the Session
Sit next to the participant, or join a screen-share call, and say almost nothing. This is the hardest part for most founders — the instinct to jump in and explain is strong, especially when you can see someone about to make the “wrong” choice. Resist it. The moment you explain, you’ve lost the data.
A simple structure works well:
- Explain that you’re testing the product, not them — there are no wrong answers.
- Ask them to think out loud as they go.
- Give one task at a time and stay quiet while they attempt it.
- Note where they hesitate, misclick, or ask “wait, what does this do?”
- Ask a few open questions at the end, after tasks are done.
| Do | Don’t |
|---|---|
| Ask “What would you do next?” | Say “Click the button in the top right” |
| Let silence sit while they think | Fill silence by explaining the feature |
| Note hesitation and backtracking | Only note what they say out loud |
| Test one core flow deeply | Try to cover the whole product in one session |
| Recruit people outside your team | Test with people who already know the product |
Sessions should run 20-30 minutes. Longer than that and fatigue starts affecting the data; shorter and you probably haven’t given people enough tasks to expose real friction.
Turning Observations Into Fixes
After five sessions, patterns emerge fast. If three out of five people hesitate at the same screen, that’s not a coincidence — it’s a design problem. Group your notes by task rather than by participant, and look for repeated hesitation points, not just repeated complaints. People are often bad at articulating what confused them but very consistent in where they get stuck.
Prioritize fixes by how directly they block the core flow. A confusing label on a settings page you can defer; a confusing primary call-to-action on the main screen cannot wait. If you’re deciding how much of this to fix before launch versus after, the guidance in how to prioritize ux work when mvp budget is limited is directly relevant — usability testing tells you what’s broken, but budget constraints still decide what gets fixed first.
When to Test Again
One round isn’t the end of the process. Run a lighter version of the same test after you’ve shipped the fixes, ideally with a fresh set of five people so you’re not just confirming that the same participants remember the changes. Many teams also build a short usability pass into every major release rather than treating it as a one-time pre-launch checkbox — it’s far cheaper to catch confusion in a 20-minute session than in a support inbox after launch.
Not sure your MVP prototype is ready to test?
We help founders design and validate MVP flows before a single line of code gets written, so usability testing surfaces real signal instead of avoidable confusion.
Book a free consultation with MVPHUBFrequently Asked Questions
How many people do I need for a usability test?
Five participants is enough for most MVP-stage tests. Research from Nielsen Norman Group shows five users typically surface the large majority of usability problems in an interface, with diminishing returns after that. Focus your effort on picking the right five rather than recruiting more.
Can I test a prototype instead of the finished product?
Yes, a clickable prototype works well as long as the core flow is navigable. Testing early, before code is written, is actually cheaper since fixes at the prototype stage take minutes rather than requiring code changes.
How long should each usability testing session take?
Aim for 20-30 minutes per session. That's enough time to walk through 3-5 realistic tasks without fatigue setting in and skewing the results.
What's the biggest mistake founders make when running these tests?
Writing tasks that tell users where to click instead of describing a goal, and jumping in to explain features when a participant hesitates. Both remove the exact friction signal you're trying to observe.
Should I test with people who already know my product?
No. Test with people who resemble your target user but haven't seen the product before. Familiarity with your team or your roadmap makes someone a poor stand-in for a first-time user.
What should I do with the results after testing?
Group observations by task, not by participant, and look for repeated hesitation points across sessions. Prioritize fixes that block the core flow first, then run a lighter follow-up test after changes ship.
