Link your screens into a clickable prototype in free Figma so people can try the flow before anything is built.
Why it matters
A wireframe shows a screen. A prototype lets someone use it. When people tap through a prototype, they reveal problems no static picture can: buttons they do not notice, steps they did not expect, and moments where they do not know what to do next. A prototype is also the clearest way to explain a flow to stakeholders and developers. Clicking through takes a minute; reading a spec takes much longer.
The core idea: just enough to answer a question
A prototype is a question in disguise. Before you build one, write what you want to learn: "Can people split a bill unequally without help?" Then build only what is needed for that question. A prototype does not need every screen, real data or working logic. It needs the path being tested, plus enough surrounding screens that people do not hit a wall immediately.
Prototypes come in fidelities too:
- Paper prototype: hand-drawn screens; a person plays "the computer" and swaps paper when the participant taps. Very fast and surprisingly effective.
- Clickable wireframes: grey-scale screens linked with hotspots.
- High-fidelity prototype: close to the real look, with transitions and realistic content.
Prototyping in Figma (free plan)
Figma's free Starter plan includes prototyping. The basic steps:
- Frames are screens. Put each wireframe in its own phone-sized frame (Frame tool, then choose a phone preset).
- Switch to Prototype mode. In the right-hand panel, open the Prototype tab.
- Add connections. Select a button or hotspot; drag the small circle that appears onto the destination frame. Each connection is an interaction: a trigger (On click/tap), an action (Navigate to) and an optional animation (Instant, Dissolve, Smart animate).
- Set a starting point. The first frame of the flow becomes the flow's starting point. You can have several flows in one file.
- Add back navigation. Connect back arrows using the "Back" action so people can recover.
- Present. Press the play button to preview, or share the prototype link with test participants.
Keep transitions simple ("Instant" or "Dissolve"); fancy animations take time and rarely answer your question.
Worked example: the bill-split prototype
Question: Can people split a bill unequally and send requests without help?
Screens needed: Bill detail, Split (equal), Split (edit amounts), Split (totals do not match error), Review, Confirmation, plus a simple Home so participants have a realistic start.
Connections:
| From | Hotspot | To |
|---|---|---|
| Home | Notification card "Internet bill added" | Bill detail |
| Bill detail | "Split this bill" | Split (equal) |
| Split (equal) | "No" radio | Split (edit amounts) |
| Split (edit amounts) | "Send requests" | Split (error) |
| Split (error) | "Fix amounts" | Review |
| Review | "Send requests" | Confirmation |
Notice the trick in row 4: the prototype cannot calculate, so the first press of Send always shows the error state. In a test, you set up a scenario ("Leo owes 20, the others share the rest") that leads people to that state naturally. Prototypes often fake logic with extra frames like this.
Making prototypes testable
- Use realistic content that matches your test scenario (names, amounts, dates).
- Make sure every visible button on the tested path does something, even if it only shows a "Not part of this test" message. Dead buttons confuse participants and spoil data.
- Put a frame number or name on each screen in the file so you can follow along during a test.
- Click through the whole prototype yourself, then ask one person to try it before a real session.
Common mistakes
- Prototyping everything. Weeks spent wiring an entire app. Build what answers the question.
- Polishing before testing. High fidelity too early makes it painful to change.
- Hotspots that are too small or missing. Participants tap a label instead of the button; nothing happens; the test stalls.
- No way back. Without back links, one wrong tap ends the session.
- Testing the prototype tool instead of the design. If people are confused by the prototype's limits, say so up front and design the scenario around them.
Quick recap
- A prototype lets people use a design so you can watch what happens.
- Start from a question and build only the screens and links needed to answer it.
- In Figma: frames as screens, Prototype tab, drag connections, set a starting point, present.
- Fake logic with extra frames, make every visible control respond, and pilot before testing.
Try it
On the Do tab you will turn your wireframes into a clickable prototype and pilot it with one person.