By Mehdi HassanHow does usability testing for startups work on a small budget?
Usability testing for startups works by watching a small number of real people try to complete realistic tasks with your product or prototype, then fixing what trips them up. On a small budget, that means five moderated video sessions in one afternoon, a short task script and a simple scoring sheet. No lab, no panel and no paid platform.
It answers a different question from interviews. Interviews tell you what problems people have. Usability testing tells you whether they can use what you built to solve them. Both belong in a lean research routine, which our hub on user research for startups lays out as a two-week cycle.
Five sessions per round is a long-standing practice in the field because the most serious problems tend to show up again and again early on. Once you've watched three different people get stuck on the same step, a fourth viewing teaches you little. Fix it, then test again.
What do you need to prepare before the afternoon?
Before the afternoon you need five booked participants, a working prototype or product, three to five task scenarios, a moderator guide and a shared notes sheet. Preparing these takes a day or two. The afternoon itself is the easy part if the preparation is done.
- Participants. Five people who match your target users, plus one backup. Screen for the right role and recent experience. Our guide to recruiting research participants covers sourcing.
- Something to test. A live product, a staging build or a clickable Figma prototype. Make sure every path in your tasks works.
- Tasks. Three to five realistic scenarios covering your most important flow.
- A moderator guide. Your intro, the tasks and a few neutral prompts, on one page.
- A notes sheet. One row per observation, with columns for participant, task, what happened and severity.
- Recording. A video call with screen sharing and permission to record.
Our list of user research tools for startups covers free options for each of these.
How do you write usability test tasks that don't give away the answer?
Write tasks as realistic scenarios with a goal and a reason, using the user's words rather than the words on your interface. A task that says 'click Settings and then Team' tests reading. A task that says 'a new colleague starts Monday, get them access' tests whether your product makes sense.
Weak task | Problem | Better scenario |
|---|---|---|
Click 'Create invoice' | Names the button | A client just approved your quote. Bill them for the work. |
Go to Settings and add a teammate | Gives the path | A new colleague starts Monday. Make sure they can log in and see your projects. |
Find the export feature | Uses product language | Your accountant needs last quarter's numbers in a spreadsheet. Get them that file. |
Try the dashboard | No goal, so no success measure | Your manager asks how many orders came in last week. Find out. |
Change your plan | Too short, no context | Your team doubled. Make sure the account covers everyone. |
Decide in advance what counts as success for each task, such as 'invoice sent to the right client with the right amount'. Without a clear end point, you'll argue later about whether someone succeeded.
What does the afternoon plan look like?
The afternoon plan is five 30-minute sessions with short breaks between them and a debrief at the end. Each session follows the same structure, so results are comparable. One person moderates and, ideally, one or two teammates watch and take notes.
1:00 pm — Setup and dry run
Check the prototype, the recording and screen sharing. Run through the tasks once yourself to catch broken links.
1:30 pm — Session 1
Intro (3 minutes), warm-up question (2 minutes), tasks (20 minutes), wrap-up questions (5 minutes).
2:00 pm — Ten-minute break
Note the top three observations from the session while they're fresh. Fix any broken prototype links, but don't redesign mid-round.
2:10 pm to 4:40 pm — Sessions 2 to 5
Same structure every time, with a short break after each to write down observations.
4:45 pm — Debrief
With everyone who watched, list every issue on a shared board, merge duplicates and score severity together.
5:15 pm — Agree what to fix
Pick the blockers and major issues to fix before the next round, and assign owners.
A moderator script for each session
Intro: 'Thanks for joining. We're testing the product, not you, so there are no wrong answers. If something is confusing, that's exactly what we need to know. Please think out loud as you go: what you're looking at, what you expect, what you're unsure about. I may not answer questions during tasks, because I want to see what you'd do on your own. Is it OK to record your screen and voice?'
Warm-up: 'How do you handle [task area] today?'
For each task: read the scenario aloud, paste it into the chat and say 'Let me know when you think you're done.'
Neutral prompts when they go quiet: 'What are you thinking?', 'What did you expect to happen?', 'What are you looking for?'
Wrap-up: 'What was the most confusing part? If you could change one thing, what would it be? Anything else you'd like to tell us?'
How should you moderate a usability test?
Moderate by staying neutral, staying quiet and letting people struggle. Your job is to observe, not to help. Every time you rescue someone, you lose the evidence you came for and replace it with a version of the product that only works when a founder is on the call.
- Answer questions with questions. If they ask 'should I click this?', reply 'what do you think it would do?'
- Don't explain the design. If they misunderstand something, that's the finding. Write it down.
- Watch, don't just listen. People often say a task was easy after visibly struggling. Trust what they did.
- Set a time limit. If someone is stuck for a few minutes, note it as a failure and move to the next task, so you still learn from the rest.
- Keep your face and voice neutral. Sighs and 'great' after a success both steer behavior.
How do you score usability issues by severity?
Score each issue on a simple scale that combines how badly it hurt the user and how many people hit it. A four-level scale is enough. Severity turns a long list of observations into a ranked to-do list, and stops the team from fixing the most visible issue instead of the most damaging one.
Severity | Definition | Example | What to do |
|---|---|---|---|
4 — Blocker | User couldn't complete the task | Nobody found how to invite a teammate | Fix before the next round |
3 — Major | Completed, but with real struggle or an error | Sent the invoice to the wrong client first | Fix soon |
2 — Minor | Brief hesitation, recovered quickly | Paused over an unclear label | Batch with other fixes |
1 — Cosmetic | Noticed but didn't slow them down | Commented on an icon's style | Fix when convenient |
Add a frequency count next to each issue, such as 3 of 5 participants. A severity-3 issue that hit four people usually outranks a severity-4 issue that hit one. Our guide to research synthesis covers how to group and rank findings in more depth.
What should you do after the usability test?
After the test, fix the blockers and major issues, then run another short round to confirm the fixes worked. A usability test is only worth the afternoon if something changes. Write a one-page summary listing each issue, its severity, its frequency and the agreed fix.
Usability testing sits alongside other quality checks. A UX audit compared with usability testing explains when an expert review is the faster first step. Before launch, functional checks matter too, and our guide to website QA testing covers them. Once you have enough traffic, A/B testing tools can measure which version of a fixed flow performs better.
Track the result in your product metrics as well. If a fix targeted onboarding, check task success and activation afterwards, using the events in our guide to UX metrics for SaaS. If you'd rather have a team turn findings into new designs, our brand & design sprint is $3,000, fixed, with 10 website and product explorations in Figma.
