Blog

Testing Figma prototypes with people who don't use Figma

July 27, 2026 · 6 min read

Most design work still starts in Figma, and most usability questions arrive long before there's a real build to test. So the practical question is: can you put a Figma prototype in front of people who have never opened Figma, and learn something worth acting on? Yes — and the honest version of the answer is more useful than the marketing one, because it tells you which questions this setup answers well and which ones need a different tool.

The mechanics are unremarkable, which is the point. You paste the prototype's share link into a task, and it runs inside the test the participant is already in. No account, no plugin, no rebuilding your screens in someone else's editor. They read the task, click through the prototype, and tell you how it went.

What an embedded prototype measures well

A prototype embed gives you the outcome of a task and the reasoning behind it — which is most of what an early design review needs:

• Whether they finished — self-reported, which is more honest than it sounds: people know when they gave up.
• Time on task — a rough but real signal, and the one that most often exposes a screen nobody can parse.
• Why, in their own words — an optional free-text field right after the outcome, while the frustration is fresh. This is usually the most valuable field in the whole test.
• Your follow-up questions — ratings, choices, open text, asked immediately after the attempt rather than from memory a day later.

What it does not give you is click-level behaviour: heatmaps, misclicks, the exact screens each person passed through. That limit isn't a product decision, it's the platform: Figma's embed only reports prototype interactions to viewers who are signed in to Figma. Your participants aren't, so no tool embedding a Figma prototype can hand you their click paths. Tools that do show screen-level tracking on Figma designs generally aren't using Figma's player at all — they import the file and rebuild the prototype in their own.

Two ways to run the same study

Once you know that, the choice is simple and it isn't really about Figma. It's about how far along the design is.

• Embedded Figma prototype — for design questions while the design is still cheap to change. Does the flow make sense? Do people know where they are? Would they trust this screen? Fast to set up, nothing to deploy.
• A real build with the tracking snippet — for behavioural questions once something is running: a Figma Make app, Lovable, v0, a staging environment, or your live product. Add one line of script and you get every click, every screen, and automatic success detection when someone reaches the page that means “done”.

A pattern worth stealing: run the prototype version first to find out whether the flow works, then instrument the build to find out where people actually go. See testing vibe-coded prototypes for the snippet side of that.

And if what you need is a single, sharp measurement rather than a walkthrough, exporting one frame and running a first-click test gives you real tap coordinates from every participant — no prototype, no snippet.

Goal-based or free explore

Not every prototype session should be scored. Two shapes cover almost everything:

• Goal-based — there's a thing to accomplish, and the participant reports whether they managed it. Use it when you have a specific flow under test and you want a number you can compare across rounds.
• Free explore — no success or failure at all. The participant looks around and answers your questions. Use it for first impressions, comprehension, and reactions to a concept, where forcing a completed/failed choice would be meaningless.

The mistake is running a goal-based task when you don't actually have a goal. You get a success rate that looks like data and means nothing, because half your participants were never trying to do the thing.

The sharing mistake that quietly ruins studies

This one is worth more than the rest of this article combined. You are signed in to Figma. Your prototype therefore looks perfect when you preview it — and if the file's link access is still restricted, every participant sees a permission wall instead of your design. Nothing errors. Your test just quietly collects nothing, and you find out when you open the results.

Two defences. Set link access to “anyone with the link can view” before you publish, and use a tool that verifies sharing the way an anonymous visitor would rather than the way you see it. In Lens that's a one-click check next to the link — it asks Figma without your session, so a private prototype fails in the builder instead of in front of your participants.

Small settings that change your results

• Turn off Figma's hotspot hints. Those blue flashes reveal every clickable area — which is exactly the thing findability testing is supposed to measure. Leave them on for a demo, never for a study.
• Match the stage to the frames you designed. A phone prototype stretched across a desktop stage sits in a letterbox; a desktop design squeezed into a phone-shaped area is unreadable.
• Hide the prototype's own navigation arrows. Figma's prev/next controls let a participant page through screens without touching your design, which produces a “completed” task that proves nothing.
• Give the prototype the whole screen. A design reviewed in a 400-pixel box gets feedback about the box.

Tell participants what they're loading

An embedded prototype means the participant's browser talks to Figma directly, so Figma sees their IP address and may set cookies — a third party your consent text probably doesn't mention yet. Add a line for it. In Lens the consent gate picks this up automatically whenever a test contains a prototype block, and the prototype only loads once the participant presses start, so nothing third-party happens before they agree. More on the wider picture in GDPR-compliant user research.

Where this fits

Testing a Figma prototype is the cheapest useful research you can run: no build, no deploy, no recruiting people who own a design tool. It answers “does this flow make sense to someone who has never seen it?” properly, and it answers “where exactly did they click?” not at all. Knowing which of those questions you have is most of the skill. For the surrounding method — block types, task wording, keeping tests short — start with unmoderated usability testing.

← All posts