Scaled down is not adapted
AI-generated pages usually look fine on desktop and fall apart on a phone:
- A 48px headline wrapping onto five lines
- Three cards squeezed into three narrow columns instead of stacking
- A table overflowing horizontally, so the whole page drags sideways
- A fixed navbar covering the content beneath it
- Buttons too small to hit reliably
The root cause is that the model is designing for desktop by default, then adding breakpoints that scale things down proportionally. Real adaptation isn't scaling — it's re-laying-out.
Four constraints that do the most work
1. Specify the mobile type scale explicitly
Don't give desktop sizes and let the model guess the rest:
Type scale:
Desktop: h1 48/1.1, h2 32/1.2, body 16/1.7
Mobile (<768px): h1 32/1.15, h2 24/1.25, body 16/1.7
Body text never below 16px at any breakpoint
That last line matters: below 16px, iOS Safari auto-zooms the page when an input gains focus, which feels broken.
2. Say how multi-column blocks reflow
Don't leave it to inference. Go block by block:
Mobile layout:
- Hero two-column → stack vertically, image below the text
- Three-card row → single column stack (not horizontal scroll)
- Feature comparison table → keep the table, wrap it in a
horizontally scrollable container; the page itself must never
scroll horizontally
- Four-column footer nav → two columns
"The page itself must never scroll horizontally" is worth including every time. Horizontal overflow is the most common and most visible mobile defect, and it's completely invisible on desktop.
3. Touch target sizes
All tappable elements have a minimum 44×44px touch target on mobile,
with at least 8px between adjacent tappable elements.
Icon buttons and tightly-packed links are the usual offenders — a visually 16px icon with no padding is a 16px touch target.
4. Fixed elements need safe areas
Fixed navbar height 56px; main content offset by 56px accordingly.
Bottom-fixed CTA must account for the iOS safe area:
padding-bottom: calc(16px + env(safe-area-inset-bottom)).
env(safe-area-inset-bottom) handles the home indicator on full-screen iPhones. AI won't add it, and the result is a button half-covered by the system bar.
The lazier, better option: design mobile first
Rather than "desktop like this, mobile like that", invert it:
Design at 375px mobile width first, then adapt upward to tablet and desktop. Mobile is the primary context.
That single sentence outperforms a pile of breakpoint rules, because it changes the model's default viewpoint — from "shrink the desktop" to "expand the mobile", and the latter doesn't naturally produce overflow or crowding.
A thirty-second self-test
After generating:
- Drag the browser window to its narrowest, then widen slowly from 320px and watch where it breaks
- Check for a horizontal scrollbar — if one appears, something is overflowing
- Open it on a real device. Not the devtools emulator — an emulator won't tell you a touch target is too small, won't show the iOS safe area, and won't reveal how it loads on a real network
Step 3 gets skipped constantly, and it consistently catches things the first two can't.
The full block, ready to paste
Responsive requirements:
- Design mobile-first at 375px, adapt upward
- Breakpoints: 768px (tablet), 1024px (desktop)
- Mobile type: h1 32/1.15, h2 24/1.25, body 16/1.7;
body never below 16px at any breakpoint
- Multi-column blocks stack vertically below 768px; no horizontal scroll
- Wide tables get an overflow-x wrapper; the page never scrolls horizontally
- Tappable elements: minimum 44×44px, at least 8px apart
- Bottom-fixed elements use env(safe-area-inset-bottom)
Every prompt on MotionSites is written mobile-first, which removes this entire round of rework.