How to Test a Figma Prototype Without Tasks or a Script (and Why)
Without instructions, people use your prototype like a real product. The method: define success, one link per audience, then read paths and drop-offs.
By Thomas Cescousse, product designer and maker of DASHUND
Testing a Figma prototype without tasks means sharing a link and letting people use it like a real product: no instructions, no script, no questionnaire. What you get is behavior that's closer to real life, because testers find their own way instead of following yours. The method comes down to four steps: decide what a successful session is, make the prototype stand on its own, share it through separate links, then read the paths and the drop-offs.
Why drop the tasks?
A task is a sentence like "Buy a pair of sneakers in size 9." It has one clear upside: it focuses the test on what you want to check. It also has a cost that's easier to miss.
- It gives away the destination. The person now knows a purchase is possible, that there are sizes, and that they're
expected to finish. Your prototype no longer has to make any of that clear.
- It often gives away the words. If the task says "cart" and the button says "cart," you're testing reading, not
navigation.
- It changes motivation. Someone on a mission keeps going where a real visitor would have given up. And drop-offs are
exactly what you're looking for.
The contrast can be striking. With a task, almost everyone finishes, and you walk away reassured. Without one, you sometimes find out that the home screen doesn't say clearly enough what the product does, or that part of the flow is never seen at all.
Dropping tasks doesn't mean testing at random. The question just changes: not "can they do X?" but "what do they do when nobody tells them what to do?"
What you can measure, and what you can't
| With tasks | Without tasks |
|---|---|
| Success on a specific instruction | Share of sessions that reach the goal on their own |
| Time to complete the task | Time spent on each screen, and where people linger |
| Answers to questions | No questions: only behavior |
| A few recruited participants | As many people as your link reaches |
| A guided path | The real paths, including ones you didn't plan for |
The limit is clear: without tasks or questions, you see what and where, not why. If lots of sessions stop on the shipping screen, you know where to look; you may need an interview to understand the reason. The two approaches work well together. Task-based testing tools exist to check a specific instruction, and they're the right choice when your question is "can people find this feature?"
Step 1: Define what a successful session is
Even without instructions, you still need to know what counts as success. Decide before you share anything:
- One goal screen: the order confirmation, the "Account created" screen.
- Several possible endings: "Order paid" or "Appointment booked," each one counts as success.
- Checkpoints: the four screens of an onboarding, seen in any order.
This doesn't guide testers, who never see it. It's for you: it's what produces the completion rate. In DASHUND, you set it in the prototype's Settings and can change it anytime; the whole history is recalculated.
Step 2: Make a prototype that stands on its own
A task-based test forgives an unfinished prototype, because the task steers people away from the empty parts. Without tasks, people go everywhere. Before you publish:
- A clear starting point. The first screen should say what the product is and what you can do with it, without you in
the room.
- No accidental dead ends. A screen with no way out reads as the end of the path. If it isn't, add a way back.
- Readable frame names. "Cart," "Shipping," "Payment": you'll read your results with these names.
- Believable content. Real labels, plausible prices. Lorem ipsum pulls people out of the experience.
Unfinished areas aren't a problem in themselves. Clicks on them tell you what people expected. You just need to keep that in mind when you read the results.
Step 3: Share through separate links
Since there's no recruiting, your distribution is your panel. One link per audience keeps behaviors apart: newsletter, existing customers, a LinkedIn post, your internal team. For example, an audience that already knows the product will often move faster than one discovering it; mix them and your numbers get muddy.
Introduce the link simply: "Here's the new version of our app, give it a try." Don't slip a mission into the message ("try booking a time slot"), or you've brought the task right back in.
With DASHUND, each audience gets its own DASHUND link to the same prototype, and the Segmentation tab compares their sessions, median duration, completion and bounce. Testers don't create an account or install anything: they open the link on their phone or computer.
Step 4: Read the results in the right order
Without tasks, the data is richer and more scattered. A reading order helps:
- Completion and bounce. How many sessions reach the goal? How many leave without a single click? A high bounce rate
usually points to the first screen.
- The Flow. The real paths, screen by screen, and where sessions stop. A big exit right before the goal is the first
thing to look at.
- Heatmaps. On the screens where people leave, where do they click? Clicks outside the clickable areas reveal an
expectation the design doesn't meet.
- A few sessions, one by one. Once you've spotted a problem, replay three or four sessions that ran into it. That's where
your hypothesis takes shape.
Keep in mind that early sessions are clues, not proof. DASHUND shows a "Small sample" label under 30 sessions, though a clear blocker often shows up well before that.
Common pitfalls
- Testing it yourself through the link. Your session counts like a tester's. Use the preview, or delete your own
sessions afterward.
- Drawing conclusions about a path nobody saw. If a screen is almost never reached, that doesn't mean it works. It may mean
people can't find it.
- Mistaking exploration for failure. Someone who visits five screens and leaves didn't necessarily fail; maybe they got
what they came for. That's why Step 1 matters.
- Changing the prototype mid-test. A published prototype should stay frozen, or your numbers mix two designs. A new
version gets published separately and compared with the old one.
The guide How to test a Figma prototype with real users walks through the setup, and the Features page shows every view in DASHUND.
FAQ
Does testing without tasks replace classic usability testing?
No. It shows what many people do, at scale. An interview or a task-based test explains why, or checks one specific point. They complement each other.
How do you know a session succeeded without instructions?
By defining a goal screen, several possible endings, or checkpoints ahead of time. The completion rate is calculated from that choice, and testers never see it.
What should I tell testers when I share the link?
Introduce the product, not a mission: "Here's the new version, give it a try." A sentence that suggests a specific action turns back into a task.
How many sessions do I need for a test without tasks?
A few sessions are enough to spot an obvious blocker. To compare two versions or two audiences, aim for at least 30 sessions on each side.
Does the prototype need to be finished?
No, but it has to stand on its own: a clear starting point and no accidental dead ends. Clicks on unfinished areas are actually useful, because they show what people expected.