How to Redesign a Website in Figma

Knowing how to redesign a website in Figma is now a standard expectation for UI/UX designers.

Figma has become the default design environment for almost every professional web redesign project, replacing older tools with a collaborative, component-based workflow that suits how modern product teams work.

This guide covers the complete Figma redesign process: project setup, wireframing, design system creation, high-fidelity page design, stakeholder review, and developer handoff. Each stage builds on the one before it.

Key Takeaways

• Figma is for design, not development: Figma produces design specifications and prototypes that must be built in a CMS, page builder, or custom code environment separately.
• Component systems save significant time: Setting up a design system with components and variables before building pages is the investment that makes the entire project manageable.
• Auto Layout is essential: Figma's Auto Layout feature enables responsive component behavior that accurately represents how the design will adapt across screen sizes.
• Stakeholder review in Figma reduces rework: Using Figma's prototype and commenting features for stakeholder feedback prevents expensive development changes later in the project.
• Handoff quality determines build accuracy: The quality of Dev Mode annotations and component documentation in Figma directly determines how accurately developers implement the design.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

Setting Up Your Figma Project for a Website Redesign

A well-structured Figma project prevents confusion during client review and keeps the team aligned on which files contain the authoritative design.

The Figma in the full redesign context matters here: Figma is one stage in a larger process, and how you set it up affects every stage that follows.

Project structure is not cosmetic. A disorganized Figma file produces misaligned feedback, version confusion, and handoff errors that cost more time than the organization would have taken.

Project and File Organization

Organize the Figma workspace with separate pages for research and moodboard, design system, wireframes, high-fidelity pages, and prototype flows. Clear page naming prevents the confusion that emerges during extended client review cycles.

• Separate pages per stage: Research, Design System, Wireframes, High-Fidelity, and Prototype are the standard pages for a professional redesign project file.
• Naming conventions: Use consistent frame naming from the start. Frames named "Homepage Desktop," "Homepage Tablet," and "Homepage Mobile" are far easier to navigate than "Frame 47."
• Version management: Use Figma's version history rather than duplicating files. Keep one authoritative source of truth per design stage.

Communicate the file structure to every team member at project kickoff. A five-minute walkthrough prevents hours of "where is the latest version?" messages.

Setting Up Frames With Correct Breakpoints

Set up standard device frames before any design work begins. Desktop at 1440px wide, laptop at 1280px, tablet at 768px, and mobile at 375px are the standard breakpoints for a professional web redesign.

• Desktop first for marketing sites: For most marketing and business sites, desktop is the primary design frame. Mobile-first applies to conversion-heavy pages where mobile traffic dominates.
• Frame sizing matters: Designing at incorrect dimensions produces a handoff where developers must reinterpret proportions rather than implement them directly.
• Grid systems: Set up columns grids at each breakpoint before designing. A 12-column grid at desktop, 8-column at tablet, and 4-column at mobile is a reliable standard.

Connecting to a Brand or Creating a New Design System

Start by importing an existing brand style guide to create Figma variables and styles, or establish a new design system from scratch with colors, typography, spacing, and elevation tokens. This decision determines how consistent the design will be.

• Existing brand import: If the client has a brand guide, extract all hex colors, typefaces, and spacing values and create Figma Variables and Styles before building any components.
• New design system: Without an existing brand guide, establish the color palette, type scale, spacing system, and elevation system as the first task, before any page design begins.
• Token naming: Name variables descriptively: "color/primary/default," "spacing/section/large." This naming structure makes Dev Mode handoff significantly cleaner.

Step 1: Wireframing Before You Design

Website wireframes before design prevent the most expensive type of rework: structural changes to a completed high-fidelity design. Wireframing validates information architecture and navigation before any visual design investment is made.

The most common cause of wasted design hours is committing to visual direction before the structure has been validated. Wireframes solve this problem cheaply.

Low-Fidelity Wireframing for Information Architecture Validation

Low-fidelity grayscale wireframes in Figma focus on content hierarchy, navigation, and conversion flow. No colors, no typography, no imagery. Just layout and content placement.

• Wireframe components: Build a small library of placeholder components: text blocks, image placeholders, button shapes, and navigation bars. Reuse these across all wireframe frames.
• Content hierarchy first: Every wireframe decision should reflect the content hierarchy established in the discovery phase, not aesthetic preferences.
• Navigation patterns: Wireframe the global navigation, mobile navigation, and secondary navigation patterns before any other page elements.

Completing wireframes before high-fidelity design typically reduces structural revisions in the design phase by 60 to 70 percent.

Mid-Fidelity Wireframes for Stakeholder Alignment

Mid-fidelity wireframes incorporate real content and approximate layouts. They are the right tool for stakeholder review before committing to full visual design.

• Real content, approximate layout: Replace placeholder text with actual page copy and actual image dimensions. Keep grayscale styling but use accurate proportions.
• Stakeholder review at this stage: Present mid-fidelity wireframes to stakeholders before any high-fidelity design work. Changes at this stage cost one hour; the same changes after high-fidelity design cost one day.
• Review focus: Direct stakeholder feedback toward content and structure, not visual style. "Is the right information visible?" is the right question at this stage.

Validating Wireframes With User Testing

Figma prototypes built from mid-fidelity wireframes can be used for lightweight usability testing before high-fidelity design begins.

• Maze and UsabilityHub: Both tools connect directly to Figma prototypes and run unmoderated usability tests with recruited participants in 24 to 48 hours.
• Task-based testing: Define three to five key tasks before testing. "Find the pricing page" or "Submit a contact form" are more useful test tasks than "explore the site."
• Act on findings: User testing findings that reveal navigation issues or missing content should be resolved in the wireframe before high-fidelity design proceeds.

Step 2: Building a Design System in Figma

The design system is the foundational investment that determines whether the rest of the project is efficient or painful. The UX redesign process in Figma consistently identifies design system quality as the most important variable in project efficiency.

A design system built before page design begins means every page benefits from consistent components. A design system built after page design begins means components must be retrofitted, which is slower and less consistent.

Creating Color and Typography Variables

Set up Figma Variables for brand colors and typography tokens before building any components. Variables enable global design updates with a single change.

• Color variable structure: Primitive colors (exact hex values), semantic colors (primary/secondary/success/error), and component-level colors (button/background/border) as three distinct layers.
• Typography tokens: Create styles for every text role: H1 through H4, body large, body regular, caption, and label. Include line height and letter spacing in each style definition.
• Variable scoping: In Figma Variables, scope each variable to the modes it applies to. This enables light/dark mode switching if the project requires it.

Building Reusable Components

Build components for every repeated UI element: navigation, buttons, cards, form fields, testimonials, and footer. Use variants to handle different states within each component.

• Variants for states: Every interactive component needs variants for default, hover, active, focused, and disabled states. Build these before any page design begins.
• Atomic structure: Build atomic components first (buttons, inputs, icons), then molecular components (form groups, navigation items), then organisms (full navigation bar, hero section, card grid).
• Component documentation: Add component usage notes in the description field of each component. This documentation becomes part of the Dev Mode handoff.

Using Auto Layout for Responsive Components

Auto Layout makes components resize and reflow correctly across breakpoints. Every component in a professional Figma design system uses Auto Layout.

• Direction and spacing: Set Auto Layout direction (horizontal or vertical), gap between items, and padding values rather than using fixed pixel positions for element placement.
• Hug vs fill: Child items that should resize with content use "Hug contents." Items that should fill available width use "Fill container." Understanding this distinction is the foundation of responsive Auto Layout.
• Breakpoint variants: For components that change significantly between desktop and mobile, create separate component variants for each breakpoint rather than trying to make one component adapt across all sizes.

Step 3: Designing the High-Fidelity Pages

UX principles for website redesign guide every decision in the high-fidelity design phase. Visual hierarchy, prominent calls to action, progressive disclosure, and trust signals at decision points are the principles that differentiate a designed site from a built one.

High-fidelity page design with a complete design system in place is significantly faster than designing without one. Components drop into place; the designer focuses on layout and content decisions.

Page Design Order and Prioritization

Design pages in priority order: homepage first as the visual direction setter, then key conversion pages, then supporting pages. This sequence matches business goals with design investment.

• Homepage as visual reference: The homepage design establishes color, typography, imagery style, and layout rhythm for every subsequent page. Get it approved before designing other pages.
• Conversion pages second: Service pages, product pages, pricing pages, and landing pages drive business outcomes. They deserve the same design investment as the homepage.
• Supporting pages last: About, team, blog, and contact pages follow the established design system and require less design time than primary conversion pages.

Applying UX Principles to Each Page Design

Apply clear visual hierarchy, prominent CTAs, progressive disclosure, and trust signals at every decision point on every page.

These principles are not optional extras; they are the difference between a page that converts and one that does not.

• Visual hierarchy: Every page should have one clear primary action. Multiple competing CTAs of equal visual weight produce lower conversion rates than a single dominant action.
• Progressive disclosure: Present the most critical information first. Use accordions, tabs, and expandable sections to make supporting detail available without creating overwhelming pages.
• Trust signals: Testimonials, client logos, certifications, and case study references should appear at the points in the page where a visitor is most likely to hesitate.

Designing All Required Breakpoints

The responsive design process requires designing desktop, tablet, and mobile breakpoints for every key page. Document where content reorders or collapses between breakpoints.

• Desktop to tablet: Identify which columns collapse, which components stack, and which navigation patterns change when moving from desktop to tablet layout.
• Tablet to mobile: Mobile layout requires particular attention to touch targets, form input sizing, and content prioritization for smaller screens with vertical scrolling.
• Breakpoint documentation: Create a breakpoint documentation frame in the Figma file that shows the key layout differences between desktop, tablet, and mobile for each template type.

Step 4: Client Review and Iteration in Figma

Structured review cycles in Figma prevent the unlimited iteration that erodes project margins and delays launches. Managing review within Figma keeps all feedback attached to design decisions.

The review process in Figma is most effective when stakeholders understand what they are being asked to review and what types of feedback are in scope at each round.

Sharing Prototypes for Review

Set up a clickable Figma prototype for each key user journey and share it via a link.

Prototype flows that replicate the actual user experience are significantly more effective for stakeholder review than presenting static frames.

• User journey flows: Build separate prototype flows for: prospective customer journey, contact form submission, and any e-commerce or booking flows the site requires.
• Prototype settings: Set the correct device type, background color, and starting frame before sharing the prototype link to ensure stakeholders see it in the intended context.
• Review instructions: Include a short written brief with every prototype share: what is being reviewed, what is not yet complete, and what types of feedback are most useful at this stage.

Managing Feedback With Comments

Use Figma's commenting feature to attach feedback directly to design elements. Resolve comments as changes are made to maintain a clean, auditable change record.

• Comment tagging: Tag specific team members in comments that require a decision rather than a design change. Decisions should not be left as unresolved comments.
• Comment categories: Ask reviewers to label their comments: "Required change," "Nice to have," or "Question." This prevents every comment being treated with equal urgency.
• Resolution discipline: Mark comments as resolved immediately after the change is made. Unresolved comments from round one appearing in round two reviews create confusion and scope creep.

Structuring Review Rounds to Prevent Endless Iteration

Structure design review into defined rounds with explicit scope: two rounds of major revisions and one round of final polish. Document this in the project contract before work begins.

• Round one scope: Structural and layout changes only. Content, color, and copy changes are deferred to round two.
• Round two scope: Content, copy, and visual refinements based on round one structural approval.
• Final polish: Minor adjustments only. New structural requests at this stage are change orders, not scope.

If you do not have a Figma-specialist designer in-house, it is worth taking time to hire a UX designer for redesign who can manage the review process as well as the design itself.

Step 5: Handing Off the Figma Design to Developers

Combining Figma with redesign tools at the handoff stage means understanding what supplementary tools developers need alongside the Figma file itself. Dev Mode, exported assets, and interaction documentation together form a complete handoff package.

The quality of the developer handoff determines how accurately the build matches the design.

A poor handoff produces a site that requires design review again after build, which costs more time than a thorough handoff would have.

Using Figma Dev Mode for Specifications

Figma Dev Mode provides developers with exact measurements, CSS properties, asset exports, and component documentation. All components must be finalized before Dev Mode handoff begins.

• Component finalization: Every component must be using Auto Layout, Variables, and proper naming before the handoff. Components that are not finalized produce incorrect CSS output in Dev Mode.
• Measurement annotations: Add annotations to any spacing or sizing relationships that Dev Mode does not communicate clearly, particularly for custom interactive components.
• CSS output review: Ask the developer to review the CSS output from Dev Mode on three or four components before the full handoff. This identifies any component structure issues while they are still cheap to fix.

Annotating Interactive States and Animations

Hover states, micro-animations, and interaction behaviors do not appear in a static design file. Document them explicitly in a separate interactions documentation page in the Figma file.

• State documentation: For every interactive component, document the default, hover, active, focused, and disabled states with transition type and duration.
• Animation specifications: Document easing functions, duration, and trigger conditions for any page transitions, scroll animations, or micro-interactions in the design.
• Interactive component flows: Create short prototype flows that demonstrate each interaction pattern. Link to these flows from the component documentation page.

Exporting Assets for Development

Export SVGs, PNGs, and icon sets from Figma in the correct formats and naming conventions that development teams can use directly without reformatting.

• SVG for icons and logos: All icons and logos should be exported as SVG. Verify that SVG export settings are set to remove unnecessary Figma metadata before export.
• PNG for complex images: Images that do not export cleanly as SVG should be exported at 2x PNG resolution and compressed before delivery to the development team.
• Naming conventions: Establish file naming conventions before export: "icon-arrow-right.svg," "hero-homepage.png." Consistent naming prevents confusion in the development asset library.

Conclusion

Figma is the most capable design environment available for website redesigns, but its full value is only realized when the design system, prototype, and handoff are built with the development team's needs in mind.

A well-structured Figma project produces a design that developers can implement accurately and stakeholders can review confidently.

Set up a new Figma file this week with the correct breakpoint frames and create your first color variable set.

Even 30 minutes of system setup at the start will save hours on the first high-fidelity page. The investment compounds across every page that follows.

Webflow Development Services

Webflow Experts On-Demand

Whether you're starting fresh or need a full revamp—we create fast, modern Webflow sites built for growth.

Let's talk

LOW/CODE Agency Designs in Figma and Builds to Pixel-Perfect Accuracy

A Figma file that never becomes a built website is a document, not a product.

LOW/CODE Agency closes the gap between design and delivery with a process that starts in Figma and ends with a launched, performing website.

LOW/CODE Agency is a strategic product team, not a dev shop.

Our Figma-first process covers design system creation, high-fidelity page design, prototype review with structured sign-off, and accurate development handoff built on Dev Mode and developer documentation.

• Design system creation: Full Figma design system with Variables, component library, and Auto Layout standards before any page design begins.
• Wireframe and UX strategy: Low and mid-fidelity wireframing with user journey validation before visual design investment is committed.
• High-fidelity page design: Conversion-focused page designs at all required breakpoints, built on the approved design system for visual consistency.
• Prototype and stakeholder review: Clickable prototype review with structured rounds and documented sign-off to prevent scope creep and unlimited revision cycles.
• Developer handoff documentation: Dev Mode annotations, interaction specifications, and exported asset libraries that enable accurate implementation without interpretation.
• Build and development: From Figma to live website via Webflow, WordPress, or custom development, with pixel-accurate implementation of every approved design decision.
• Post-launch performance review: Core Web Vitals, conversion analytics, and design QA in the 90 days after launch to confirm the design is performing as intended.

LOW/CODE Agency has delivered over 350 digital products for clients including Coca-Cola, American Express, Sotheby's, Medtronic, Zapier, and Dataiku. When you are ready to take a Figma-designed website redesign from file to launched product, Start with a scoping call.