Prototype testing: how to test with 5 to 8 users, and what you learn
Gideon Awolesi ·
Before you spend months and a lot of money on a build, you can find out if a flow works by putting a prototype in front of the people who'll use it. A lot of teams skip this because it sounds slow and expensive. It doesn't have to be. With 5 to 8 people from your user group and a prototype of the one flow you're least sure about, you'll usually see the biggest problems within the first few sessions. Here's how we run it.
01Why 5 to 8 people is enough
In 2000, Jakob Nielsen published "Why You Only Need to Test with 5 Users", arguing that a small group finds most of the usability problems in a design, and that it's better to run several small rounds than one big one. That still holds for prototype testing, where the goal is to find problems and fix them, not to prove a number.
We test with 5 to 8 people, so we still get enough sessions if one or two people don't turn up, or turn out not to match the user group. If your product has two very different user groups, like admins and the people they manage, test with a small group from each.
02A Figma prototype or a coded one?
A Figma prototype is enough when you're testing layout, navigation, and wording, and the content can be the same for everyone. It's quick to change between sessions.
You need a coded prototype when the flow depends on real data or on something the person types, like a search, a form with validation, or an AI feature. A clickable Figma file can't show what happens when someone pastes in their own messy data, and with AI features, that's where a lot of the problems are. That's why the prototypes in our Evidence Sprint are working apps on a live URL, with seeded or real data, and live AI calls where the flow needs them.
03Write tasks, not instructions
Give people a goal and the context they'd have in real life, and then let them work out how to do it. "You've just been invoiced twice for the same order. Sort it out." tells you far more than "Click Billing, then click Disputes."
- Pick the three to five tasks that matter most for the flow you're testing.
- Write each one as a goal, in the words your users would use, without naming any buttons.
- Decide in advance what counts as success, so you're not judging it on the day.
- Run one pilot session with a colleague to catch tasks that don't make sense.
04Running the sessions
Ask people to think out loud as they go, and resist helping them. When someone gets stuck, ask what they expected to happen instead of pointing to the answer. Record the screen and the audio, with their consent, so the rest of your team can watch the moments that matter.
It's important that the person running the session isn't the person who designed the flow. Designers tend to defend their decisions without meaning to, and participants pick up on it.
05What to do with what you find
After the sessions, list every problem with how many people ran into it and how badly it stopped them. Fix the ones that stopped people from finishing a task first. Then decide: is the flow ready to build, does it need another round, or should you stop?
That decision is the point of the whole exercise. In our Evidence Sprint, you get a written test report and either a fixed price for the full build or a recommendation to stop, in three to four weeks, from €9,500.