How to make AI-generated UI responsive

AI-generated UI usually breaks on phones because it was designed for one desktop width and then squeezed. Making it responsive means deciding how each part should change, not just shrink: which table columns survive, where the sidebar goes, how navigation collapses, what a card grid becomes. Tell your agent those decisions explicitly, give it the widths that matter for your product, and check the result at those widths in a real browser.

Why desktop-first output fails on mobile

• One reference width. Mockups, screenshots and prompts usually describe a wide screen, so that’s what gets designed.
• Scaling instead of restructuring. Columns get narrower until text wraps word by word, rather than reorganising.
• Fixed widths. A w-[480px] panel or a 1200px table guarantees horizontal scrolling on a phone.
• Hover-dependent UI. Actions that only appear on hover don’t exist on touch screens.
• Unchecked output. If nobody looks at 375px, nobody notices.

In Tailwind, it helps to remember the model: unprefixed utilities apply at every size, and prefixed ones like md: apply from that breakpoint up. The Tailwind docs warn that sm: doesn’t mean “on small screens”. Generated code gets this backwards surprisingly often.

Choose breakpoints from your content

There’s no universal set of correct breakpoints. Tailwind’s defaults (640, 768, 1024, 1280 and 1536px) are a reasonable starting point, but the right places to change layout are where your content stops working. Pick test widths from your own analytics and from the layout itself: typically a small phone, a large phone, a tablet or narrow laptop, and a desktop. Then add a width wherever something visibly breaks.

For components that live in different-sized containers (a card in a sidebar and in a main column), container queries are often better than viewport breakpoints. Tailwind supports them with @container and variants such as @md:.

Pattern by pattern

Data tables

Tables are the hardest case. Pick one approach per table and state it:

• Priority columns: keep the two or three columns people scan for; move the rest into an expandable row or a details view.
• Stacked rows: each row becomes a compact list item with a label for each value.
• Contained horizontal scroll: acceptable for genuinely two-dimensional data, if the first column stays visible and only the table scrolls, never the page.

WCAG’s Reflow criterion explicitly allows two-dimensional scrolling for data tables, but not for the rest of the page around them.

Sidebars and navigation

• App sidebars usually become a drawer behind a menu button, or a bottom bar for three to five top-level destinations.
• Secondary navigation (tabs, filters) can become a horizontally scrolling row or a select, with the current item visible.
• Page actions in a header row often move into an overflow menu, keeping only the primary one visible.

Cards and grids

• Grids should reflow by available width (grid-cols-1 sm:grid-cols-2 lg:grid-cols-3, or container queries), not shrink.
• Ask whether a card grid should become a list on mobile. Lists are often denser and easier to scan.
• Truncate long titles deliberately, and test with real long content.

Forms and dialogs

• Multi-column forms become one column.
• Large dialogs become full-screen sheets on phones, with the primary action reachable without scrolling past the keyboard.
• Use the right input types (email, tel, number) so phones show the right keyboard.

Viewport and touch details

• Viewport height: 100vh can be taller than the visible area on mobile browsers. Dynamic viewport units such as 100dvh track the visible area more closely.
• Touch targets: WCAG 2.2 sets a minimum target size of 24 by 24 CSS pixels, with exceptions such as adequate spacing. Many teams aim larger for primary actions.
• No hover-only actions: anything revealed on hover needs a visible or tappable alternative. The pointer: coarse media feature can help adapt for touch.
• Safe areas: fixed bottom bars need padding for device insets such as the home indicator.

Mobile typography and spacing

• Body text shouldn’t shrink below a comfortable reading size on phones; keep it at your base size.
• Display headings should scale down (for example with clamp()) so a hero headline doesn’t break into one word per line.
• Reduce outer padding, not the spacing that groups related items.
• Check that long words, URLs and numbers wrap or truncate instead of overflowing.

Refinement prompts that work

Be specific about the change and about what must stay the same:

Make the invoices page work from 360px wide. Keep the desktop
layout exactly as it is.
- Below md: the table becomes a list. Each item shows customer,
  amount (right-aligned) and status; date and invoice number go on
  a second muted line. Tapping an item opens the existing detail
  sheet.
- The filter bar collapses into a "Filters" button that opens a
  full-screen sheet. Show the active filter count on the button.
- Page actions: keep "New invoice" visible; move "Export" and
  "Settings" into the overflow menu.
- No horizontal page scroll at any width.
Then screenshot at 360, 390, 768 and 1280 and show me all four.

Audit this page for touch use: list every interactive element
under 24 by 24 CSS pixels, every action that only appears on hover,
and every fixed-width element wider than 360px. Don't fix yet.

Test at representative widths

Responsive bugs are found by looking. Have Claude screenshot your test widths after each change, and make the check repeatable with Playwright: our visual testing guide includes a tested example that fails when a page scrolls horizontally. Then check on a real phone, because emulation doesn’t show everything: the keyboard covering inputs, safe areas and how touch actually feels.

Responsive work overlaps with accessibility: reflow, target size and zoom are both. See how to make AI-generated interfaces accessible, and for refining the rest of a generated screen, improving AI-generated UI without rebuilding everything.

Decide what changes, not just what shrinks

Responsive design is a set of decisions about what changes at each width. Make those decisions per pattern, write them into the prompt with what must stay fixed, and verify at widths chosen from your content and users. An agent will happily make a layout narrower; it takes your instructions to make it work.