Prototyping

The production question

You've got the Recovery Setup screens built and a component library with all your button states — now which transitions actually get wired into a real Figma prototype, and which get left as static frames? Connecting every frame in the file with default “on click, next frame” burns an afternoon and produces a demo that looks complete but proves nothing. The judgment call is deciding which interaction questions the team actually needs answered — can a user back out of a confirmation, does a validation error recover cleanly, does a choice survive a trip back to review — and wiring only those, deliberately, instead of chasing full connectivity.

How to decide

1. Name the critical path first: the one sequence someone needs to click through to trust the flow works — for a recovery workflow that's dashboard → workload detail → recovery setup → review → confirm → progress → success. Wire that completely before touching anything else.
2. For every screen on that path, ask what the user could do besides proceed: cancel, submit with a missing field, go back. Each of those is a recovery branch, and recovery branches are the actual point of a prototype, not an afterthought.
3. For each interaction, decide if it's local state or navigation. Hover, press, and disabled feedback on a button is local state and belongs on an interactive component variant. Moving from one screen's content to another's is navigation and belongs on a frame connection. Mixing them up produces duplicated screens for what should be one component.
4. Wherever a task interrupts the main flow — a confirmation, a destructive action, a focused single task — use an overlay, and wire its close and cancel targets to the specific frame the user came from, never left unconnected.
5. Run the stress tests before calling the prototype done: cancel from confirmation, submit without a required field, return from review and check the earlier choice is still there, and imagine using it with only Tab and Enter.
6. Stop wiring once the questions above are answered. A connection added because a frame happened to be next in the layer list, not because someone needs to test that transition, is scope creep dressed up as thoroughness.

Correct vs. incorrect

Practice it, then try to break it

Build three frames: a one-field form (“Set recovery target”), its validation-error state, and a success state. Wire the submit button so an empty field routes to the error frame, wire the error frame's retry action back to the form with the field visibly cleared, and wire a filled-in submit to success. Then click through it twice — once submitting empty first to hit the error path, once going straight to success — and check that the error frame doesn't strand you with no way back to a working form.

Stress test: Click Cancel from the confirmation overlay, then try to pick up the flow again from where you left off. If Cancel dumps you back at the dashboard instead of the review screen you cancelled from, or the review screen has forgotten the target you'd selected, the prototype fails the actual test of recoverability — even though technically every frame in it is connected to something.

Common mistakes

• Connecting every frame in file or layer order with the default click-to-next-frame behavior instead of deliberately wiring the critical path plus its cancel, error, and back branches.
• Duplicating a full screen for each button state (default, hover, pressed, disabled) instead of building those as variants on one interactive component.
• Wiring an overlay's close or cancel button to “close overlay” without confirming that lands the user back on the specific frame they opened it from, not a default or unrelated screen.
• Treating one successful click-through of the happy path as proof the prototype works, without also testing cancel, an empty or invalid submission, and whether a prior choice survives a trip back to an earlier screen.

Accessibility and handoff

Figma's prototype connections only simulate mouse clicks, not real keyboard focus order or Escape-to-close, so a prototype that “proves” an overlay works communicates nothing about keyboard behavior to developers unless you write down what Escape and Tab should do directly on the frame.

FAQ

What's the actual difference between prototyping and interactive components?

Prototyping connects separate frames to simulate navigation, like a button click moving you from Review to a Confirm overlay. Interactive components let one component change its own appearance in place, like a button showing hover or pressed feedback, without leaving the frame or duplicating screens.

Do I need to connect every screen in my file?

No. Wire the critical path the team needs validated, plus its cancel, error, and back branches. Screens that aren't part of an interaction question actually being tested can stay unconnected without hurting the prototype.

How should a confirmation overlay's Cancel button be wired?

Connect it explicitly back to the exact frame the user was on before the overlay opened, not a generic “close overlay” action. That's what proves cancelling returns someone to a working state instead of a dead end.

Can I build and test a prototype without Figma's Dev Mode?

Yes. Prototyping — connections, overlays, interactive component states — is a separate feature from Dev Mode. Dev Mode affects handoff inspection for developers; it has no bearing on whether you can build or click through a prototype.