[Case Study] From Figma-First to Code-First: A Four-Month Transformation
How we moved designers from design files to production code, and what it revealed about the future of product disciplines.
Last year, I proposed moving our UX designers out of Figma. It was too drastic for many. Many managers said designers need Figma skills. They are not wrong. This approach is not suitable for every organization. Today, our designers are still in Figma; however, they are using it for a very different purpose.
This is my case study.
Four months, 40-person organization, four steps. Moving from a design-only tool to vibe-coded prototypes, pushing merge requests, and shipping directly to production.
The Old Workflow
Like most design teams:
Design in Figma
Create prototypes (in Figma)
Handoff to engineering
Engineering implements
Design reviews implementation
Figma was the “source of truth.” Design system lived in both Figma and code. Constant drift between them.
The New Workflow
Wireframe (tool-agnostic: Figma, Miro, Mermaid diagrams)
Clone the design system repo
Vibe code using design system components (prototype or UI fix)
Push merge request
Engineering review, refine, produce ships
Key difference: The design system exists only in code. Code is the source of truth because it’s the originator.
Why This Workflow Might Work for Your Organization (And When It Won't)
Our context matters:
B2B product: Experience exploration, not heavy visual design
Design engineers on staff: Team members with both design and design engineering who can contribute code to the design system
Strong collaboration culture: Design and engineering already worked closely
AI timing: Code assistance made this practical at scale
This won't work if your organization has:
Products that require heavy visual exploration
No code-based design system foundation
No AI infrastructure for the business
Organizational culture is resistant to workflow experimentation
If those conditions aren't met, Figma-first might still be your best bet.
What Actually Ships to Production
Important clarification: Most vibe-coded prototypes don’t go directly into production. If the experience is good (signed off) and the code is good (reviewed), it can be merged into production (like those papercuts). However, many prototypes stay as prototypes. Conversation starters. Engineering takes the prototype, refactors it for production standards, and implements it properly.
Why this works:
Designers get fast feedback on experience
Engineers get working code to inspect instead of static mocks
The prototype already calls real design system components
Engineers can see intended behavior, not just static states
It’s not about designers replacing engineers. It’s about better collaboration through working code.
But if you’re ready to explore this shift, here’s the blueprint.
Four Months, Four Phases:
Month 1: Remove fear (vibe code training)
Month 2: Production onboarding (dev environment)
Months 2-3: Build confidence (internal tools)
Month 4: Practice (quick-win, papercut fixes)
