By Mehdi HassanWhat makes a responsive design handoff work?
A responsive design handoff works when a developer can predict what the interface does at any width, not just the widths you drew. That takes rules: which breakpoints exist, what changes at each one, and how components behave between them. Frames illustrate the rules, but they can't replace them.
This is the part of a design-to-development handoff that web apps get wrong most often. Marketing pages can survive a rough responsive spec because they're mostly stacks of sections. Web apps have sidebars, tables, filters, modals and dense toolbars, and each one needs a decision about what happens when space runs out.
Why not just design every screen at every breakpoint?
Because duplicated frames multiply the work, drift out of sync and still don't define the sizes in between. For example, a product with fifty screens drawn at four widths has two hundred frames to keep current. One change to a component means four updates, and the version someone forgot is the one that gets built.
Approach | What developers get | Main problem |
|---|---|---|
Every screen at every width | Many frames, no rules | File bloat, drift, gaps between widths |
Desktop only | One frame and guesswork | Every responsive decision made in code |
Key widths plus written rules | Frames where layout changes, rules for the rest | Requires discipline to write the rules |
Responsive components with auto layout | Components that resize correctly in Figma | Only covers component behavior, not page layout |
The third and fourth approaches together are what we use. Components handle their own resizing through Figma auto layout that maps to CSS, and page-level changes get drawn once at the width where they happen, with a rule attached.
Which breakpoints should a web app design use?
Use the breakpoints your codebase already uses, and refer to them by name. If the front end is built with Tailwind, its default breakpoints are named sm, md, lg, xl and 2xl, with the pixel values listed in Tailwind's documentation. Designing at one width while the code switches layout at another creates arguments about which version is correct.
Most web apps need only three layout modes: phone, tablet or small laptop, and desktop. Pick the breakpoints where your layout changes between them, write them on the file's read-me page, and name frames by mode rather than by device, for example Billing / Desktop (lg and up). Devices change every year. Breakpoint names in code don't.
How do you write responsive rules instead of duplicated frames?
Write each rule as an element, a breakpoint and a change: "Sidebar: below lg, collapses into a drawer opened from the top bar." Keep the rules in a short table on the ready-for-dev page, next to the frames they modify. A developer can implement a rule like that directly, and QA can test it.
Element | Rule | Drawn as a frame? |
|---|---|---|
App sidebar | Below lg, becomes a drawer opened from the top bar | Yes, both modes |
Page header actions | Below md, secondary actions move into an overflow menu | Yes, at md |
Card grid | Columns fill available width with a minimum card width | No, rule only |
Data table | Below md, becomes a stacked list with the three key columns | Yes, the stacked list |
Filters bar | Below lg, collapses into a Filters button that opens a sheet | Yes, the sheet |
Modal | Below sm, becomes full-screen with a sticky action bar | Yes, one example |
Body text | Max width for readability at every size | No, rule only |
Notice that card grids and text never need extra frames. They just stretch or wrap, which a rule describes better than four pictures. Save frames for changes in structure: things that move, hide, collapse or turn into something else.
How should you spec responsive components?
Spec responsive components by the space they're given, not by the viewport. A card might sit in a three-column grid on desktop and a sidebar on the same screen, so a viewport rule doesn't describe it. CSS container queries let components respond to their container's width, and designing with that model makes components reusable across layouts.
- Set resizing on every layer: fill, hug or fixed, plus min and max widths, so the Figma component behaves like the coded one.
- Define a minimum width: the narrowest size at which the component still works, and what happens below it.
- Show one alternate layout if it changes: for example a horizontal card that stacks when narrow.
- Spec text overflow: wrap, truncate with an ellipsis or clamp to a number of lines.
- Spec touch targets: controls that are comfortable on desktop can be too small on a touch screen, so define a minimum tap size for small modes.
Hypothetical example: speccing a dashboard for three modes
For example, suppose a SaaS analytics dashboard has a sidebar, a header with date range and export actions, four KPI tiles and a large data table. The designer draws three frames: desktop (lg and up), tablet (md to lg) and phone (below md).
The rules table says: the sidebar becomes a drawer below lg; KPI tiles fill a grid with a minimum tile width, so they go from four across to two to one without extra frames; export moves into an overflow menu below md; the table becomes a stacked list showing name, status and value, with a link to the full row. Three frames and five rules cover every width, and a developer can build all of them without a follow-up question.
How do you handle fluid type and spacing in a responsive handoff?
Handle fluid type and spacing by speccing a minimum, a maximum and the range they scale across. In code, that becomes a CSS clamp() value, so a heading grows smoothly from phone to desktop instead of jumping at breakpoints. In Figma, show the two ends and write the range next to the type style.
Keep fluid scaling for display headings and major section spacing. Body text, form controls and app chrome usually work better at fixed sizes, because density and alignment matter more in product UI than drama. If your product is translated, test fluid type with longer strings as well. Our guide to designing for multiple languages covers text expansion, and accessible design basics covers why zoom and resizing must never break the layout.
How do you check a responsive spec before handoff?
Check it by resizing, not by reading. A spec that looks complete on paper often breaks the first time someone drags the frame narrower.
Drag every key frame between its breakpoints
Resize each drawn frame from its smallest to its largest intended width and look for overlap, overflow and awkward gaps.
Swap in the longest real content
Long names, big numbers and translated labels expose most responsive problems in seconds.
Check each rule has an owner element
Every rule in the table should name a specific component or region a developer can find in the file.
Confirm breakpoint names match the code
Ask a developer to check the names and values once. It prevents a whole category of disputes later.
Run the handoff checklist
Finish with the full Figma handoff checklist and mark the section ready in Figma Dev Mode.
When mobile is the main product rather than a smaller web layout, the problem changes. Read the mobile app design process for native patterns. And if you want a responsive system designed by people who also build it, our fixed $3,000 brand and design sprint delivers Figma files structured this way.
