Design for the smallest screen you ship. Expand from there.
"Approach responsive layouts without writing five separate stylesheets or designing five separate screens."
Ali AhmedWhy this exists
Responsive design failures usually stem from process, not technique. Designers hand off desktop frames, and engineers build them. Then we retrofit mobile in the final sprint under time pressure. It always shows. Starting from the smallest viewport forces you to face the real constraint of what actually matters on the screen. Everything added for larger viewports is an enhancement, not a requirement.
Operational Flow
Design mobile-first in Figma: Every component and layout frame must have a 375px artboard before a 1440px one. If only the desktop exists at handoff, send it back.
Use container queries over media queries: Components should respond to container width rather than viewport width. This applies to any component appearing in a sidebar, modal, or full-width section.
Define breakpoints as tokens: Use sm (640px), md (768px), lg (1024px), and xl (1280px). These four cover almost every scenario. A custom breakpoint requires a written explanation.
Test on physical devices: Test on a physical iPhone and Android before marking a layout done. Simulated viewports in browser developer tools lie about tap target sizes and font rendering.
Audit touch targets: Every interactive element must meet a 44x44px minimum on mobile. Run a target audit using Lighthouse or Chrome DevTools before releasing mobile layouts.
Document layout shifts explicitly: If a layout changes significantly between breakpoints, such as a grid collapsing or a sidebar becoming a drawer, annotate it in Figma and the PR description.
What good looks like
- A component works at 375px, 768px, and 1440px with no extra CSS beyond adjusting column counts and spacing because it was designed flexibly.
- A junior engineer implements a responsive layout from Figma without asking what happens on mobile, because the mobile frame is already there.
- A client demo on a phone looks as polished as the desktop version in the pitch deck.
What NOT to do
- Don't hide large chunks of content on mobile with display: none. If it shouldn't exist on mobile, reconsider if it needs to exist at all.
- Don't add a new breakpoint without checking if container queries or fluid spacing can solve the issue first.
- Don't finalize a layout in Figma without testing it in a real browser. Figma preview is not a substitute.
Responsive layout seems like a technical problem, but it usually hides a process problem. On a project in 2023, we designed mobile three days before launch. The engineer had not seen the Figma file and worked from a screenshot of the desktop version. The result worked and passed QA, but it was miserable to use on a phone. The client flagged it in their feedback. Nobody was surprised. Everyone knew mobile was an afterthought, and everyone let it stay that way.
The smallest screen is not a cut-down version of the desktop screen. It is the original argument. Everything you add as the viewport grows must have a reason. If you cannot explain why a sidebar is hidden on mobile, the sidebar probably should not exist at all.