From Figma to Client-Ready Prototype in 48 Hours. Then the Real Story Began.

There is a specific frustration that sits between a design concept and a client conversation about it.

The concept exists. The thinking has been done. The team knows what they want to show. But getting from that thinking to something the client can actually click, test, and react to — something that behaves like a real product rather than a static Figma frame — takes time. Days, sometimes weeks. By the time the prototype is ready, the context has shifted. The momentum of the initial conversation has dissipated.

What we tested on two active engagements was a different model. One where the prototype is not the output of a long production cycle. It is the starting point for the first real conversation.

Two Workflows, One Goal

The design team ran two parallel experiments, each starting from a different point and arriving at the same output: a deployed, interactive prototype the client could test the same week the engagement began.

1. Figma → Claude → deployed prototype.

Start with an existing Figma design. Feed it into Claude. Produce a deployed HTML prototype that faithfully renders the design intent — including responsive behaviour across breakpoints — without manual frontend development. The client sees the design as a live, navigable experience, not a linked frame.

2. Claude → Figma → deployed prototype.

Start in Claude with brief, context, and reference materials. Generate a structural direction. Export that direction to Figma for design refinement. Then produce the deployed prototype from the refined output. The workflow inverts the usual sequence — interactive exploration first, pixel-perfect refinement second.

Both workflows were tested on real, active client engagements — not internal sandboxes. The brief was the brief. The timeline was the actual engagement timeline. The prototype was what went to the client.

The output of one engagement: a deployed prototype supporting English, German, and full Arabic RTL. Language switching worked live in the demo. The client could toggle between languages in the room and experience the full multilingual behaviour before a single line of production code had been committed.

Timeline from design start to deployed prototype: 48 hours.

The client could switch between English, German, and Arabic in the room. We had not written a single line of production code.

What Speed Actually Enabled

The 48-hour figure matters, but not primarily because it is fast. It matters because of what it changes about the conversation.

When a prototype takes weeks, the client meeting happens before the prototype exists. The discussion is abstract — about direction, intent, principles. Feedback is speculative. The client is reacting to descriptions of an experience rather than the experience itself.

When a prototype takes 48 hours, the client meeting can happen with the prototype already in hand. The discussion is concrete. The client is reacting to actual navigation, actual responsive behaviour, actual language switching. Their feedback is more specific, more actionable, and — critically — more honest. People respond differently to something they can touch than to something they have to imagine.

On one engagement, this changed the structure of the initial client meeting entirely. Instead of a presentation about what might be built, it became a navigation session with what had already been explored. The client's questions shifted from "would you be able to..." to "what happens when...". The conversation moved faster and went deeper because there was something real to anchor it to.

The Moment That Changed How We Think About This

The speed outcome was expected. What we did not anticipate was what happened in the preparation for the client meeting.

Before the meeting, the prototype was shared internally for review. Without supplying any additional context about the client — no background brief, no account history, no project documentation — Claude was asked to audit the prototype against what was known about the client's current digital situation.

The output was not a generic UX review. It was a structured analysis specific to the client's actual challenge: a digital presence fragmented across multiple separate platforms, each with its own navigation system, design language, and account state. The audit identified what the prototype was getting structurally right — the consolidation logic, the taxonomy decisions, the unified navigation shell — and flagged the open questions that would need to be resolved in the next design phase.

It also produced a client conversation guide: which questions to ask in the meeting, which to avoid, how to frame the structural explorations without inviting feedback on placeholder aesthetics.

No context supplied. No brief attached. Claude audited the prototype against the client's known challenge and produced a meeting guide before we walked in.

That output — produced in the time between sharing the prototype and the meeting starting — would previously have required either a dedicated preparation session or the collective memory of whoever happened to be in the room. It is the kind of analysis that often does not happen at all, not because it is not valuable, but because there is no time.

With Claude as the always-on intelligence layer between sessions, there is time. Not because anyone worked longer. Because the preparation work ran in parallel rather than sequentially.

What This Changes for Design Delivery

The two workflows — Figma to Claude and Claude to Figma — are not the same as traditional design-to-build handoff. They sit earlier in the engagement, before the design has been finalised, before the build has been scoped, before the client has seen anything.

The value they create is not efficiency in production. It is compression of the loop between design intent and client reaction. That loop, in traditional engagements, spans weeks. In the model we tested, it spans days. And each time the loop closes faster, the subsequent iteration is more informed.

There is also something worth noting about what the human designer's role becomes in this model. The compressed timeline does not reduce the design thinking required — it concentrates it.

The decisions about information architecture, the judgment calls about what to show and what to defer, the read of what the client is actually trying to solve: these remain entirely human. What AI handles is the execution time between decision and testable output.

That is not a small shift. Execution time in design delivery is measured in days. When those days compress to hours, the number of iterations possible within an engagement timeline changes significantly. More iterations means more refined outcomes. More refined outcomes means a narrower gap between what was designed and what gets built.

Where This Goes Next

Both workflows are now being refined based on what the initial tests revealed. The question of when to start in Claude versus when to start in Figma is becoming more defined — there are project types that suit each approach, and the decision logic is getting clearer with each engagement.

What is already clear: the model of design delivery where the prototype arrives after the client meeting is not the only option. In engagements where speed-to-testable-output matters — which is most engagements — there is now a different approach available.

The prototype can be in the room. The intelligence layer can be working before anyone gets there.