Usability testing has an undeserved reputation for being expensive and slow. When people hear "user research," they picture a one-way mirror, a moderator with a clipboard, and a two-week timeline. That version of testing exists and has its uses — but it's not the version most product teams need most of the time.
The version most teams need is simpler: five users, a Figma prototype or a staging environment, a video call, and 45 minutes per session. Done well, this surfaces the majority of serious usability problems before they ship. Done consistently — even once per sprint — it produces a compounding improvement in product quality that no amount of post-launch analytics can replicate.
Here's how to run it from scratch.
Five participants is the right number for most usability tests. Jakob Nielsen's research established that five users uncover around 85% of usability problems, with diminishing returns after that. Running three sessions of five users at different points in the design process is more valuable than one session with fifteen.
The criteria for recruiting are more important than the number. A usability test with five people who closely match your target user will reveal real problems. A test with fifteen people who don't match will generate noise. Define two or three screening criteria — role, context of use, technical comfort level — and hold to them.
The fastest recruitment route for most teams is emailing existing users who have given contact permission. Offer a modest incentive — a £20 gift card is sufficient for a 45-minute session. Aim to schedule sessions within the same week; the longer the gap between recruiting and testing, the higher the no-show rate.
The most common scripting mistake is writing tasks as instructions: "Click on Settings, then navigate to Notifications, and change your preference to..." This tells the user what to do, which means you're testing whether they can follow directions, not whether the interface is intuitive.
Write tasks as scenarios instead: "Imagine you've been getting too many notifications and you want to only receive alerts when someone mentions you directly. Show me what you'd do." This gives the user a realistic goal and lets you observe how they actually navigate — including where they get confused.
The hardest part of moderating a usability test is resisting the urge to help. When a user is confused, every instinct says to jump in and show them where to click. But the confusion is the data. A user who is struggling is telling you something is wrong with the interface — and the moment you intervene, you lose the signal.
Ask users to think aloud throughout the session: "As you go, just tell me what you're looking at and what you're thinking." This produces a continuous stream of data about their mental model. Note not just errors but hesitations — a user who pauses for three seconds before clicking the right button has still revealed a design problem, even if they eventually succeeded.
The synthesis step is where most of the value is created — and where most teams cut corners. Raw notes from five sessions are not findings. They become findings when you debrief as a team, group observations by theme, and assign severity ratings.
Do the debrief on the same day as the sessions, while the observations are fresh. Group issues into three buckets: critical (users couldn't complete the task), moderate (users completed the task but with significant difficulty or error), and minor (friction that didn't prevent completion). Critical issues need to be fixed before launch. Moderate issues should be prioritised in the next sprint. Minor issues go into the backlog.
Write up findings in a single page: the top three critical issues, with evidence from at least two participants each, and a proposed design change for each. Anything that needs more space than that belongs in a separate document.