5 Responsive Design Patterns I Actually Use

As a Junior, I Thought Media Queries Were Everything

Below 768px, do this. Above 1024px, do that. Isn't that what responsive means? After more than 2 years of responsive work in production, I realized media queries are just one piece of the puzzle. Here are the 5 patterns I use most.

Pattern 1: Container Queries for Flexible Cards

My blog post cards display as a 3-column grid on the home page, 1-column in the sidebar, and 2-column in related posts. I used to either create separate cards for each location or manage three layouts with media queries.

CSS Container Queries let the card adapt its layout based on its parent's size. Wide parent? Horizontal layout. Narrow parent? Vertical. Drop it anywhere and it just works. Media queries ask "how big is the screen?" while container queries ask "how big is the space I'm in?" This difference dramatically improves component reusability.

Pattern 2: Hide with CSS Instead of JS Conditional Rendering

When hiding a sidebar on mobile, a lot of people do {isMobile ? null : <Sidebar />}. The problem is determining isMobile requires reading window.innerWidth, which doesn't work during server rendering. Classic hydration mismatch territory.

Tailwind's hidden md:block avoids server rendering conflicts entirely. The HTML is already rendered — CSS just controls visibility. The trade-off is that hidden DOM still takes up memory. My rule: CSS hiding for lightweight UI, dynamic import + conditional rendering for heavy components. (Though this rule gets shaky pretty often.)

Pattern 3: Move Core Navigation to the Bottom

Desktop gets a top horizontal nav, mobile gets a hamburger menu. The most common pattern, but I add one thing: I pull 2-3 frequently used menu items into a bottom tab bar on mobile.

The user's thumb naturally reaches the bottom of the screen. A top hamburger menu requires reaching up every time. Core items at the bottom, everything else in the hamburger. This hybrid approach is much more effective for mobile UX. Though deciding what goes in those three bottom slots is surprisingly difficult — you can only pick three.

Pattern 4: Responsive Typography with clamp()

A fixed font-size: 16px looks small on large screens. With clamp(), it scales naturally: font-size: clamp(1rem, 0.5rem + 1.5vw, 1.5rem) — scales proportionally between 16px minimum and 24px maximum based on screen width. No media queries needed, and it looks right on every screen.

After applying this to my blog body text, the "text is too small on mobile" feedback completely stopped.

Pattern 5: Defend the 44px Touch Target

Tapping a button on mobile and accidentally hitting the one next to it — we've all been there. WCAG minimum touch target size is 44x44px. Pad text links to expand their hit area, and ensure icon buttons have at least 44px of hit area even if they look smaller visually. In Tailwind, making min-h-11 min-w-11 the default for icon buttons noticeably improves mobile usability.

Chrome DevTools Alone Isn't Enough

Some things only surface on actual devices. Hover states sticking on mobile, soft keyboard pushing the layout, the feel of momentum scrolling — you can't catch these in the emulator.

I use ngrok to expose my local server and test on my actual phone constantly. This single habit cut "it's weird on mobile" feedback in half. It's annoying, but the results are undeniable.

In the End

Responsive isn't "fitting the screen size" — it's "fitting the usage context." Mobile users don't just have smaller screens. They're using one hand, viewing in sunlight, on spotty connections. But realistically, you can't address everything every time. You just tackle them one by one.