Making Responsive Work
Don't just stack desktop components onto mobile—decide the trade-offs at each breakpoint first.
Don't just stack desktop components onto mobile—decide the trade-offs at each breakpoint first. Responsive design is not letting a layout auto-squash. It's swapping in a different structure at specific widths. What to swap and how is a design decision, not a technical one. Media queries are just the mechanism; the real work is re-judging the content relationships at every tier.rwd-wiki
What you'll run into:
- On mobile you drag sideways to read a table, and you still have to zoom to tap anything
- The desktop sidebar becomes a long strip across the top on mobile
- Ask AI for responsive design and it just stacks columns into one, leaving the nav untouched
How many breakpoints
| Tier | Width | Layout character |
|---|---|---|
| Mobile | Below 768px | Single column, bottom tab nav, cards instead of tables |
| Tablet | 768–1024px | Two columns, collapsible sidebar, fewer columns in tables |
| Desktop | Above 1024px | Multiple columns, persistent sidebar, full tables |
Three tiers are enough. Don't memorize breakpoint values—the real test is "does the content start to look bad at this width." Drag the browser narrower slowly; the first place it feels awkward is your breakpoint.
Pick the main battlefield first. If 90% of users are on desktop, build desktop well and ship a "good enough" mobile version—and vice versa. Trying to make both ends equally good usually leaves both awkward.
What changes at the breakpoint
| Element | What it becomes on mobile |
|---|---|
| Table | Cards. One row becomes one card, showing only the two or three key fields; the rest folds away |
| Side nav | Bottom tabs, at most five, overflow goes into "More" |
| Multi-column layout | One column, but reordered by priority, not stacked left to right as-is |
| List plus detail on one screen | Two pages, with a back control on the detail page |
| Hover-only content | Always visible or long-press. Mobile has no hover |
| Batch actions | Long-press into multi-select, or skip entirely and leave it for desktop |
Stacking columns is the step people fake most easily. On desktop it's "main content left, auxiliary right"; stacked into one column, auxiliary under main is tolerable—but if auxiliary ends up on top, users scroll a full screen before seeing the point.
A few zero-cost rules that are often skipped. Their order matters: settle the breakpoints and structural changes first, then tune these details—adjusting type size before the structure is fixed means polishing the wrong layout.
- Size tap targets to fingers. No matter how small the icon looks, the tappable area should reach about 44px.
- Don't scale font sizes proportionally. Body text on mobile should actually be slightly larger than desktop—the screen is smaller but closer to the face.
- Match the keyboard. Phone fields pull up a numeric keypad; email fields one with an @. Zero cost, yet many products skip it.
- Look at it on a real device. Dragging the browser narrow isn't the same as a real device—safe areas, the address bar, and keyboard occlusion only show up on actual hardware.
Tell AI
Write down what changes and how, so AI doesn't just stack.
Make this page responsive, breakpoints: 768px / 1024px.
Don't just stack the columns into one. For each element type,
state the change explicitly:
- Tables -> cards on mobile; list which fields are kept,
which field leads the visual, and how the rest are handled
- Side nav -> bottom tab bar; state which four items remain
and where the rest go
- Multi-column layout -> stacked order re-ranked by importance;
state the new order
- Hover-dependent interactions -> what they become
- Batch actions -> keep or remove
Other requirements:
- Tap targets no smaller than 44px
- Mobile body text no smaller than desktop
- Inputs specify inputmode / type by content type
Propose the plan for each item above first; I'll confirm before you change code.