Workflow · 9 min read

How to Redesign a Legacy Website Without Starting From Scratch

Import the existing site into Figma, audit what's there, and redesign in phases. This is the playbook for agencies and product teams modernizing a live website without a full-rewrite bet.

HF

HTML to Figma Team

Last reviewed: March 2026

Direct Answer

Import the legacy site into Figma with html2design, audit the component inventory, then redesign iteratively — one component or page section at a time. This avoids the risk and cost of a full rebuild. You start with actual working Figma layers from the live site (not screenshots), identify design debt systematically, and ship improvements in phases while the existing site stays live throughout.

The "start from scratch" impulse is understandable. Legacy codebases are messy. The design is inconsistent. Nobody can find the source files. But full rebuilds routinely take 3–4× longer than estimated, delay feature work, and often end up with a new site that recreates the old site's problems in a shinier codebase. The iterative path is harder to propose but almost always smarter to execute.

Here's the workflow that makes it work.

Why Import First, Design Second

The traditional approach to a legacy redesign is to start with blank Figma frames and redesign pages from memory or from screenshots. This is slower and produces worse results than importing the existing site first, for two reasons.

First, you can't audit what you haven't captured. Designers making decisions about the new design system need to know what the old system actually contains — how many button variants exist, how many different card layouts are in use, what the actual font sizes are in production. Screenshots give you a visual impression. Figma layers from html2design give you exact measurements you can act on.

Second, the import gives you a working baseline to iterate from. Instead of redrawing a nav from scratch, you import it, see the exact layer structure, understand what CSS it's using, and redesign with full context. The first iteration of the redesigned nav is faster, and it's grounded in what actually exists.

Phase 1: Import the Existing Site into Figma

Phase 1 — Baseline capture

Import each major page type as a Figma frame

Spend one session importing the current site into Figma. You're not designing yet — you're creating a baseline that the entire redesign process will reference.

The import workflow using html2design:

  1. Build a page inventory first. List every distinct page template on the site — home, category, product/article, contact, checkout, error page, etc. For large sites, focus on the top 10 by traffic. You don't need every page — you need every type.
  2. Open each page in Chrome. Navigate to a representative instance of each page type.
  3. Import the full page. Right-click the <body> element in DevTools → Copy outerHTML → paste into html2design in Figma. For very large pages, import key sections separately (hero, nav, footer, content area).
  4. Organize in Figma. Create one Figma page per site template. Name each frame with the page type and date. Keep all baseline frames on a "Current State" page — do not delete them. They're your reference throughout the project.
  5. Import at multiple breakpoints. For responsive sites, import at desktop width and mobile width separately. Use html2design for both — resize the browser between captures.

For a full multi-page site import workflow, see Importing Multi-page Websites into Figma: Full Workflow.

Phase 2: Audit Existing Components

Phase 2 — Component audit

Inventory every component and identify design debt

With the site in Figma as editable layers, you can measure exactly what exists. This is where you find out why the site feels inconsistent.

Walk through the imported Figma frames and build a component inventory. For each component type, count how many variants exist and flag inconsistencies:

Component Variants Found Design Debt Redesign Priority
Buttons (primary) 6 3 different border-radius values, 2 font sizes High
Navigation 2 Mobile nav vs desktop nav use different spacing High
Cards 8 5 different padding values, 3 font size scales High
Forms / inputs 4 Inconsistent placeholder text styling, 2 border styles Medium
Tables 3 Headers use different weights across pages Medium
Footer 1 Outdated copyright year; otherwise consistent Low

The component audit serves two purposes: it gives you the data to build a new consolidated design system (how many components you're actually replacing), and it gives you a priority ranking for the redesign work.

Four Categories of Design Debt to Document

Typography fragmentation

More than 4–5 distinct font sizes used in production, inconsistent line-heights for body text, or multiple font families where one was intended. In Figma layers from html2design, you can select all text layers and see the actual computed font sizes — no guessing.

Color entropy

Dozens of near-identical hex values that should be the same color but drifted over time. In Figma, right-click any fill → "Select matching fills" to find all uses of a color. Import the site and do this for every brand color to see how many variants exist.

Spacing inconsistency

Padding and margin values that have no relationship to a spacing scale — 13px here, 17px there. This is almost universal in codebases that grew without a design system. The html2design import preserves computed spacing values in the Figma frame dimensions and padding, making it auditable.

Component fragmentation

The same UI pattern reimplemented differently across pages — three button components, two modal implementations, four card layouts that are logically the same component. The audit in Figma makes this visible and measurable.

Phase 3: Define the New Design System

Phase 3 — Design system definition

Establish tokens, typography scale, and spacing before redesigning a single component

The most common iterative redesign failure mode is starting to redesign components before defining the system they belong to. Every component should use tokens. Every token should be decided before the first component is drawn.

Decisions to make before opening a new Figma frame:

For teams using html2design to bridge code and design, the design tokens should match the CSS custom properties or Tailwind config in the production codebase. See Design Tokens: Bridging Code and Figma for the sync workflow.

Phase 4: Redesign Components Iteratively

Phase 4 — Component redesign

Redesign shared components first, page-specific sections last

The redesign sequence matters. Redesign global components before page-specific ones. Ship each component to production before moving to the next.

Recommended redesign sequence:

  1. Design tokens and global styles — update CSS variables or Tailwind config first. Every subsequent component change will inherit these automatically.
  2. Navigation — appears on every page. A nav redesign has maximum visible impact and validates the token system immediately.
  3. Footer — also global. Ship nav and footer together for cohesive first-impression improvement.
  4. Primary CTAs and buttons — consolidate to 2–3 variants maximum. Update all uses across the site.
  5. Form inputs — high-stakes for conversion. Consolidate variants and apply new spacing/typography tokens.
  6. Cards and content modules — redesign the consolidated version, then replace all variants across the site.
  7. Page-specific sections — hero sections, landing page layouts, etc. These come last because they depend on the shared components being stable.

For each component: import the current version from production using html2design → redesign against the new design system in Figma → hand off the Figma frame to development → ship → mark the old variants as deprecated.

Phase 5: Validate and Ship Iteratively

Each phase of the redesign should ship to production independently. Do not hold everything back for a "big reveal" launch. Iterative shipping:

Using Figma for Before/After Comparisons

The imported baseline frames you created in Phase 1 become invaluable for stakeholder reviews and handoff documentation. Create a "Before / After" Figma page with the original imported frames beside the redesigned frames. This gives stakeholders a direct visual comparison without needing access to the old production site, and gives developers a clear reference for what they're replacing.

For teams running A/B tests during the redesign rollout, the Figma baseline frames can also serve as the visual specification for the control variant, and the redesign frames as the treatment variant.

When a Full Rebuild Is Actually the Right Call

Iterative redesign is not always the right answer. A full rebuild is justified when:

Even in these cases, importing the legacy site into Figma first is still worthwhile. It gives the new site team a documented audit of what existed, prevents the "we forgot that feature" problem, and provides before/after documentation for stakeholders.

Key Takeaways

  • Import before you design — html2design converts your legacy site into editable Figma layers. Use these as the baseline for your entire redesign process.
  • Audit with data, not impressions — Figma layers show you exact computed values. Count component variants, identify typography fragmentation, and measure spacing inconsistency before redesigning anything.
  • Define tokens before components — every design decision in the redesign should reference a token. Components built without tokens become the next generation of design debt.
  • Redesign shared components first — nav, footer, buttons, and form inputs appear everywhere. Fixing them has the highest ROI and validates your token system before you commit to page-specific work.
  • Ship iteratively — do not hold back the redesign for a simultaneous launch. Ship each component to production as it's completed.
  • Keep the baseline frames — your Phase 1 imports are reference material throughout the project. Don't delete them.

Related Guides