User testing on a five-person startup budget

Founders at small startups often assume user testing requires a dedicated researcher, a proper lab setup, and a budget they don't have, so they skip it entirely and design by instinct instead. Real, useful user testing is achievable with five participants, a laptop, and an afternoon, and the insight-per-hour is usually higher than most other early-stage activities.

Usability research going back decades consistently shows that testing with five users surfaces the majority of a design's most significant usability problems, with sharply diminishing returns from additional participants at the early stage. You don't need statistical significance to catch a confusing checkout flow, you need a handful of real people trying to use it while you watch.

Existing customers or waitlist signups, friends-of-friends who match your target user profile but aren't personally close to the product, and small paid participant pools (typically a modest incentive per session) all work for early-stage testing. The key requirement is that participants aren't so close to the team that they're inclined to be polite rather than honest.

Give participants a specific task ("sign up and complete your first order") rather than a general tour, and resist the urge to help when they get stuck, since watching where and how someone struggles unprompted is the actual data you're there to collect. The most useful moment in a testing session is often the one where you have to bite your tongue rather than jump in.

A simple screen recording with audio (most video call tools handle this natively) captures everything you need. Review sessions looking specifically for moments of hesitation, wrong clicks, and verbalized confusion ("wait, where do I..."), and note the exact screen and moment each issue occurred, rather than relying on memory afterward.

If two or more of your five participants hit the same specific issue, that's usually worth fixing before launch. A single participant's individual confusion is a data point worth noting but not necessarily acting on alone, since any one person can have an unusual mental model that doesn't generalize. Pattern across participants, not any single loud opinion, is what should actually drive design changes.

Founders sometimes assume proper user testing requires an in-person session in the same room, which adds real logistical cost and often becomes the reason testing gets postponed indefinitely. In practice, a remote session over a video call, with screen sharing and a recording, surfaces the large majority of the same usability issues an in-person session would, and it's dramatically easier to schedule, especially with participants outside your immediate city. We default to remote sessions for early-stage testing specifically because the format that actually happens on schedule beats the theoretically slightly-more-thorough format that keeps getting pushed back.

First-time moderators consistently make the same mistake: jumping in to explain, reassure, or redirect the moment a participant looks confused, which erases exactly the signal the session exists to capture. We coach new moderators to sit with the silence, let a participant struggle for a genuinely uncomfortable stretch of time before offering any help, and to ask open, non-leading follow-up questions ("what did you expect to happen there?") rather than questions that hint at the right answer. It's a harder discipline than it sounds, especially when the interface being tested is your own team's work and every instinct says to jump in and defend it.

Small-sample qualitative testing is excellent at surfacing usability friction but poor at answering quantitative questions, whether a specific design actually converts better than another, or how a change performs across a genuinely broad, diverse user base. For those questions, five-person testing is the wrong tool, and we pair it with actual analytics and, once there's enough traffic, structured A/B testing rather than trying to stretch qualitative sessions to answer questions they're not suited for. The two methods complement each other well: qualitative testing tells you why something's confusing, quantitative testing at scale tells you how much it actually matters to the bottom line.

One of the biggest budget-saving realizations for founders new to user testing is that participants don't need a fully built, functioning product to give useful feedback. A clickable prototype built in a design tool, with static screens wired together to simulate the core flow, surfaces the majority of the same navigation and comprehension issues a working build would, at a fraction of the time cost and weeks earlier in the process, when changes are still cheap to make. We push founders toward testing a prototype well before any code gets written specifically because problems caught at the prototype stage cost minutes to fix, while the same problem caught after a build is finished can mean reworking already-shipped code.

A surprisingly common mistake in early-stage user testing is walking into a session with only a general sense of what to learn, which leads to loosely structured sessions that produce interesting but hard-to-compare notes across participants. We write a short, specific list of the actual questions the session needs to answer, does the user understand what the product does within the first ten seconds, can they complete the core task without help, before the first session, and use the same list across all five participants, which makes it far easier to spot a genuine pattern across sessions rather than five disconnected anecdotes.

We spend five minutes writing down first impressions immediately after each session ends, before starting the next participant, since details that feel obvious and memorable right after a session fade surprisingly fast once a second and third session start layering new impressions on top. This small habit, done consistently, produces a far more reliable set of notes to review afterward than trying to reconstruct all five sessions' worth of detail from memory at the end of a long afternoon of back-to-back testing.