How to prepare a Figma prototype before testing it: a checklist
Link sharing, a flow starting point, readable frame names, connected screens and no accidental dead ends: five Figma checks that make test results readable.
By Thomas Cescousse, product designer and maker of DASHUND
Before you share a Figma prototype, check five things: the file is shared by link with view access, the flow has a clear starting point, frames have readable names, every screen that matters is connected by an interaction, and no screen is an accidental dead end. Skip them and testers get a blank screen, paths stop where you planned nothing, and your numbers end up describing your file instead of people's behavior.
I run through this list before every test, because any one of these can quietly ruin a batch of sessions. Here's the method, in the order I follow it.
1. Is the file shared by link?
Your testers see the prototype through Figma's player. So the file has to be open to anyone with the link. In Figma: Share, then "Anyone with the link" and "can view".
The catch: this setting applies to the file, not just the prototype. Making only the prototype public isn't enough. Figma then asks people to log in, or shows a blank screen to someone who's already logged in. The tester closes the tab, and you never find out they came.
A Figma password still works, but your testers will see Figma's password screen before the prototype. Keep that for truly confidential tests.
With DASHUND, as long as no session has come in, sharing is checked after you publish: if Figma asks for a login, the dashboard tells you and explains which setting to change.
2. Does the flow have a starting point?
In Prototype mode, every flow begins with a starting screen. It's the first screen everyone sees, and it's also where people land again after reloading the page. Pick it like a real entry point: a home screen, a product page someone reaches from an ad, the first onboarding screen.
A few tips:
- One flow, one question. If your file holds both onboarding and checkout, make two flows and test them separately. A
flow that tries to cover everything dilutes the paths.
- No utility screen up front. A "table of contents" screen that links to every page is handy in a design review, but it
becomes the first screen of every session and skews the first click.
- Stay under a hundred screens. Beyond that, the import can fail because of Figma's limits. A short flow, focused on what
you want to learn, works better.
The DASHUND plugin lists the flows in your file: without a starting point, there's nothing to publish.
3. Do your frames have readable names?
"Frame 1427" and "Frame 1428" mean nothing in a path diagram. Rename your frames after what they show: "Cart", "Checkout", "Confirmation".
Names matter twice:
- When you read results. The Flow, the Sitemap and the heatmaps display these names. Clear names save you time and make
your screenshots ready to show a team.
- When you compare two versions. When you publish a version 2, Compare matches the screens of both versions by their
Figma identity, then by their original Figma name. So keep the same frame names from one version to the next. Otherwise, you fix the matching by hand.
DASHUND also lets you rename a screen for display, without touching the file. But the simplest fix is naming things well in Figma, at the source.
4. Is every screen that matters connected?
DASHUND keeps the starting screen and every screen and overlay reachable from it through the prototype's interactions. A screen that isn't connected to anything doesn't get imported.
To check, click through the flow in Figma's presentation mode like an impatient tester:
- Start from the starting screen.
- Follow the main path to the end.
- Go back and try every visible button, even minor ones.
- Write down any screen you can't reach: an interaction is missing.
The Sitemap tab in DASHUND then shows every imported screen, with the links you planned in Figma. A dotted arrow is a link nobody took; a gray arrow is a path people took that you didn't plan, like going back.
5. Are there dead ends?
A dead end is a screen with no outgoing interaction. Some are on purpose: the order confirmation, the "Account created" screen. Others are oversights: a "Terms" page you designed but never linked back from, a product page with no way back to the list.
They matter for two reasons.
They stop paths. A stuck tester closes the tab, or uses Figma's bar to go back. Navigation through Figma's bar isn't a design choice: DASHUND records it, but leaves it out of the Flow and target paths. Your diagram will show an exit where there was really a wall.
They become default goals. When you publish, DASHUND picks screens with no outgoing interaction as goal screens, since they're the likely ends of a path. A forgotten dead end can therefore count as a success. A banner asks you to check those goals in the prototype's Settings: do it every time you publish.
| Screen with no way out | On purpose? | What to do |
|---|---|---|
| Order confirmation | Yes | Keep it as a goal screen |
| Help page never linked back | No | Add a way back in Figma, or remove it from the goals |
| End screen with a "Back" button | Yes, but it has an exit | Add it as a goal by hand |
| Single-page prototype | No end | Pick the goal by hand, or go without |
Two last settings
- The device. The frame chosen in the Figma prototype settings (phone, tablet, desktop) is what your testers will see.
Screens taller than the device scroll normally.
- The version. When you publish, the plugin creates a named version in the file's version history. That's what your
testers see, even if you keep editing the design. No layer is touched.
What next?
Once these five checks pass, publish with the plugin, then open your DASHUND link yourself once to see what testers will see. That session counts like a tester's: delete it afterward from the Sessions tab. The preview in Settings never collects anything.
The full walkthrough is in the guide to testing a Figma prototype, and each setting is covered in the resources.
FAQ
Why do my testers see a blank screen?
Most of the time, the Figma file isn't shared with "Anyone with the link" and "can view". Making only the prototype public isn't enough: the setting applies to the file.
Do I need to rename every frame?
Every frame in the flow you're testing, yes. Their names show up in the Flow, the Sitemap and the heatmaps, and they're used to match screens when you compare two versions.
Does an unconnected screen get imported?
No. Only the starting screen and the screens and overlays reachable through the prototype's interactions are kept.
Can I change the design after publishing?
Yes, in Figma. Your testers keep seeing the published version. To test the new version, publish it as a new prototype and compare the two.