Responsive SaaS UI: Implementing Complex Figma Layouts Across Breakpoints

SaaS Responsive Design Is Not Standard Responsive Design

When most developers think about responsive design, they think about marketing pages: stack columns on mobile, adjust font sizes, maybe hide a decorative image. This is well-understood territory with established patterns. SaaS applications are fundamentally different. The information density of a SaaS dashboard, the interactive complexity of a data table, and the navigational depth of a multi-section application create responsive challenges that standard techniques cannot solve.

A SaaS dashboard that simply stacks its panels vertically on tablet produces a page that requires endless scrolling to see information that was visible at a glance on desktop. A data table that hides columns on mobile loses the comparative context that makes the table useful. A sidebar navigation that collapses behind a hamburger on every breakpoint wastes screen space on tablets where there is room for a compact sidebar.

This article covers the responsive implementation strategies we use for SaaS products — specifically how we translate complex Figma layouts into production CSS and React code that works intelligently across every breakpoint.

Sidebar Navigation Patterns

SaaS applications almost universally use sidebar navigation. The sidebar provides persistent access to top-level sections, status indicators, and quick actions. Making this navigation responsive requires three distinct modes, not two.

Desktop (1280px+): Full sidebar with icons, labels, and section headers. Width typically 240-280px. This is the default state that your Figma design likely shows in full detail.

Tablet (768px-1279px): Collapsed sidebar showing only icons, with labels appearing as tooltips on hover. Width typically 64-72px. This mode preserves persistent navigation access while reclaiming horizontal space for content. Many SaaS products skip this mode and jump directly to mobile behaviour on tablets — this is a mistake that wastes usable screen space.

Mobile (below 768px): No persistent sidebar. Navigation moves to a bottom tab bar for primary sections (4-5 items maximum) and a slide-out drawer for secondary navigation. The bottom tab bar is reachable with the thumb, which matters for mobile usability.

Implementation requires a NavigationProvider context that tracks the current mode based on viewport width (via a ResizeObserver, not CSS media queries — because we need the mode value in JavaScript for conditional rendering, not just styling). The sidebar component renders different structures in each mode, not just different styles applied to the same structure.

Collapsible Panel Systems

SaaS dashboards frequently feature multi-panel layouts where several information panels share the viewport. An analytics dashboard might show a chart panel, a metrics summary panel, and a recent activity panel side by side. Making these responsive requires collapsible panel logic.

Our implementation uses a PanelGrid component that manages panel visibility based on available width. Each panel has a priority level. When the viewport narrows, lower-priority panels collapse into an "expand" button or a tabbed interface. The user can still access all panels — they just access lower-priority ones through a deliberate action rather than seeing them simultaneously.

The panel collapse order is defined in the component configuration, not in CSS. This is intentional — CSS media queries can show and hide elements, but they cannot implement the interactive expand/collapse behaviour that makes collapsed panels accessible. The logic lives in React state, driven by the PanelGrid's measured width.

For Figma implementation, the designer typically provides the full-width layout and one or two collapsed states. We work with the design team to define the collapse priority and the visual treatment of collapsed panels (tab bar, icon button row, or accordion), then implement the intermediate states that the designer may not have explicitly designed but that follow logically from their specifications.

Responsive Data Tables

Data tables are the hardest responsive challenge in SaaS applications. A ten-column table that works perfectly on a 1440px display becomes unusable on a 768px tablet and impossible on a 375px phone. There are three strategies, each appropriate for different situations.

Strategy 1: Horizontal Scroll with Sticky Columns

The table maintains its full columnar structure but scrolls horizontally. The first one or two columns (typically the identifier column and a status column) remain sticky so the user always knows which row they are looking at. A horizontal scroll indicator shows how much content extends beyond the viewport.

Best for: Tables where column-to-column comparison is the primary use case. Financial data, comparison matrices, and any table where users need to see the relationship between columns.

Strategy 2: Card-Based Transformation

Below a defined breakpoint, each table row transforms into a card. The card shows the most important fields with labels, and a "show more" interaction reveals the remaining fields. The card layout is defined separately from the table layout — it is not a CSS transformation of the table, but a completely different React render path.

Best for: Tables where each row represents an entity (a customer, an order, a ticket) and users typically want to see all details of one entity at a time rather than comparing across entities.

Strategy 3: Progressive Column Hiding

As the viewport narrows, columns are hidden in priority order. Hidden column data is accessible through a row expansion interaction. This is a middle ground between full scroll and full transformation — the table retains its tabular structure but shows fewer columns.

Best for: Tables where some columns are essential and others are supplementary. A task list where name and status are essential but assignee and due date are supplementary.

In the Figma-to-code process, the designer's mobile table design tells us which strategy to implement. If they have designed cards, we use Strategy 2. If they show a narrower table with a scroll indicator, we use Strategy 1. If the design is ambiguous, we discuss the use case with the product team and recommend the appropriate strategy.

Chart Resizing Strategy

Charts present a unique responsive challenge because their aspect ratio affects readability. A line chart that is 800px wide and 400px tall communicates trend information effectively. The same chart at 375px wide and 400px tall compresses the x-axis to the point where data points overlap and labels collide. Simply scaling the chart proportionally does not work — the chart needs to adapt its internal layout.

Our chart responsive strategy involves several adjustments triggered by container width:

• Axis label density: At narrower widths, we show fewer x-axis labels to prevent overlap. A chart showing twelve monthly labels on desktop might show every third month on tablet and every sixth on mobile.
• Legend repositioning: A legend displayed to the right of the chart on desktop moves below the chart on narrower viewports, reclaiming horizontal space for the data area.
• Tooltip behaviour: On desktop, tooltips follow the cursor. On touch devices, tooltips anchor to a fixed position (typically below the chart) and update when the user touches different data points, avoiding the problem of a tooltip being hidden by the user's finger.
• Aspect ratio adjustment: We define minimum width thresholds below which the chart switches to a taller aspect ratio, giving the data more vertical space as horizontal space decreases.
• Data point density: For scatter plots and time series with many data points, we implement responsive data sampling — showing every Nth data point at narrower widths while maintaining the overall shape of the data.

These adjustments are driven by the chart container's measured width using ResizeObserver, not by viewport breakpoints. This means a chart in a narrow sidebar panel behaves differently from the same chart in a full-width layout — which is correct behaviour.

CSS Grid for Dashboard Layouts

CSS Grid is the foundation of our responsive dashboard implementations. Named grid template areas make each responsive state explicit and readable. A dashboard layout might define four template areas on desktop (sidebar, header, main, aside), collapse to three on tablet (header, main, aside), and stack to two on mobile (header, main).

The key advantage of named template areas over flexbox-based layouts is clarity. Each responsive state is a complete layout definition, not a set of override rules. When debugging a responsive issue, you look at the template definition for that breakpoint and see exactly where every element is positioned. There is no cascade of flex-direction changes, order properties, and conditional wrapping to trace through.

For Figma implementation, we map the designer's responsive layouts directly to grid template definitions. Each Figma responsive frame becomes a named template in CSS. This 1:1 mapping makes it straightforward to verify that the implemented responsive behaviour matches the design specification.

If you are building a SaaS product with complex responsive requirements and want implementation that matches your Figma specifications precisely, book a free consultation. We will review your designs and provide a responsive implementation plan tailored to your product's specific layout challenges.