How to Use Personas in Floto: A Practical Guide

The setup

A team is redesigning the first-run onboarding screen for a B2B SaaS dashboard. The screen has one job: get a non-technical user to connect their first data source. The design looks clean. The copy has been through two rounds of edits. Nobody on the team can tell if it actually works — because everyone reviewing it already knows what the product does.

That's the exact gap Persona Testing is built for: it swaps "does this look right to me" for "does this land with someone who isn't me."

Step 1: Pick the frame, not the file

Inside Figma, the team opens Floto and selects a single frame — the onboarding screen — rather than the whole flow. Floto tests one frame at a time by design, because a persona reacting to an entire file gives vague, diluted feedback. Since this is step 1 of a 3-step onboarding sequence, they add a one-line note to that effect so the persona has the right context for what came before and what's next.

Step 2: Choose — or build — the right persona

Floto suggests personas that match the design's likely audience, and those suggestions can be edited or replaced with a persona built from scratch. For this test, the team doesn't want a generic reaction — they want to know if a specific kind of user gets stuck. They pick two:

• Maya, Marketing Manager, 28 — non-technical, time-poor, doesn't want to feel embarrassed asking for help.

• Raj, Senior Engineer, 34 — security-conscious, wants to know exactly what data is being requested before he commits to anything.

Running the same screen against a non-technical persona and a technical, skeptical one is deliberate — it's the fastest way to see whether the design is actually serving the audience it claims to, or just the audience the designer had in mind.

Step 3: Ask one focused question, then follow up

The team starts broad, then narrows:

To Maya: "What's the first thing you'd do on this screen?"

"I'd go toward the 'Connect' button, but I'd hesitate. I don't know what happens after I click it — will it ask me for something technical? I don't want to get three steps in and realize I need my engineer's help."

That's a specific, actionable signal: the copy isn't telling Maya what happens after the click, and that ambiguity is what's causing hesitation — not the button itself.

To Raj, asked about hesitation directly: "Is there anything here that would make you hesitate to connect a data source?"

"I can't tell what permissions this needs. If it's asking for read/write access to production data, I want that stated up front, not buried after I click through."

Different persona, different concern — but both point at the same root cause: the screen assumes trust it hasn't earned yet with either audience.

Step 4: Look for the pattern, not the individual opinion

One persona flagging an issue is a data point. Two personas — with very different priorities — independently landing on "this screen doesn't tell me enough before asking me to act" is a pattern worth acting on. That's the signal the team takes into the redesign, rather than any single line of feedback taken in isolation.

Step 5: Redesign, then re-test

The team adds a single line of microcopy above the CTA — stating in plain terms what happens next and what access is being requested — and re-runs the same two personas against the updated frame.

Maya: "Okay, that's clearer. I still might loop in someone technical, but at least I know what I'm agreeing to." Raj: "Better. I'd still want a link to the permissions doc, but this doesn't feel like a black box anymore."

Neither response is a green light to ship blind — but both show the specific hesitation from round one has measurably softened. That's the outcome Persona Testing is meant to produce: not a pass/fail score, but a before-and-after read on a specific friction point.

Step 6: Use it to prioritize real user research

The team doesn't stop here. The persona feedback didn't replace user testing — it told them exactly which two things to validate with real users first: whether the new copy actually reduces drop-off at this step, and whether a permissions link is worth the extra click. That's the intended relationship between the two: synthetic feedback for fast, directional signal; real user sessions for confirmation on the highest-stakes open questions.

Why this works as a workflow, not just a feature

A few things made this test useful rather than just interesting:

• One frame, one question at a time. Testing the whole flow at once would have buried the specific friction point in generic feedback.

• Deliberately mismatched personas. Testing only with a persona similar to the design team's own mental model would have missed the issue entirely.

• Pattern over opinion. The decision to act came from convergence across two different personas, not from a single compelling quote.

• A before/after loop. Re-testing the same personas against the revised frame turned a one-off critique into a way of measuring whether the fix actually worked.

Quick reference: the workflow

1. Select a single frame (add context notes for multi-step flows)

2. Choose or build a persona that matches who'd realistically land on this screen

3. Ask one focused question, then follow up on what you're actually uncertain about

4. Run it across 2–3 personas — treat agreement as signal

5. Redesign, then re-test the same personas against the same question

6. Use the findings to decide what's worth validating with real users next

Persona Testing runs on 50 credits per test inside the Figma plugin. Built-in personas cover a range of roles and technical comfort levels, or you can build custom ones — including from your own research — to mirror your actual audience.