The core distinction: Design-to-code starts in Figma and ends in a codebase — designers create the design, developers implement it. Code-to-design starts in the codebase and ends in Figma — existing HTML and CSS are imported as editable design layers. Both directions are legitimate workflows. Choosing the wrong one for your situation wastes weeks of effort.
Why the Direction Matters
When teams talk about "design and development workflow," they almost always mean design-to-code: Figma → handoff → code. This is the default mental model, and it's the one most tooling is built around.
But it's the wrong model for a large class of real-world situations. If your product already exists — if there's a live codebase producing a working UI — then the gap isn't between design and code. The gap is between the code that exists and the design files that don't. The right direction to fix that gap is code-to-design, not design-to-code.
Choosing the wrong direction is expensive. Teams that try to use design-to-code tools on products that need code-to-design end up with designers rebuilding UI from scratch in Figma, spending weeks recreating what already works in production. Teams that run both directions simultaneously without intentional process end up with two sources of truth and no clear authority.
Design-to-Code: When Figma Is the Source of Truth
Flow: Figma design → Dev Mode / handoff → code implementation
Design-to-code is the right workflow when designers create designs before any code is written — or when a team has committed to Figma as the authoritative source of truth for all UI decisions. The design file is the blueprint; the code is the implementation.
Tools in the design-to-code stack
- Figma Dev Mode — Developers inspect designs, extract CSS values, spacing, and assets from Figma files
- Figma Code Connect — Links Figma components to actual code components for handoff
- Anima, Locofy, Builder.io — Generate code directly from Figma designs (varying quality and fidelity)
- Zeplin, Avocode — Design-spec handoff tools that output annotations and measurements
When design-to-code works best
- Greenfield products — No existing codebase, building from scratch with design driving decisions
- Teams with dedicated designers — Full-time design function that creates specs before engineering begins
- Design system teams — Where the Figma library is the canonical design specification and all new components flow from it
- Agency and consulting work — Where a client approves designs before development begins and changes are managed through the design layer
Where design-to-code breaks down
Design-to-code struggles whenever code gets ahead of Figma — which happens constantly in practice:
- A developer fixes a visual bug directly in code without updating the Figma file
- An engineer builds a component in a sprint without a designer spec
- The product moves fast and design files go stale within days of shipping
- There are legacy sections of the product that predate any Figma files
In all these cases, Figma is no longer the source of truth — the code is. Trying to run design-to-code workflows in this environment means designers are constantly playing catch-up, reimplementing what already exists, or making decisions based on outdated specs.
Code-to-Design: When Code Is the Source of Truth
Flow: Existing HTML/CSS → html2design → editable Figma layers
Code-to-design is the workflow for situations where the UI exists in code but not in a design file — and where the codebase, not Figma, reflects the actual current state of the product.
Instead of rebuilding the UI in Figma from screenshots or memory, html2design imports the rendered HTML and CSS directly into Figma as native, editable layers. The result is an accurate, editable design document that reflects what's actually in production — not a designer's reconstruction of it.
The code-to-design workflow with html2design
- Open your browser to the page, component, or section you want to import. This works with live sites, localhost, Storybook, staging environments, or any page accessible via DevTools — including auth-gated dashboards.
- Select the element in DevTools and copy the outerHTML. For full pages, copy the
<body>element's outerHTML. - Paste into html2design in Figma. The plugin parses the HTML and CSS and generates native Figma frames, text nodes, fills, borders, and shapes.
- Edit in Figma — rename layers, extract design tokens to Variables and Styles, build components, or use the import as a redesign baseline.
When code-to-design is the right choice
- Legacy products — UI built years ago, no Figma files exist, and the product needs a redesign or documentation
- Design debt sprints — Team needs to align Figma with what's actually shipped across multiple sprints of direct code changes
- Component library documentation — Engineers built a component library without design files; import the components to create a Figma library
- Redesign kickoff — Before redesigning any page, import the current state as the baseline — saves hours of reconstruction
- Reverse-engineering shipped UI — An acquisition, an inherited codebase, or a period of fast engineering iteration has left Figma completely out of sync
- Agency audits — Document a client's live site before proposing a redesign, without rebuilding every component manually
Key advantage: html2design works with any source you can open in a browser — localhost, staging, and auth-gated pages that screenshot tools can't reach. There's no Chrome extension required; the workflow is: DevTools → copy outerHTML → paste into the plugin.
The Drift Problem: Why Both Directions Are Needed
Most teams start with design-to-code — Figma leads, code follows. But after months of shipping, the gap grows:
- Developers fix visual bugs directly in CSS without a designer spec
- Copy changes happen in the CMS or codebase without touching Figma
- Performance optimizations change layout details that aren't reflected in the design file
- New components are added in a fast sprint, Figma file update deferred
This accumulation is called design drift: the gap between what the design file says and what production renders. Over time, design drift makes the Figma file increasingly unreliable as a reference — and teams either ignore Figma entirely or spend cycles maintaining it manually.
The solution isn't to pick one direction. It's to run both on a planned cadence:
- New feature work → design-to-code: Figma spec → Dev Mode → engineer implements
- Post-sprint sync → code-to-design: html2design imports what shipped → Figma file updated to match production
This bidirectional approach keeps Figma accurate as a living document — not a historical artifact.
Choosing the Right Direction: A Decision Framework
Use these questions to identify which direction (or combination) your team needs:
Does a Figma file exist for the UI you're working on?
- Yes, and it's current → design-to-code is working. Use Dev Mode for handoff.
- Yes, but it's stale → run code-to-design to resync Figma, then resume design-to-code going forward.
- No → code-to-design is the only viable direction. Import from the codebase.
Where is the source of truth for your UI decisions?
- Figma → design-to-code. Protect this state by enforcing that all UI changes go through the design file.
- The codebase → code-to-design. Import into Figma, establish it as a design reference, then decide whether to flip to Figma-first going forward.
- Neither — it's ambiguous → run a code-to-design audit first to establish a verified baseline, then choose a governance model.
Is your product greenfield or does it have existing UI?
- Greenfield → design-to-code. Design before building.
- Existing product, new feature → typically design-to-code for the new feature, code-to-design to document surrounding context.
- Existing product, no design files → start with code-to-design to establish the full baseline before any design work begins.
Tools for Each Direction
Design-to-code tools
- Figma Dev Mode — Best for extracting CSS values, spacing, and assets from Figma files for developer handoff
- Figma Code Connect — Links Figma components to production code components
- Anima — Generates React/HTML code from Figma designs (with varying fidelity)
- Builder.io / Locofy — AI-powered Figma-to-code generation
Code-to-design tools
- html2design — The primary code-to-design tool. Converts any HTML/CSS into native Figma layers. Works with all frameworks, localhost, staging, and auth-gated pages.
There are very few tools that do code-to-design well — most of the tooling ecosystem is oriented toward design-to-code. This asymmetry is why code-to-design workflows remain underused even when they're the right choice.
The Combined Workflow for Mature Teams
Teams that manage design at scale typically run a bidirectional loop:
- Sprint planning: Designers create specs in Figma for planned features. Dev Mode used for handoff to engineering.
- Sprint execution: Engineers implement from spec. Occasional direct fixes go to code without a design update.
- Sprint close: Use html2design to import the production state of changed components. Compare against the Figma file. Update the Figma file to match where they diverge.
- Repeat: Figma stays accurate. The design team has a reliable reference. Engineers trust the design system.
Practical cadence: Many teams find that running the code-to-design resync once per sprint is sufficient to keep design drift under control. For teams shipping multiple times per day, a weekly sync works well. The key is making it a scheduled process — not an ad-hoc catch-up after drift has already compounded.
Frequently Asked Questions
Is code-to-design only for legacy products?
No. Code-to-design is valuable any time code and design diverge — which happens regularly in fast-moving products, regardless of age. Even teams with strong design-to-code practices use html2design after sprints where direct code fixes accumulated.
Does running code-to-design mean giving up on Figma as a source of truth?
Not at all. Code-to-design is used to restore Figma as a source of truth after code has moved ahead of it. Once the Figma file is accurate again, the team can resume design-to-code governance — with the resync process as a safety net.
Can html2design handle dynamic and interactive UI?
html2design imports the rendered HTML at a specific state — you choose which state to capture (hover, active, loading) by triggering it in the browser before copying the outerHTML. For components with multiple states, import each state separately and organize them as component variants in Figma.
What's the fastest way to tell which direction my team needs?
Open your production website. Compare it with your Figma file. If they match closely — design-to-code is working. If there are visible differences — run code-to-design first to restore accuracy, then decide on a governance model.
Key Takeaways
- ✓ Design-to-code (Figma → Dev Mode → code) works when Figma is the source of truth and design leads development.
- ✓ Code-to-design (HTML → html2design → Figma) works when the codebase holds UI that doesn't exist in a design file.
- ✓ Design drift is inevitable without a code-to-design resync process — most teams underestimate how fast Figma goes stale.
- ✓ Mature teams run both directions: design-to-code for new features, code-to-design to resync after every sprint.
Related Articles
Figma Dev Mode vs html2design: When to Use Which →
The two tools that represent each direction — side-by-side breakdown with a feature comparison table.
Design Handoff Best Practices: Keeping Code and Figma in Sync →
The per-sprint sync cadence, token strategy, and annotation practices that prevent design drift from compounding.
Figma AI in 2026: What It Does, What It Doesn't, and Where html2design Fits →
Figma AI works within the design-to-code direction. Here's what it can and cannot do — and where html2design fills the gap.
Design System Migration: From Code to Figma Components →
The full code-to-design playbook for teams building a Figma design system from an existing component library.
AI-Powered Web Design Workflows: How html2design Fits In →
Where AI code generators stop and design tools start — and how html2design bridges the two directions.
Start the code-to-design workflow
Import your first UI from code in 30 seconds
Copy outerHTML from DevTools. Paste into html2design. Get editable Figma layers — the fastest way to close the gap between code and design.
Install from Figma Community →$12/mo · $96/yr · Cancel anytime