Rapid Prototyping using Figma’s MCP Server and AI-assisted code generation

I might not be breaking any news here 😅

But here’s a workflow that consistently gets me from Figma frames to a test-ready interactive prototype with enough realism to support high-quality usability sessions, using MCP design context and AI.

**Figure 1:** End-to-end rapid prototyping pipeline.

Most writing about Figma’s MCP Server and agentic coding tools focuses on design-to-code for production: pixel-accurate components, engineering throughput, and codebase alignment.

In practice, the same setup is just as valuable for research prototyping. Especially when you need interactive behaviors and controlled test conditions that typical hotspot prototypes can’t emulate.

In this article, I’ll walk through my end-to-end workflow for translating Figma frames into runnable HTML/CSS/JS screens, integrating them into a cohesive flow, and adding a lightweight test harness for scenario control, deterministic states and edge-case flows.

Why this example?

The prototype used here comes from a real project where I needed to evaluate a mobile check-in workflow under realistic conditions, before the intended hardware was available.

You can find the detailed usability test requirements (screens, tasks, and outcomes/learnings) in the document.

The challenge

The check-in workflow includes interactions that matter a lot in testing:

Scan-to-autofill for fast guest registration
Tap-to-pay to process payments quickly
Error recovery (e.g., failed scan, missing required fields, declined payments)
Operational constraints (e.g., high occupancy impacting room selection)

This flow was designed for a mobile application intended to run on Android OS based portable POS devices , with an integrated card reader and barcode scanner. During design, we didn’t have access to the target devices, but the usability study still needed to reflect how the experience would feel in the field.

So instead of relying on a standard hotspot prototype, I chose to build a browser-executable prototype that emulates:

device-like interactions (scan, tap-to-pay, processing states),
repeatable “edge” conditions,
and facilitator-controlled scenarios.

**Figure 2:** Selected screens from the Check-In workflow used in this demonstration.

Why not just use a traditional Figma prototype?

Figma prototypes are excellent for validating information architecture and basic task flows. But for research sessions that depend on interactive realism, limitations show up quickly:

Hard to emulate camera/scanner behavior, timed transitions, and processing feedback loops.
Hard to enforce deterministic states
(e.g., “first card attempt declines, second succeeds”)
Hard to run scenario-based sessions without visibly exposing controls to participants.
Hard to version, diff, and iterate on behavior the way engineering teams do.

A lightweight HTML/CSS/JS prototype, by contrast, gives you:

browser-native APIs and deterministic logic,
fast iteration and review via Git,
and easy publishing (e.g., GitHub Pages) for distributed testing.

**Figure 3:** Stock reference images used to visualize the intended device context and key interactions, including scan-to-autofill and tap-to-pay.

Evolution of my approach

Before LLMs, my go-to method for high-fidelity clickable prototypes was:

convert frames into static screens using tools like Anima,
hand off annotated specs + interaction notes,
and partner with engineering to implement interactive behavior.

With AI-assisted code generation, I can now produce the same class of prototypes significantly faster, but only if the workflow is systematic.

That’s where Figma’s MCP Server changed the game: instead of prompting from screenshots alone, MCP lets agentic tools pull richer design context (layout, components, variables) directly from Figma into the coding workflow.

**Figure 4:** Evolution of my prototyping workflow over the time.

My workflow (end-to-end)

1. Set up the design for high-quality code generation

Even for research prototypes, the quality of the output is heavily influenced by the quality of the design inputs.

My checklist:

Use Auto Layout consistently (predictable structure and constraints)
Use a lightweight design system (consistent components + type styles)
Add Dev Mode annotations where interaction intent matters
(states, validation rules, edge cases)

This improves extraction quality because MCP can carry structured context into the prompt workflow, not just pixels.

**Figure 5:** Frame annotations in Figma Dev Mode capturing interaction intent, validation rules, states, and edge cases to improve agent output quality.

2. Implement screens frame-by-frame (static screen implementation)

I generate static screens one frame at a time to reduce drift and make QA faster. Each screen becomes a standalone, lightweight HTML file that’s easy to inspect, edit, and version-control.

The practical benefit of MCP here is that the agent can incorporate:

layout structure and constraints,
component/variable context,
and detailed design metadata,

This improves fidelity in the output and reduces guesswork compared to image-only prompting.

**Figure 6:** Example of implementing a single Figma frame as a standalone HTML/CSS screen using MCP-informed context (structure, typography, spacing, and assets).

Not every screen ships perfectly on the first pass. When I see small inconsistencies, I do a quick fidelity pass (spacing, alignment, typography, states). Doing this sequentially makes it easier to spot and correct issues before they propagate across screens.

**Figure 7:** Before/after of a quick fidelity pass correcting spacing, alignment, typography, and component states while keeping structure stable for integration.

3. Implement screens with “device-like” interactions separately

Certain screens shouldn’t be treated as simple static renderings because they depend on behavior:

The guest registration screen includes a scan-to-autofill flow that uses the browser camera and barcode detection logic to simulate scanning.
The card processing screen includes a time-based processing animation.

For these, I write a dedicated implementation prompt that includes:

the user story and expected interaction model,
states and edge cases,
constraints (“do not redesign UI”, “keep it client-side”),
and any technical references or notes that help the model converge.

This is one of the most important parts of making the prototype feel realistic in sessions: participants behave differently when the interface provides the same feedback loops as a real system (scan succeeds/fails, processing delays, decline states, etc.).

**Figure 8:** Guest registration screen implementing a scan-to-autofill simulation(GIF) to approximate device behavior in sessions.

4. Integrate the baseline flow (happy path)

Once the screens exist, the next step is prototype integration: making the experience behave like one product instead of a folder of pages.

I start with the baseline “happy path” because it:

sets the navigation skeleton,
establishes shared state,
and creates a stable surface to layer scenarios on top.

Practically, this means implementing:

client-side navigation (e.g., hash routing for static hosting),
shared state to carry data across screens (guest, stay details, booking summary),
and minimal event bindings for primary CTAs.

**Figure 9:** Integrated prototype walkthrough of the baseline journey (GIF): dashboard → registration → stay details → booking summary → payment → completion.

5. Add a lightweight test harness (deterministic states + scenario control)

This is the step that turns a prototype into something session-ready.

For usability testing, you want:

repeatable conditions (“every participant sees the same failure once”),
controlled constraints (e.g., high occupancy),
and facilitator controls that don’t prime participants.

In this prototype, the test harness includes:

scenario selection persisted across refresh/pages (local storage),
deterministic rules (e.g., forced scan fail vs success),
and a hidden trigger to open the scenario menu

**Figure 10:** Prompt used to implement client-side routing, shared state, event bindings, and deterministic transitions without redesigning the UI.

**Figure 11:** Prompt used to implement “Test Harness: Scenario control + deterministic states for usability testing,” without redesigning the UI.

How these prompts were authored

To compose prompts at this level of specificity, I started from a proven baseline: I shared an existing, engineer-built prototype (with real routing and interaction patterns) with the AI to generate an initial draft prompt that reflected production-grade structure and constraints.

From there, I iterated, tightening the language, removing ambiguity, and adding explicit acceptance criteria (“do-not-modify” boundaries for critical behaviors like scanning and processing animations).

The final prompts are therefore AI-assisted, but intentionally authored: grounded in real implementation patterns, then edited to match the exact usability testing requirements and the fidelity constraints of this prototype.

A consolidated document containing all prompts used in this workflow is available here.

**Figure 12:** Facilitator-only Scenario Menu and active-scenario indicator, enabling deterministic test conditions while keeping the participant-facing UI unchanged.

**Figure 13:** Scenario switching in action (GIF): selecting a test scenario and confirming persistence via the header indicator across the flow.

This is where AI-assisted coding is especially effective: once the baseline wiring exists, adding deterministic rules and scenario toggles becomes a structured integration task.

Up Next

Winix Filter Replacement Flow

Learn how a simple maintenance task became a trust problem.