Interactive prototype in Figma: how to convince the customer from the first show

The customer sits across the street, opens the laptop, and 40 seconds later he says, "Can I show you how this will work?" You open Figma, click on the frame, and you get in the wrong place. Then again, wrong. Then you explain in words that this is the animation, and this is the modal. By the end of the meeting, the customer nods, but the decision is postponed “to think.”.

It's not about design. This is about the fact that the static layout loses to the imagination of the customer. He sees the picture, but he doesn't feel the product. Until he feels it, he doesn’t buy.

An interactive prototype solves exactly this problem. But a poorly assembled prototype is worse than static: it breaks at the show, confuses the customer and undermines the trust in the team. Therefore, the question is not “do or not”, but “how to put together so that the first show closes the deal”.

---

## Why a static layout almost always loses

The customer is not a designer. He can't put 12 screens in his head. What he doesn't know is that there's a three-state transition between screen 3 and screen 4. He looks at the statics and sees exactly what he sees: a set of pictures.

From this grow three typical problems of the first show:

• ** Questions are not about the product, but about the artifact.** “Why is there a button in this color?” instead of “Will the user manage to register?”
• Infinite edits on details. When the script is not visible, the customer clings to the details - this is the only thing he can appreciate.
• “Show more options,” “Let’s talk inside,” “We’ll be back in a week.” This is not about the layout - it is about the fact that the customer did not see the working product.

The prototype switches the conversation. The customer clicks, passes the script, catches the feeling of “oh, this is already working” – and discusses the essence, not the colors.

---

## What is considered an interactive prototype and what is not

This place is often confused. “I tied the frames with arrows” is not a prototype in the sense that convinces the customer. It's a clickable layout.

### Three levels of readiness

Level 1: Clickable layout. Frames are connected by transitions, buttons lead where appropriate. Suitable for internal review, not suitable for display to the customer.

Level 2: Scenario Prototype. Collected one or two key user scenarios from input to output. There are states (hover, active, disabled), there is basic transition animation, works on a mobile device if the product is mobile. That's the bare minimum.

** Level 3: Product Prototype.** Uses components with variants, variables for themes and states, smart animate for micro-interactions, realistic data. The customer does not differ from the working product in the first minutes.

For the first display, aim for Level 2 with Level 3 point elements in the most prominent places: the main CTA, the key transition, the wow moment.

### Anti-pattern: the prototype of everything

The temptation is to show every page and every state. In practice, it kills the display: you spend time building, the prototype becomes fragile, the customer is lost in the number of screens.

Rule: one scenario that answers the main question of the customer. Everything else is static.

---

## Where to start: Selecting a scenario for the customer

Before you open Figma, you need to understand what exactly the customer wants to see in the work. Not the whole product, but the specific path that matters most.

### Questions before assembly

• What decision does the customer make based on the results of the show? (launch, budget, hiring a team)
• Which scenario will he or she repeat most often?
• Where in the current product or competitors is it painful? The prototype should show that we are not in pain.
• What did the customer show to the previous contractors and what was not satisfied?

The answers to these questions are given by one or two scenarios around which the prototype is built. Everything else is background.

### Script selection checklist

• The script ends with a measurable result (the order is executed, the report is built, the profile is created)
• In a scenario, there is a point where a product does something markedly better than alternatives
• The script takes 60 to 90 seconds without explanation
• In the script no more than 6-8 screens
• The script works on the device from which the customer will look

If the script does not go through these points, the prototype will look cumbersome even with a perfect build.

---

The short result of the first part: the prototype convinces not by the volume, but by the accuracy of getting into the script, which is important to the customer. Next, we will analyze the assembly itself – the file structure, components, transitions and preparation for the display.

## Prototype Assembly: A File Structure That Will Not Fall Apart

The main mistake at this stage is to assemble a prototype "like a layout, only with arrows." The prototype is a separate artifact with its own file logic, and if this is not taken into account, something will necessarily fall off at the display: the link is wrong, the state did not pull up, the layout went on the phone.

### Basic page structure in Figma

One file, one head. Inside the file, I spread the pages by roles so that during the show I do not climb random frames.

• Cover – cover with title, version, script reference
• Flow - [script name] - only those screens that participate in the clickable pass
• Components—Components with variants and states
• Library / Tokens - variable colors, typography, indentations
• *Archive – everything that is not included in the show, but it is a pity to remove

The Flow page is a screening scene. There should be nothing superfluous on it: neither parallel versions, nor “let’s try this again.” Parallel options - in Archive, otherwise on the screening accidentally click the wrong place.

### Components and options: where to save, where not

The temptation to build a prototype "of flat frames" is large - it seems that faster. You'll regret the second change.

What to do with a component with options:

• Buttons (default / hover / pressed / disabled / loading)
• Input fields (empty / focused / filled / error)
• Cards of entities that have more than one on the screen
• Navigation (active/inactive point states)

What the component does not need to do for a prototype to show:

• Unique screens-"heroes" (main, success-page)
• Decorative blocks that meet once
• Conditions that are not involved in the screenplay

Rule: A component is justified if the state changes over the course of a scenario or the element occurs more than twice.

---

## Transitions: where Smart Animate helps, and where prevents

Smart Animate looks magical, but at the show it often creates the feeling of “glutch”. The reason is usually one - the discrepancy of the names of layers between frames.

### When to use Smart Animate

• Switching inside one screen: opening the curtain, turning the card, the appearance of a list
• Change in the state of the element: checkbox, toggle, load indicator
• Switch between steps of one flou, where screens are similar to 80%

### When not to use

• Change the screen with different structures – better Instant or Dissolve
• Long lists with dynamic content
• Transitions where the developer won’t be able to repeat it (meaning you’re selling what’s not in the product—a separate ethical trap)

### Checklist of stable transition

• The layers that should “flow” have the same names in both frames
• They lie in the same hierarchy (frame → group → element)
• Duration 200-400 ms, ease out for appearances, ease in-out for movement
• On a slow device, the transition is still readable, doesn't twitch
• If you remove the animation, the script remains clear

The last point is the most important. Animation emphasizes logic, not replaces it.

---

## Diagnosis: What usually breaks an hour before a screening

Scenarios that you encounter regularly.

Symptom: "Prototype brakes on the customer's phone." The reason is almost always heavy pictures in the original resolution or excessive blure effects. Run the images through the compression, turn off the shade where it is decorative.

Symptom: “Clicked the wrong way and the prototype broke down.” ** There is no default transition from dead ends. Each screen should have either an explicit CTA or a way to return. Add an overlay prompt on the first click past.

Symptom: "The review looked different." Viewing in the editor and in Present mode are different worlds. The final check is always done in Present, from the device from which the customer will watch.

Symptom: "Customer didn't find where to click." Hotspot is too small or in an unexpected place. Expand the hit area with an invisible frame on top – this is normal practice.

### Anti-patterns that can be seen immediately

• The prototype is shown from the designer’s laptop, and the product is mobile
• In the script, there’s a “imagine what’s going to happen here...” step, which means the script isn’t ready
• The customer never clicked during the show
• Designer comments on every screen out loud - the prototype has to speak for itself

---

## Questions for internal review before screening

Run the prototype on a colleague who hasn't seen the project. He must answer yes to each:

• What kind of product is this without explanation?
• You know what scenario we're going through?
• Did you get to the end without help?
• Was there a moment I remembered?
• If it were a work product, what would be the first thing to break?

The last question is golden. It pulls out holes that the designer can no longer see.

---

The short build result: the file structure protects against accidents, components from fragility, Smart Animate works only with clean layer names, and the final check is always in the Present and on the customer’s device. Next is the show itself: how to conduct a meeting so that the prototype works, and does not turn into another “discussion of layouts”.

## Advanced Scenarios: When an Ordinary Click is Missing

The basic prototype conducts on a linear flow. But the customer most often wants to see not the perfect scenario, but a fork: “and what will happen if the user has an empty basket”, “and if he has already signed”, “and if a payment error”. Here the linear circuit breaks down.

### Variables and Conditions: Why and When

Variables at Figma turns a prototype from a slideshow into simple logic. It is useful in exactly three cases:

• The state that you need to drag through several screens (login, selected plan, design theme)
• Counters and forms where the value affects the next step (number of goods, validation)
• Fork on the role of the user on one demo: admin, ordinary user, guest

If a variable is used once – it is not necessary, enough of the duplicate frame. Variables are justified when the alternative is ten almost identical screens.

### Anti-Pattern: “Prototype App”

The temptation to build a small working application in Figma arises for everyone who has figured out the variables. It's a trap. The prototype is a hypothesis testing tool, not a replacement for the frontend. Signs that you have gone too far:

• The file opens for more than five seconds
• Logic is only in the mind of the author
• Changing copyright takes fifteen minutes
• The developer looks and says, "We won't do that."

The last is the main thing. If the prototype demonstrates behavior that the team will not repeat, you sell a promise that cannot be kept.

---

## AI and Figma: where it really accelerates, where it interferes

Now in any discussion of the prototype pops up “let’s generate through AI”. Where it works for the benefit of:

• Content blacklist: realistic names, descriptions, prices instead of Lorem Ipsum
• Generation of Copyright Options for CTAs and Emptistates
• Quick assembly of decorative illustrations for one-off screens
• MCP integrations that pick up the desired components from the design system

Where AI consistently fails:

• Flow Structure – The model collects the “average” scenario, not yours
• The logic of states – skips edge cases that are just important to the customer
• Compliance with the design system – the components look similar, but they are not your components

### Rules for an AI-assisted prototype

• AI works in the filling phase, not in the architecture phase
• Any generated screen goes through the same check as a hand drawn screen
• Before the show - a separate passage "find traces of generation": the same phrases, broken transitions, foreign components
• Don’t show the customer what you don’t understand; if the AI has assembled the transition and you don’t know how it works, throw it away

The main risk is not quality, but responsibility. To the question “why is this so?” the answer “AI suggested” is not accepted by either the customer or the team.

---

## How to explain a prototype to the team

The customer nods - that's half the battle. Next, the prototype goes into development, analytics, content. If the team does not understand what is being shown, a “creative interpretation” will begin at the implementation stage.

### What to attach to the file

• Screen map: a list with one sentence about each ("this screen after successful payment")
• List of variables and what they mean
• Explicitly labeled “prototype, not final design” where true
• A list of what is not in the prototype, but it is conscious (empty states, network errors, offline)

### Questions that the developer must answer after the review

• It is clear which transitions are animation, and which are product behavior?
• It is clear that this is wet data, and what is real logic?
• You can see where the component from the design system is used, and where is the one-time version?
• Is there a behavior in the prototype that cannot be implemented on the current stack?

If one answer is no, the prototype is not ready to go into operation, even if the customer has already accepted it.

---

## Quality check: final pass

Before sending a link, run the file through three slices.

Speed slice. Open Present from a cold start on the customer's device. If the first screen is longer than three seconds, optimize your images and effects.

Slice logic. Go through the main script twice in a row without looking at the editor. On the second pass, pay attention only to the moments where you yourself think for a second - these are places where the customer will think.

Go through screens and ask one question: “Is this behavior really going to appear in the product in the foreseeable future?” If the answer is “unlikely,” mark the screen as illustrative or remove it.

---

The bottom line: Advanced scenarios are justified when without them the essence is lost; AI speeds up content, but is not responsible for decisions; the team needs not only a file, but also a map of what is wet and what is grocery. And then the most nervous part is the show itself.

## Checklist of the prototype ready for display

Final check before opening Zoom and pressing Present. If at least one item is not closed - postpone the show for a couple of hours, finish, then return.

### Contents

• The main scenario goes from beginning to end without explanation on my part
• All CTAs lead somewhere - there are no "dead" buttons in mostly float
• Texts, numbers and names look like real product data, not stubs
• Load states and errors are shown at least for key screens
• There is one “wow moment” for which the customer came

### Technique

• Present opens on the customer's device in a reasonable time
• Prototype tested on both laptop and phone if both scenarios are discussed
• Fonts and icons have not left - there are no "squares" instead of glyphs
• Components from a design system are actually components from a system, not visual copies of them
• The file is renamed and lies in the folder, the link to which is not ashamed to send

### Communication

• I know which screen I will start with and which one I will end with
• I have one or two questions that I will ask myself – to lead the discussion, not to answer random questions
• I know what's wet and what's a real promise, and I can share it aloud
• There's a plan B if someone says, "Show me this other scenario."

---

## Anti-patterns that break the show

### Prototype portfolio

Symptom: five options for the main screen, three themes of design, animation for each click. The customer does not understand what to discuss, and goes into the discussion of the color of the button.

Treatment: one basic flow, the rest - in a separate page "research", open on request.

### Demo wizard

Symptom: the prototype works only in the hands of the author. The author knows where to tap to make the transition work, and in what order to open the screens.

Treatment: Link a colleague who is not in context at all. If he is stuck, the customer will get stuck, just silently.

### Prototype promise

Symptom: Showing interactions that look beautiful, but the team honestly says, "We're not going to pull it out in a sprint." The customer has already mentally “buyed” this behavior.

Treatment: prior to the show to agree with the development, which in the prototype is implemented in the foreseeable release. Everything else is either removed or explicitly marked as “direction, not commitment.”.

### Too much mope under the guise of a product

Symptom: 12 cards on the screen, everyone has different data, everything looks like a finished product. The question “Where does this data come from?” has no answer.

Treatment: either honestly show an empty state and one completed card, or talk about which data sources are assumed.

### Animation for the sake of animation

Symptom: each transition is a Smart Animate with a spring. After five minutes, the customer begins to get tired, after ten - irritated.

Treatment: Animation only where it explains the relationship between conditions. Everything else is an instantaneous transition.

---

## Questions for a prototype review

If you can run the prototype through a colleague before the show, give him this list. If not, ask yourself questions, honestly.

### On behalf of the customer

• I know what this product is after the first screen?
• Do I see how my task, for which I ordered the work, is solved?
• Is there a point where I don’t know what will happen after I click?
• Is there a screen that surprised me in a bad way - "why is that?"?

### On behalf of the developer

• Can I put this together on the current stack without heroism?
• I understand what data comes from the back, and what is generated on the client?
• Are the animations described enough for me to repeat, or do I have to improvise?

### On behalf of the designer on the team

• Could I open this file in six months and figure out how to use it?
• Are the components named so that they can be searched?
• If I'm gone tomorrow, can anyone continue with this file?

---

## Short practical outcome

A good demonstration of a prototype is neither magic nor charisma. This is the sum of the boring decisions made before the meeting: one scenario is chosen instead of five, wet data is similar to the real one, transitions are coordinated with development, animations work for meaning, not effect. The customer agrees not because you sold beautifully, but because he has nothing to say about it – everything he sees looks like a product that will actually live. The rest is calm at the show itself and the willingness to hear “let’s redo this” without offense.