Catchpoint
2026
Reframing Product Design: Replacing Figma-First Workflows with Live, AI-Driven Code Prototyping
In this case study, I outline how I developed a strategic shift from a Figma‑first workflow to an AI‑first, code‑native design model—reframing how teams prototype, validate, and deliver UI. By analyzing the structural limitations of upstream design abstractions and contrasting them with the advantages of tools like Lovable, I demonstrated how designing directly in production‑grade code reduces translation cost, strengthens design system enforcement, and enables prototypes that behave like real software. This work established a clear path toward a single source of truth in code, accelerated iteration through live, data‑driven prototypes, and positioned AI‑native environments as the future foundation for high‑fidelity, scalable product development.
Overview
Creating a structure around storytelling
The Shift
AI‑first, code‑native tools like Lovable, Cursor and other AI Design Tools are changing where and how UI is best designed. Instead of designing abstractions that are later rebuilt in code, these tools allow teams to design directly in production‑grade code, using real components, tokens, data, and APIs from the start.
The Problem with the Current Model
Our Figma‑first workflow (including Figma Make):
Treats design as an upstream abstraction
Requires translation into real components and systems
Produces prototypes that approximate behavior rather than exercising it
Relies on process and discipline to maintain consistency
Even with AI assistance, this model creates friction, rework, and loss of intent.
Why AI‑First Tools Are Structurally Different
AI‑first tools like Lovable and Cursor:
Generate UI inside real projects and repositories
Use actual production components and tokens
Support real data, APIs, and AI‑driven behavior in prototypes
Treat prototypes as branches of the production codebase
This places prototypes under production governance by default and removes an entire translation layer.
Design Systems: Governance Where It Matters
In Figma, design systems are visual representations that must be mirrored and enforced manually in code.
In Lovable, design systems are first‑class, code‑native projects whose rules are applied programmatically during generation.
This shifts consistency from review and documentation to enforcement by the system itself.
Strategic Direction
We should intentionally move away from a Figma‑first workflow toward an AI‑first, code‑native design model, with Lovable (or a similar tool) as the primary environment for prototyping and early implementation.
Figma should be repositioned as a supporting tool for exploration and ideation—not the system of record for UI definition or handoff.
This shift:
Reduces translation cost
Improves prototype fidelity
Strengthens design system enforcement
Accelerates delivery
The Problem We Are Experiencing
Balancing personality with clarity
1. Design and Production Are Increasingly Decoupled
Today, our workflow still largely follows:
Design in Figma → Handoff → Rebuild in code
Even with Figma Make and MCP:
Design artifacts remain upstream abstractions
Generated code is rarely production-ready
Engineering still translates intent into real components and systems
This creates:
Rework and friction
Loss of design intent during implementation
Longer iteration cycles
2. AI Has Shifted Where UI Is Best Created
AI-first tools like Lovable allow teams to:
Generate real, running UI immediately
Iterate visually in code
Treat UI as a living system, not a static artifact
In these environments:
Layout, responsiveness, and behavior emerge directly from implementation
The feedback loop is faster and more concrete
The boundary between "prototype" and "product" is blurred
This makes frame-based, design-first tools less central than they once were.
3. Figma Make vs AI‑First Coding Tools: A Structural Difference
Figma Make is often positioned as Figma’s answer to AI‑first tools like Lovable. However, the difference between them is not feature‑level—it is architectural.
Figma Make is an AI feature inside a design tool.
Lovable is a design capability inside a code environment.
That distinction has real consequences.
Figma Make: Design‑Centric Code Generation
Make generates code from Figma artifacts (frames, components, variables)
Generated UI remains conceptually downstream of the design file
Components are references to Figma constructs, not production primitives
Iteration still flows: design → generate → adapt → integrate
As a result:
Code is rarely reused verbatim
Engineering must still reconcile generated output with real component APIs
Make works best for demos, scaffolds, or isolated surfaces—not sustained product development
AI‑First Tools (e.g., Lovable): Code‑Centric Design
UI is composed directly from real components and tokens
Prototypes are running applications
Design decisions are expressed as component composition, not visual approximation
Iteration happens in the same medium as production
This removes an entire translation layer rather than optimizing it.
4. Working Prototypes: Data, APIs, and Real Behavior
A critical distinction between AI-first tools and Figma Make is how close a prototype can get to real production behavior.
Lovable: Prototypes as Real Applications
In Lovable, prototypes can:
Connect to real databases (e.g., Supabase) for realistic, persistent data
Integrate directly with external APIs (e.g., OpenAI) to generate dynamic content
Respond to real user inputs, state changes, and async behaviors
As a result:
Prototypes behave like real software, not simulations
Design decisions can be validated against realistic data and edge cases
PMs and stakeholders evaluate actual flows, not approximations
This dramatically reduces the gap between "approved prototype" and "shippable experience."
Figma Make: Primarily UI-Level Fidelity
Figma Make excels at quickly generating UI and basic interactivity, but:
External database connections are limited or non-native
API integrations are not first-class or persistently managed
Dynamic behavior is typically mocked or simulated
This makes Figma Make best suited for:
Visual exploration
Static or lightly interactive demos
Early-stage concept validation
But it limits its usefulness for validating real product behavior.
5. Code Ownership, GitHub, and Production Flow
Another core difference is how prototypes live alongside production code.
Lovable: Prototypes as Branches of Reality
Lovable supports workflows where:
A real GitHub repository is connected
Prototype code can be edited both inside and outside Lovable
Changes remain synchronized
Prototypes can exist as branches that are reviewed, refined, and merged
This enables:
Clear ownership by Engineering
Standard code review and CI processes
A natural path from prototype → production
In this model, prototypes are not throwaway artifacts—they are early versions of the product itself.
Figma Make: Export-Based Code Handoff
With Figma Make:
Code typically lives inside Figma until exported
There is no native, bidirectional synchronization with GitHub
Versioning and review happen outside standard engineering workflows
As a result:
Code ownership is ambiguous
Iteration often forks between Make and the real codebase
Production readiness requires additional reconciliation work
This reinforces Figma Make’s role as a generator, not a production participant.
Decision Criteria
How to Evaluate the Right Model
If we optimize for the following outcomes, AI-first, code-native tools have a structural advantage over Figma Make:
Realistic validation → Prototypes must use real data, APIs, and behavior
Single source of truth → UI components and styles should not be mirrored
Low translation cost → Approved prototypes should not require rebuilds
Clear ownership → Code should live in GitHub with standard review and CI
Scalable consistency → Design systems should be enforced programmatically
If these outcomes are not priorities, a Figma-first workflow may remain sufficient. But if they are, the current model becomes a constraint rather than an enabler.
The Proposed Direction
AI-First, Code-Native Design
Prototypes and production should be built from the same components, tokens, and styles.
Instead of designing representations of the UI, we design with the UI itself.
What This Looks Like in Practice
1. Production UI System as the Source of Truth
In the proposed model, the design system lives in code first, not in a design file.
A shared, versioned UI system includes:
Design tokens (color, spacing, typography)
Core components (buttons, inputs, modals, tables)
Common patterns (forms, empty states, flows)
This system is consumed by:
Production applications
AI‑first prototyping tools (e.g., Lovable)
Why Keeping the Design System in Figma Is Limiting
When the design system is primarily authored and governed in Figma:
Components are representations of production components, not the components themselves
Drift is inevitable between visual spec and real behavior
New patterns must be re-implemented to be validated
AI tools are forced to interpret, not reuse
Even with MCP:
Figma remains a translation hub
The design system must be mirrored in code
Consistency relies on process, not enforcement
By contrast, AI-first tools like Lovable provide first-class design system support inside the code environment:
Design systems live as dedicated, reusable projects
Rules, components, and usage guidance are applied automatically during generation
Multiple design systems can be composed with deterministic priority when rules overlap
This shifts governance from documentation and review to programmatic enforcement, while still allowing flexibility where needed.
2. Lovable as the Primary Prototyping Environment
Lovable (or similar AI‑first tools) is not simply a faster way to mock UI—it changes what a prototype is.
Designers:
Compose screens using real, shared components
Operate within the same constraints as production
Style exclusively via tokens
Iterate on behavior, responsiveness, and hierarchy—not just appearance
Engineering:
Receives prototypes that already conform to production APIs
Reuses structure, not just ideas
Focuses effort on data, logic, and performance
Why This Is Different from Figma Make
With Figma Make:
Components used in Make are still mediated by Figma’s component model
Shared componentry is referential, not literal
Generated code must adapt to production libraries
With Lovable:
The prototype imports the same component package as production
There is no component translation step
“Handoff” becomes code review
3. Review and Collaboration Shift to Running Software
Instead of commenting on frames:
Teams review live previews
Iterate on behavior, not just appearance
Make decisions in context of real constraints
This preserves critique and collaboration while grounding it in reality.
Strategy
Why the Figma MCP Approach Is a Complication, Not a Strategy
The proposal to rely on the Figma MCP server is a logical extension of a Figma‑first worldview—but it also highlights its limitations.
MCP Solves Access, Not Authority
Figma MCP allows AI tools and developers to read structured design data from Figma. This improves extraction fidelity, but it does not change the underlying model:
Figma remains the upstream source of truth
Code is still downstream and derivative
Design systems still need to be mirrored and reconciled
MCP optimizes translation; it does not eliminate it.
MCP Adds a New Integration Layer
Adopting MCP introduces:
Another system dependency
Another failure mode
Another surface area for drift and mismatch
In practice, teams must now reason about:
What lives in Figma vs code
What is authoritative when conflicts arise
How changes propagate across systems
This increases cognitive and operational overhead without removing the core handoff boundary.
MCP Is Defensive, Not Foundational
MCP exists to keep Figma relevant in a world where UI increasingly originates in code and AI tools. It is a bridging mechanism, not a new foundation.
By contrast, AI‑first tools remove the need for a bridge entirely by making code the shared substrate for design, prototyping, and production.
Why This Matters Long‑Term
Relying on MCP:
Locks us into a dual‑authority model (Figma + Git)
Makes design system governance harder, not easier
Optimizes an architecture that is already being bypassed
Using AI‑first, code‑native tools:
Establishes a single source of truth
Reduces system complexity
Aligns with where AI‑assisted product development is heading
For these reasons, MCP should be viewed as a transitional mitigation for Figma‑centric teams—not a viable long‑term or even medium‑term strategy.
Why This Is Better for Each Discipline
For Design
Less throwaway work
Clear constraints that scale creativity
Direct influence on what actually ships
Stronger ownership of patterns and systems
For Engineering
Reduced reimplementation cost
Fewer interpretation errors
Faster path from approval to merge
For Product
Shorter iteration cycles
Earlier validation with real UI
Less gap between "what we saw" and "what shipped"
What This Does Not Mean
Designers become engineers
Exploration and early ideation disappear
Visual thinking is devalued
Figma (or similar tools) may still be used for:
Early exploration
Conceptual work
Moodboarding or broad ideation
But it is no longer the handoff artifact or system of record.
Recommendation
Moving towards an AI-first, Code-native model
We should intentionally move away from a Figma‑first workflow toward an AI‑first, code‑native model, with Lovable (or a similar tool) as the primary environment for both prototyping and early implementation.
Maintaining the design system and prototypes in code—rather than in design files—will:
Eliminate a persistent translation layer
Allow designers to work directly with production constraints
Enable higher‑fidelity validation using real data and APIs
Reduce rework and accelerate delivery
Figma should be repositioned as a supporting tool for exploration and ideation, not as the authoritative source of UI truth.
Version A: Neutral / Evaluative
We should evaluate a transition toward an AI-first, code-native design workflow, with Lovable (or a similar tool) used as the primary prototyping environment and a shared production UI system as the source of truth.
This evaluation should focus on:
Prototype-to-production reuse
Ability to validate real behavior (data, APIs, AI-driven interactions)
Design system consistency and enforcement
Designer and engineer experience
Figma would continue to play a role in early exploration and conceptual work, but would no longer be assumed to be the system of record for UI definition or handoff.
A time-boxed pilot would allow us to validate these assumptions before making a broader organizational change.
Version B: Strategic / Directional
We should intentionally move away from a Figma-first workflow toward an AI-first, code-native model, with Lovable (or a similar tool) as the primary environment for both prototyping and early implementation.
Maintaining the design system and prototypes in code—rather than in design files—will:
Eliminate a persistent translation layer
Allow designers to work directly with production constraints
Enable higher-fidelity validation using real data and APIs
Reduce rework and accelerate delivery
Figma should be repositioned as a supporting tool for exploration and ideation, not as the authoritative source of UI truth. This shift aligns our design practice with how modern products are increasingly built and iterated.
