Figma Prototype Usability Testing Without Recruiting

The sprint review is Friday. The Figma prototype for the new onboarding flow is ready. The recruiting step takes a week. That is the whole problem with Figma prototype usability testing on a sprint cadence: by the time you have five qualified participants on calendars, the design has already shipped.

The User Interviews State of User Research 2025 report says 61% of researchers struggle to find enough qualified participants, and another 54% say recruiting on their own is too time-consuming. Those numbers describe the same problem from two angles. Either the panel does not have your user, or the calendar back-and-forth eats the week.

So most teams skip the test. Or they test with whoever is closest, which usually means colleagues who already know the product. Neither answers the question the prototype was built to answer.

Why recruiting is the part that breaks

The flow that gets cited in research-ops decks looks like this: write the test, recruit, schedule, run sessions, synthesize, share. The first four steps consume most of the elapsed time. The actual usability evidence comes from steps five and six, which take hours.

For a B2B prototype, the recruiting problem is worse. The target user is often a specific job title at a specific company size: an operations manager at a 200-person mid-market SaaS company, an IT lead at a regulated firm, a finance director at a venture-backed startup. Public panels do not have many of these. Enterprise platforms can find them, but the contracts are annual and the scheduling is weekly. Neither matches a Tuesday-to-Thursday sprint window.

When the timeline does not allow a real test, what gets sent to engineering is whatever the designer and PM agreed on. The flow is shipped on stakeholder confidence, and the first real users encounter it in production.

What changes when you remove the recruiting step

If you keep the testing step but cut the recruiting step, the workflow looks different. You write a task, configure a persona that matches the target user, and run the prototype against it. The persona walks the flow in a real browser and surfaces where it hesitates, what label it misreads, and where it backs out.

The output is not statistical. It is directional: where the prototype confuses a user with this role and this context. That is the question most pre-handoff usability testing is trying to answer anyway. The recruiting cycle was never producing statistical confidence on a five-participant test, just qualitative evidence with scheduling overhead attached.

This does not replace every kind of research. Studies that depend on lived experience or emotional nuance still warrant moderated sessions with real people. But for the question of whether a prototype’s primary task is navigable, an AI persona returns a usable answer in minutes.

How figma prototype usability testing works in Tessary

Tessary takes a Figma prototype share link and runs configured AI personas against it. The steps:

1. Paste the prototype link. No export. The persona reads from your shared Figma URL.
2. Configure the persona. Role, company size, technical comfort, prior familiarity with the product category, and the goal the user is trying to complete.
3. Write one task. Single objective per run, phrased as user intent: “Complete onboarding and invite a teammate.” Multi-objective tasks blur where the friction is.
4. Run. The persona navigates frame by frame, narrating decisions and flagging hesitation.
5. Read the findings. Where the persona stalled, what copy caused a re-read, which control it expected to find and did not.

For a sprint-scope prototype, the run takes minutes. The findings come back as structured issues with screenshot evidence, not a video you have to scrub through.

Tessary against Maze for Figma prototypes

Maze is the common reference point for Figma testing. It produces task success rates, click maps, and time-to-complete data. For quantitative comparisons across many participants, that data is useful.

What Maze does not produce is reasoning. You see where users clicked, not why they paused before clicking. For B2B flows where the friction is usually about copy clarity or domain assumptions, the click data alone does not tell you what to change.

	Tessary	Maze
Requires recruiting	No	Yes
Figma prototype support	Yes	Yes
Qualitative reasoning	Yes	No
Quantitative click data	No	Yes
Time to first findings	Minutes	Days

For broader context on engineer-led testing of finished flows, the engineer usability testing guide covers what to do once the prototype has shipped to staging.

When this workflow fits

Three situations where running an AI persona against the prototype is the right call:

• The sprint review is in two days and you need directional evidence, not statistical significance.
• Your target user is hard to recruit on short notice: a CFO, a security lead, a clinician, a regulated-industry buyer.
• You want to compare two prototype variants against the same persona, which is hard to do with five different recruited participants.

It does not fit when the test depends on tasks the persona cannot reasonably simulate, like steps that require the user’s own data or external account access. In those cases the persona will surface the friction up to that step, and a moderated session covers the rest.

For how this stacks against the legacy enterprise option, see how Tessary compares to UserTesting.

Try Tessary on your next Figma prototype