The easiest prototype to generate is often the least informative: a polished first screen with a convincing success path. The harder questions appear when someone changes their mind, enters unexpected data or loses the connection. Designers and developers get more value from AI prototyping when they use it to investigate those moments rather than produce another attractive landing page.
Figma Make can help explore interactive behaviour. That does not make a Make prototype a production-ready application or establish that its behaviour is usable. Treat it as an instrument for answering a specific product question.
Choose an uncertainty before choosing a prompt
Imagine an illustrative booking tool where people select a time, add details and confirm. The uncertainty might be whether people understand that a selected time is not reserved until confirmation. This is more precise than “prototype the booking experience.”
Write the question, the participant task and the observation that would change your decision. For example: can someone explain the reservation status before confirming? If they cannot, the prototype should help reveal whether the wording, sequence or interaction is responsible.
Designers can define the intended mental model. Developers can flag where availability checks and reservation creation are separate operations. That conversation prevents a prototype from quietly promising behaviour the actual system cannot deliver.
Prototype the boundary, not just the screen
Describe the flow with explicit states: no selection, selection pending validation, available, no longer available, submitting, confirmed and failed. Include how the person returns to a safe state. A spinner alone does not explain whether a reservation exists.
A focused prompt might say:
Build a testable booking flow using fictional availability. Make selected and confirmed states visibly different. Include a slot becoming unavailable before submission. Preserve entered details on failure. Do not connect to live services or send notifications.
This is a recommended prompt pattern, not a promise that a tool will obey every constraint. Inspect the result. Check whether the prototype actually uses the fixtures, whether failure is reachable and whether any service connection has been introduced.
Use a small fixture set that exposes meaningful differences: a normal result, an unavailable slot, a long label and a delayed response. Name the simulation controls so a facilitator can reproduce each condition. Keep those controls separate from the participant-facing interface.
Test with people, not with your familiarity
Give participants a task rather than instructions about which controls to press. Observe their actions before asking for opinions. “Book a consultation next week” reveals more than “Click this time and then Confirm.”
A prototype can mislead when its shortcuts are invisible. Tell observers which behaviour is simulated. A successful task does not validate payment security, database permissions or real availability handling if those parts are fixtures. Record the limitation beside the finding, not in a forgotten technical note.
Developers should attend enough sessions to understand the interaction problem directly. Designers should inspect the simulated rules so they know what the test did and did not exercise. AI-generated polish can otherwise make both groups overestimate how much has been resolved.
Carry forward intent rather than a whole generated app
Figma documents a Make-to-MCP resource workflow that lets compatible clients retrieve code and other resources from Make files. The documentation requires file access and a client that supports MCP resources; availability should be checked for the actual environment.
The practical opportunity is selective reuse. Bring a relevant interaction into an existing component rather than importing a prototype wholesale. Compare its behaviour against the validated decision and the application's architecture. Review accessibility, dependencies, state handling and any assumptions about data before accepting generated code.
The prototype is evidence about an interaction. It is not an exemption from engineering review.
A focused prototype checklist
- State the uncertainty the prototype is meant to resolve.
- Include realistic failure and recovery conditions.
- Label fictional data and simulated service behaviour.
- Make test conditions repeatable without exposing facilitator controls.
- Observe actual participants and record contradictory findings.
- Transfer validated behaviour into reviewed production components.
Stop adding screens when the research question has been answered. A smaller prototype with an honest boundary often produces a clearer decision than an impressive product simulation that hides everything difficult.
Sources
Key takeaways
- Prototype a real uncertaintyChoose a behaviour or decision that needs testing before asking a tool to generate screens.
- Include failure and recoveryTest slow, empty, interrupted and unsuccessful states instead of evaluating only the ideal path.
- Carry forward verified intentUse the prototype to communicate decisions and constraints, then implement and validate them in the real product.