Responsive design

The production question

A workloads table with status, region, recovery point, and action columns looks fine at 1,440px and increasingly cramped at 1,024px. At exactly what point do you stop shrinking columns and start replacing the table with something structurally different — and once you cross that line, which fields survive into the new layout and which get cut?

How to decide

1. Identify what the table (or nav, or card row) is actually for — comparison, monitoring, or navigation — because that purpose determines which fields are decision-relevant and which are decoration.
2. Test the current Auto Layout structure (Hug/Fill, wrap, min/max widths) at the target width first — if wrapping and Fill alone still produce a usable result, you don't need a transformation yet, just a resize.
3. If columns start truncating status text or the action control gets squeezed under a usable tap size, that's the signal to stop scaling and design a different arrangement, not shrink the type further.
4. Rank the remaining fields by decision relevance: what would make someone click into this specific row? Keep those visible; demote the rest to secondary text or drop them.
5. Choose the transformation pattern that matches the content — table rows become cards, a side nav becomes a compact header, a metadata row collapses into an overflow disclosure — and reuse the same component instances rather than building parallel mobile-only versions.
6. Re-run the stress tests (longest name, zero rows, multiple simultaneous warnings) against the transformed layout before calling it done — a transformation that only survives clean sample data isn't finished.

Correct vs. incorrect

Practice it, then try to break it

Take a four-card summary row (label, value, trend note, status) and a workloads-table concept and design their 768px and 390px versions from the same component instances. At 768px, decide which one field in each summary card gets dropped or demoted before the type itself shrinks. At 390px, turn the table into a card list. Then stress-test both with a workload name long enough to wrap to two lines and one card in a warning state — confirm nothing overlaps or clips, and that you didn't detach a single instance to make it work.

Stress test: Set five workloads to a warning state simultaneously in the 320px card-list view. If the warning treatment (icon, color, copy) pushes card height inconsistently, shifts the recovery action to a different position from card to card, or makes the list unscannable, the mobile transformation only works for the happy path — it hasn't actually been designed for the state that matters most.

Common mistakes

• Resizing the desktop frame and calling whatever Auto Layout produces “responsive,” instead of deciding which fields should survive at each width.
• Detaching instances to force a mobile-only version of a table row or nav item, which breaks the update path the component system exists to provide.
• Testing only the widest and narrowest frame (1,440 and 375) and skipping tablet, where secondary metadata should get reduced before type ever gets compressed.
• Moving the primary action into an overflow menu to save space on mobile while leaving lower-priority actions like export or column settings visible.

Accessibility and handoff

If the fields dropped or demoted at each breakpoint aren't annotated, a developer has no way to know whether a missing column on mobile was a deliberate content decision or a bug — and without a minimum tap-target size called out explicitly, an action that read fine as a desktop table cell can ship too small to reliably tap on mobile.

FAQ

Do I need a separate Figma frame for every breakpoint, or can one frame just resize?

Build distinct frames for the breakpoints where the arrangement actually changes. A single frame can preview intermediate widths, but a transformation like a table becoming cards needs its own frame so you design it deliberately rather than let it fall out of dragging a resize handle.

How many breakpoints should I actually design?

Design for the widths where behavior changes, not an arbitrary count. A dashboard typically needs three — desktop, tablet, mobile — because that's where the side nav, table, and card row each need a different arrangement; a fourth is only worth designing if something distinct actually happens there.

Is Auto Layout (Hug, Fill, wrap, min/max) enough to get responsive design, or do I need something else?

Auto Layout is the mechanism, not the decision. It lets a card resize or wrap cleanly, but choosing that a table becomes a card list, or that a side nav becomes a header, is a content and priority call Auto Layout can't make for you.

Should I design mobile first or desktop first?

Neither order is mandatory, but design the states — empty, warning, error — before you polish either one. A warning state or an unusually long name changes the structure of both layouts, so polishing before that's settled just means redoing the work.