Build a Clickable Prototype of an Interactive Commercial

A review prototype has one job: let someone else walk the interaction without you driving.

Four things make that possible. An entry state the reviewer lands on. An action they're offered. A visible response. A route back out. Add a fifth — the route for a viewer who declines — and you have something a client can judge in ninety seconds without a narration track.

That's the whole build. A clickable prototype demonstrates selected connections. It doesn't demonstrate the finished product, live data, or whether the platform will run the idea at all. The moment it starts implying otherwise, the review is answering a question nobody asked.

The example running through this piece is a fictional interactive commercial for a desk organizer. The viewer can look inside the front tray, read a short passage about what fits there, and continue to the closing screen — or skip the tray entirely. Small enough to hold in your head. Big enough to need a return route.

The cycle is the deliverable

Begin with states, not screens. Drawing an attractive frame first is how prototypes end up with a lovely opening and nowhere to go.

Name four things in plain language before you open anything:

• Entry. The state the reviewer lands on.
• Action. What the viewer is offered.
• Response. What they see because they took it.
• Return. How they get back, or get out.

Then name the fifth: what happens when the viewer declines, or does nothing at all.

Doing nothing is a real state. In a prototype it usually means staying on the frame that offered the action, which is fine — but only if you've decided that and can say so. If the answer is "then I'd click for them," you don't have a decline route. You have an invisible rescue, and it will disappear the moment someone else presents the file.

One distinction earns its keep here: navigation is not the same as a choice that changes content. Moving from one frame to another is navigation. Showing something because of what the viewer picked is a choice, and it usually needs more than a connection to be real. In the desk organizer example, exploring the tray takes you somewhere — but the ending you reach afterward is identical whether you explored or skipped. The choice changed what you saw, not what you got. That's honest, and it's the kind of thing a client will ask about, so decide it now rather than during the meeting.

Name the states before you place them

Each state becomes a frame. Keep the set as small as the cycle allows; five is a comfortable number for one commercial, and eight usually means you've included something the review isn't about.

Give the frames names that survive being read aloud. 02_Tray, not Frame 47. Names appear in the destination lists when you connect things, so a bad name costs you every time you wire a control.

Put the simulated content inside the frames, marked as simulated. A placeholder paragraph labeled "PLACEHOLDER — final wording not approved" does more for trust than a charming sentence with no label, because it tells the reviewer which parts of this object are decisions and which are stand-ins. Same for the closing claim: label it pending rather than letting a rough line read as approved copy.

Keep unsupported behavior out of the apparent demonstration, and label what you couldn't include on the frame where it would have lived. A note in an email gets lost. A line on the frame travels with the link.

Hotspot, trigger, action, destination

Figma's help page on connecting prototypes — last checked in September 2026, at help.figma.com/hc/en-us/articles/360040315773-Connect-your-prototype — describes the parts plainly: a connection associates an interaction with an action and a destination. That's the whole grammar, and it's worth learning as four separate nouns before you touch the panel.

The hotspot is the shape that catches the click. Put it over the thing the viewer is being invited to touch, and size it to that thing. A hotspot stretched across the entire frame technically works and teaches you nothing: every click succeeds, including the ones a real viewer wouldn't make, so you never learn whether the offered action was legible in the first place.

The trigger is what starts the transition — most often a click. The action is what happens: navigate to a frame, open a link, go back. The destination is where the action lands. In the Prototype tab, selecting a hotspot opens interaction details where you set trigger, action, and destination together.

Leave the transition alone unless the movement itself is what you're reviewing. A slow dissolve invites a conversation about motion when the open question is whether the interaction is worth building. You can always add animation later; you can't easily un-spend a meeting.

Panel labels move between Figma releases. If what you see doesn't match a description here, follow the panel in front of you — the four nouns are stable even when the interface isn't.

The return route and the decline route

Two different things get called "back," and mixing them up is how reviewers get stranded.

Return to previous goes one step back — from the tray to the organizer view. Reset to start throws the reviewer to the beginning of the cycle. Both are useful, neither is a substitute for the other, and every control that does one of them should say which.

Then check what actually needs clearing. In a fixture like this one, nothing does: the tray being "open" is just which frame you're on, and there's no stored state to reset. That's worth saying out loud, because it's also the honest limit. If the finished commercial would remember that the viewer explored the tray, this prototype can't show that memory, and admitting it costs you one line on a frame.

The decline route needs a visible control. If the only way to say no is to close the tab, the reviewer learns nothing about the path most viewers will take, and the client's obvious question goes unanswered. Give the decline an actual destination.

And here is the rule that saves you the most embarrassment: a drawn button is not a connection — it's a picture of a button. A rectangle styled to look like a control, with no connection behind it, does nothing when the reviewer presses it. That's a dead control, and it reads as a broken prototype rather than an unfinished one. If a branch genuinely isn't implemented, label it where it sits. Don't dress a dead control as a supported path.

Walk it from the front door

Review it the way the reviewer will, which means entering through the intended starting view and clicking only what a viewer can click.

That rules out your editing-mode habits. Jumping to a frame from the canvas, using the frame list, or stepping through with a keyboard is an author shortcut, not a path. It confirms the frames exist. It tells you nothing about whether the controls work.

Walk the cycle in order — entry, action, response, return, decline — and write down what you find. Keep the note narrow. "Back did nothing in the presented build, on this laptop, on this date" is an observation. "Users found the back button confusing" is a claim you haven't earned from one person pressing one button.

If the treatment calls for a different input — hover, swipe, a timed reveal — that's a different trigger and it needs its own connection and its own check. A click version does not stand in for a swipe version; they're separate pieces of evidence.

Two other things go in the record, because both are easy to forget and expensive to discover later. First, which build you walked: a version name and a date, so the reviewer's ten-minute-old screenshot matches the file they're about to open. Second, anything the walk raised that isn't a defect — "the tray passage is four lines; will three fit better" is a design question, not a bug, and mixing the two makes the fix list unreadable.

The desk organizer, assembled

What follows is a design, not a build. No Figma file was created for this article, and no one has walked it. Treat it as the shape your own fixture takes.

Five frames:

• 00_Cover — the entry state and the label. Prototype name, version, date, one line: "Simulated content. Final copy and platform behavior are not represented." One hotspot: Start.
• 01_Organizer — the organizer, seen from the front. One hotspot over the front tray. One secondary link: Skip ahead.
• 02_Tray — the tray, open, with three lines of placeholder copy about what fits there, marked as placeholder. Two controls: Back and Continue.
• 03_Ending — the closing screen and the product claim, marked as pending. Two controls: Walk it again and What this prototype doesn't show.
• 04_Limits — the disclosure list, on a frame rather than in a message. One control: Back.

Eight connections:

Every frame is reachable from inside the cycle, and every frame has a way out. That's why Walk it again goes back to the cover rather than straight to the organizer view — a reviewer who wants to re-read the disclaimer should be able to, and a frame that nothing connects to is a dead end the moment you hand the file over.

Now suppose the first pass ships with the tray's Back control drawn but left unconnected — the most common version of this mistake, because the button looks finished and the panel beside it is empty. Say the walk produces this:

00_Cover — starts here when presented. Start works. 01_Organizer — tray hotspot works. Skip ahead works. 02_Tray — Continue works. Back does nothing. 03_Ending — both controls work. 04_Limits — Back works.

One line names the problem, and one line names the fix: select the Back control on 02_Tray, add a single connection, On click → Navigate to → 01_Organizer. Then walk it again from the cover. That's a scoped repair — one connection, no rebuild, no renegotiation of the states.

It's worth running this deliberately once, on purpose, before you hand anything over. The walk that finds the dead control in your own file is much cheaper than the one that finds it in the client's meeting.

What the fixture can't settle

The last frame in the cycle should say what the prototype is not, in the same language the reviewer will use.

For the desk organizer, that list reads like this: the content passage is fixed copy, and no data is retrieved to produce it. The ending is identical whichever route you take, so nothing here shows what a viewer who declines would actually receive. No hover, swipe, or timed reveal is implemented. And nothing in this file establishes whether an ad platform will accept, serve, or measure this interaction, or whether it will behave the same way on a phone.

None of that is a flaw in the prototype. It's the boundary of what a prototype is evidence for. Keep the list short and put it where the reviewer will see it without being told to look.

One last check before you send a link: open it the way the reviewer will open it. Your own account view is not their view, and sharing permissions decide whether they can reach the presentation mode at all. If they can't walk the cycle, you've built the fixture and thrown away the evidence.

A finished handoff sounds like this: "Start at the cover. The tray opens if you click it, or skip ahead. Everything after that is one of three screens. The copy is placeholder and the ending is the same either way — the last frame lists what we're not claiming." If you have to narrate past that, the prototype isn't done.

Frequently asked questions

What has to be in a clickable prototype before anyone can review the interaction?

An entry state the reviewer lands on, an action they are offered, a visible response, and a route back out. Add a fifth: what happens when the viewer declines or does nothing. Doing nothing is a real state, so decide it rather than clicking for them. Also distinguish navigation from a choice that changes content: moving between frames is navigation, while showing something because of what the viewer picked is a choice. In the desk organizer example, exploring the tray changes what you see, not what you get. A clickable prototype demonstrates selected connections; it does not demonstrate the finished product, live data, or whether the platform will run the idea.

How should I name frames and mark placeholder or pending content?

Begin with states, not screens, and keep the frame set as small as the cycle allows; five is comfortable for one commercial, while eight usually means something outside the review has been included. Give frames names that survive being read aloud, like 02_Tray rather than Frame 47. Put simulated content inside the frames and mark it as simulated. A placeholder paragraph labeled 'PLACEHOLDER — final wording not approved' does more for trust than a charming unlabeled sentence. Label pending closing claims and unsupported behavior on the frame where it would have lived.

What are the four nouns of a prototype connection, and how should I use them?

The hotspot is the shape that catches the click; put it over the thing the viewer is invited to touch and size it to that thing. A full-frame hotspot works but teaches nothing because every click succeeds. The trigger starts the transition, most often a click. The action is what happens: navigate to a frame, open a link, or go back. The destination is where the action lands. In the Prototype tab, selecting a hotspot opens interaction details where trigger, action, and destination are set together. Leave the transition alone unless the movement itself is what you are reviewing, and follow the panel in front of you if labels differ between releases.

What is the difference between return to previous and reset to start, and how should the decline route work?

Return to previous goes one step back, from the tray to the organizer view. Reset to start throws the reviewer to the beginning of the cycle. Both are useful, neither substitutes for the other, and every control that does one should say which. Check what actually needs clearing; in the desk organizer fixture nothing does, because the tray being open is just which frame you are on. If the finished commercial would remember that the viewer explored the tray, this prototype cannot show that memory, and admitting it costs one line on a frame. The decline route needs a visible control; if the only way to say no is to close the tab, the reviewer learns nothing about the path most viewers will take.

Why is a drawn button without a connection a problem, and how should I walk the prototype before handoff?

A drawn button is not a connection — it is a picture of a button. With no connection behind it, it does nothing when the reviewer presses it; that is a dead control, and it reads as a broken prototype rather than an unfinished one. If a branch genuinely is not implemented, label it where it sits; do not dress a dead control as a supported path. Review it the way the reviewer will: enter through the intended starting view and click only what a viewer can click. Do not jump to a frame from the canvas, use the frame list, or step through with a keyboard, because those are author shortcuts. Walk the cycle in order — entry, action, response, return, decline — and write down what you find. Keep the note narrow, for example 'Back did nothing in the presented build, on this laptop, on this date.' Record which build you walked with a version name and date, and separate non-defect design questions from defects. For the common tray Back failure, select the Back control on 02_Tray, add On click → Navigate to → 01_Organizer, then walk it again from the cover.

Further reading

• When an Interactive Commercial Needs a Different Story From the Linear Film — Read it when someone asks whether the choice should change the story rather than only what the viewer saw, and the no-action default needs writing down.
• Build a Branching Film Pitch Prototype That Remembers Earlier Choices — For the memory a click-through cannot hold: a film-pitch prototype built around one stored choice and a later responding scene, with its path table still to be run.