Prototype Testing SOP

A prototype testing SOP puts a clickable fake of your product in front of real customers and watches where they get stuck, before a single line of production code exists. Each round takes about a week, and two or three rounds take most products from confusing to clear. Every problem you find in a Figma file costs minutes to fix. The same problem found after launch costs weeks of rework and a pile of lost signups. That is the trade this SOP makes.

What is the prototype testing SOP and when should you use it?

Prototype testing is a form of usability testing: target users try to complete realistic tasks on a prototype while thinking aloud, and you measure what they finish, how hard it felt and where they fail. It rests on three well-known pieces of research. Jakob Nielsen and Tom Landauer showed that five users find about 85% of usability problems in a design, which is why this SOP runs small rounds of five and repeats them. John Brooke's System Usability Scale (SUS) gives a ten-question score from 0 to 100, and Jeff Sauro of MeasuringU puts the average score at 68. Sauro's benchmark data also puts the average task completion rate at about 78%.

Use this SOP:

• After a concept test picked a winner, to see whether people can use it.
• When your product has a flow customers must complete alone: signup, booking, ordering, setting something up.
• Before you hire developers or start a no-code build, so they build a tested flow.

Scope check: this SOP tests whether people can use the solution and still want it after trying. To check whether the technology works, use the proof of concept SOP. To deliver the result by hand behind a real front end, use Wizard of Oz testing or concierge testing.

What do you need before you start?

• A chosen solution with a storyboard or concept board.
• A list of your riskiest assumptions about how customers will use it.
• Figma (free plan works) or a similar tool for a clickable prototype.
• 5 participants per round from your target segment, plus 2 spares, and a thank-you for each.
• A video call tool with recording, or an unmoderated tool such as Maze or Lyssna.
• An issue log in a spreadsheet (template below).

How do you run it, step by step?

1. Pick 3 to 5 tasks tied to risky assumptions

Write each task as a goal in the customer's words: "You have a new client. Get your first invoice to them." Choose tasks where failure would kill the product: the first-time setup, the main action, the moment money changes hands. Skip settings pages and edge cases for now.

2. Build only the paths those tasks need

Make a clickable Figma prototype with realistic content: real names, prices and text in your customer's language. Placeholder text makes people test your layout instead of your product. Mid-fidelity (grey boxes, real words) is enough for round one.

3. Write the session script

Plan 30 to 45 minutes: a short intro, a request to think aloud, the tasks as short scenarios, one question after each task ("How easy or hard was that?"), the SUS questionnaire and a closing question that asks for commitment, such as joining a pilot.

4. Run five moderated sessions

Share the prototype link, ask the participant to share their screen and stay quiet while they work. When they ask "Should I click here?", answer "What would you expect to happen?" Record with permission and take notes on every hesitation, wrong click and comment.

5. Log and rate every issue

After each session, log each problem with the task, what happened and how many participants hit it. Rate it on Nielsen's severity scale from 0 (not a problem) to 4 (usability catastrophe). Issues rated 3 or 4 must be fixed before the next round.

6. Fix and retest with five new people

Change the prototype to fix all severity 3 and 4 issues, then run the same tasks with five new participants. Never reuse participants: they remember the fixes. Two or three rounds are normal.

7. Check desire as well as ease

Close every session with a real ask: "We are running a pilot next month. Would you like to join?" Count yes answers and follow-ups. A product that is easy to use and still gets no takers needs a different fix than better buttons.

Template you can copy

SESSION SCRIPT (30–45 min)
Intro (3 min)
"Thanks for helping. We are testing the design, not you. Please think
aloud: say what you're looking at, what you expect, what confuses you.
OK to record?"

Tasks (20–25 min, one at a time)
Task 1: "[Goal in customer words, no button names]"
  After: "How easy or hard was that, from 1 (very hard) to 7 (very easy)?"
Task 2: ...
Task 3: ...

SUS questionnaire (5 min): Brooke's 10 statements, 1–5 agreement

Close (5 min)
"What would stop you from using this?"
"We're starting a pilot next month. Would you like to join?"

ISSUE LOG COLUMNS
Round | Task | Issue | Participants affected (n/5) | Severity 0–4 |
Quote | Fix | Fixed Y/N

ROUND SUMMARY
Round | Completion % per task | Avg ease 1–7 | SUS avg | Severe issues | Pilot yes (n/5)

Worked example: a reorder tool for independent cafés

This is an illustrative case. A founder builds a Figma prototype that lets café owners reorder milk, beans and cups from several suppliers in one place. She tests four tasks: add a supplier, set a weekly order, change an order on the day, and approve a price change.

Round one with 5 café owners: overall task completion is 60%. Nobody finds where to add a supplier, because the button sits under "Settings". Four of five expect the weekly order to repeat automatically and are surprised it doesn't. The SUS average is 58, and she logs three severity 3 issues.

She moves suppliers to the home screen, makes weekly orders repeat by default and rewrites the price change screen in plain words. Round two with 5 new owners: completion rises to 85%, SUS averages 74, no severe issues remain, and 3 of 5 ask to join the pilot. She sends the tested flow to a developer and starts a concierge test with the three pilot cafés while the build runs.

What should you measure, and when do you stop?

Stop when a round passes all four signals, or after three rounds. If completion is high and commitment stays at zero, the problem lies in the offer instead of the design: go back to the concept test results.

Which mistakes should you avoid?

• Leading the participant. "Click the blue button to add a supplier" tests whether they can read. Describe goals.
• Testing with your team or friends. They know what you meant. Recruit strangers from the segment.
• Building the whole product in Figma. Prototype only the risky tasks; extra screens cost time and teach nothing.
• Fixing everything at once. Fix severity 3 and 4 first, then retest. Small polish can wait.
• Counting ease as validation. An easy product nobody wants is still a failure. Always ask for a commitment.

How can AI speed this up?

AI design tools and Figma plugins can turn a storyboard into a first clickable draft in an hour, and an AI assistant can write task scenarios, fill screens with realistic content and score SUS from a spreadsheet. After sessions, transcription plus AI summaries list every hesitation by task. Watch the recordings yourself for the severe issues, because a summary misses the long pause before someone gives up. The F/MS AI for startups module covers these tools, and if you want an AI co-founder for building your first product, that site walks through the build after testing.

Where does this SOP fit in your validation plan?

Prototype testing comes after a solution sketching workshop and a concept test. Run it alongside Wizard of Oz testing when the hard part happens behind the screens. Once the flow passes, use feature prioritization to decide what goes into the first build, and check feasibility with a proof of concept. See the full stage on the Solution Validation page.

FAQ

How many users do I need for prototype testing?

Five per round, per customer segment. Nielsen and Landauer's research shows five users find about 85% of usability problems, so run several small rounds instead of one large one.

What is a good SUS score?

Above 68, which is the average from Jeff Sauro's data. Scores above 80 put a design among the best rated.

Should prototype tests be moderated or unmoderated?

Moderated for the first round, so you can see and ask about confusion. Unmoderated tools such as Maze work well for later rounds when you mainly need completion numbers.

What fidelity should my prototype be?

Mid-fidelity with real words is enough for most first rounds. Raise fidelity only when visual design is part of what you are testing, such as trust on a payment screen.