How to test your Figma prototype with real users
The fastest way to test a Figma prototype is to set its share link so anyone can view it, give 6–8 target users one realistic task each, and watch where they tap dead spots or stall while thinking aloud. Two short rounds before you write code catch most expensive design mistakes.
There’s a ready-made template for this — skip to itThe method: a 15-minute task-based prototype test
Figma's own help docs stop at "share the prototype link" — for actual testing, they point you at third-party tools. That's because the gap between a clickable prototype and a real test isn't technical. It's three things: participants who match your audience, a task that gives them a reason to click, and someone asking "what did you expect there?" the moment they hesitate. Get those three right and a prototype test is the cheapest research you'll ever run — every fix costs a design tweak instead of a sprint.
One honest limitation up front: a prototype can't fake everything. Participants can't type real data, there are no loading states, and when someone taps a dead area Figma flashes every hotspot in blue — which quietly teaches people to hunt for clickable zones instead of thinking. You work around this with task wording (below), and the signal that survives is exactly what you need: first taps, stalls, and expectation gaps.
Set the share link so testers can actually open it
In the prototype view, hit Share and set access to "Anyone with the link" + "can view." Links restricted to your org or password-protected are the #1 silent failure — the session starts and the participant is staring at a Figma login wall. Open the link in an incognito window yourself before recruiting anyone; if you see the prototype without signing in, they will too.
Pick one flow and patch its dead ends
Test one flow per study — checkout, onboarding, whatever decision you're trying to make. Walk it frame by frame and wire up every screen the task needs, including the "wrong" paths a confused person would try: a back arrow that works, a nav item that goes somewhere. A prototype that's a one-way corridor can't tell you anything, because there's nothing to get wrong.
Write tasks as goals, not directions
"You're looking for a winter jacket under $100 — find one and get to checkout" beats "tap the search icon, then filter by price." The task gives a reason to act; the route is what you're testing. And since participants can't type real data into a prototype, word tasks so typing is never the point — pre-fill forms with plausible values, or let a single tap stand in for "filled this out."
Run 6–8 sessions and let them think aloud
Each participant attempts the task on their own device while narrating. When they stall for more than ~30 seconds, ask what they expected to happen — and let them stay stuck a moment longer than feels polite; the stall is the data. Watch for hotspot-hunting: after a dead tap, Figma flashes every clickable area, so a participant who "succeeds" on the second tap may just have followed the blue flash. Their first tap is the honest answer.
Probe right after, then tag friction to frames
While memory is fresh, dig into each hesitation: what did that button mean, what did you expect after tapping it, what almost made you quit. Pin every observation to a frame — "pricing-screen / skipped the plan toggle / 5 of 8 participants" beats "users found pricing confusing." Count participants per problem, not total complaints.
Fix the top three problems, then re-run the same test
The whole point of testing in Figma is that fixes are cheap — a duplicated frame, not a sprint. Update the prototype, keep the same tasks and screener, and run a second round with fresh participants. When first-tap accuracy and completion climb between rounds, you've earned the confidence to build.
What to measure
- Task completion — did they reach the end frame without help?
- First-tap accuracy — was their very first tap the right one? The most honest prototype metric
- Dead taps — taps on things that aren't wired — each one marks where they expected something to work
- Hesitation points — pauses over ~5 seconds, pinned to a frame
- Backtracks — how often they returned to a previous screen to reorient
- Expectation gaps — "I thought tapping that would…" — mismatches between the design's intent and their mental model
- Comprehension — can they say what the screen is for in their own words?
- 1. Walk me back through what you just did. Where did you slow down, and why?— ask this one first, before you hint at anything specific — their unprompted recall tells you what actually registered
- 2. On the screen where you paused — what did you expect to happen when you tapped that?
- 3. Was there anything you wanted to tap that didn't respond? What did you think it would do?— dead taps are design requests in disguise — this question turns them into words
- 4. Right before you tapped the main button, what did you think would come next? Did it match?
- 5. This is a mockup with placeholder data — was there any point where that got in your way?— separates prototype artifacts from real design problems, so you don't "fix" things that only exist in Figma
- 6. If a friend asked what this app does, what would you tell them right now?
What’s in the ready-to-run study
This is the exact study Sera drafts when you paste your Figma prototype link below. Every piece is editable before launch.
Figma prototype usability test
Moderated · Think-aloud · Live URL or Figma prototype
Screener
4 questions that admit people who match your target audience and reject existing users, industry insiders, and professional testers — cold eyes are the whole point of a prototype test.
Tasks
1 primary goal-based task per flow (attempt it, think aloud) plus 2 conditional follow-ups that trigger only if the participant abandons or taps dead areas repeatedly.
Interview questions
6 post-task questions with probe instructions — the AI moderator digs into the hesitations and dead taps it actually observed on your frames, not generic prompts.
Participants & timing
N = 8 recommended — enough to see every recurring problem twice, small enough to synthesize the same day. Sessions run 10–15 minutes; recruit-to-readout is typically under 24 hours.
Try this template
See your prototype through your users' eyes
Paste a link — the AI reads your flows and drafts your full study in ~2 minutes. You review everything before it runs.
- Works with live URLs and Figma prototypes
- First 7 interviews free
- No credit card required
How it works in Sera
1 · Paste your flow
Drop in the live URL or Figma prototype. Sera reads the flow, drafts the screener, tasks, and questions, and shows you the whole study for review.
2 · Interviews run
Participants attempt the task on their own device while the AI moderator watches, listens, and probes hesitations in real time. You can sit in on any session.
3 · Readout, cited
Friction moments ranked by how many participants hit them, each linked to the exact clip. Share the readout; skeptics can click through to the evidence.
Frequently asked questions
Can you do user testing with a Figma prototype?
Yes — a clickable Figma prototype is enough to test navigation, layout, comprehension, and whether people can complete a flow. What it can't test is anything that depends on real data, real typing, or system speed. For those, test the live product; for everything upstream of code, the prototype is faster and cheaper.
How do I share a Figma prototype for user testing?
Open the prototype (Present view), click Share, and set access to "Anyone with the link" with "can view" permission. Avoid org-restricted or password-protected links — participants hit a login wall. Verify in an incognito window first. The link should open straight to your flow's starting frame, full-screen, with no Figma account required.
How many users do you need to test a prototype?
Six to eight per round. Five finds most problems once; eight sees the serious ones twice, which is what lets you rank them with confidence. Prototypes reward two small rounds over one big one — test 6–8, fix the top three problems in Figma, then re-test with fresh participants.
Can you test a Figma prototype on a mobile device?
Yes. If you designed on mobile frames, test on actual phones — the prototype link opens in a mobile browser, and thumb reach, tap-target size, and keyboard behavior only show up on a real device. A mobile design tested on desktop, with a mouse, will pass tests it should fail.
Do participants need a Figma account to view a prototype?
No — as long as the share link is set to "Anyone with the link, can view," the prototype opens in any browser without a Figma login. If participants are being asked to sign in, the link is restricted to your organization or a password. That's the setting to change; never ask participants to create accounts.
Should you test a prototype before building it?
Almost always. A design problem found in Figma costs a duplicated frame to fix; the same problem found after launch costs a sprint plus the users you already lost. The exceptions are performance, real-data, and trust-with-real-money questions — those need the live product. Test the flow logic before code, the rest after.
Keep reading
Find out why people abandon
your Figma prototype — this week.
Paste your URL, review the study Sera drafts, and watch the first interview yourself.
Your first 7 interviews are on us — no credit card required.