The Actual Process, Not the Theory
Most people try to start responsive design by defining breakpoints and laying out pixels before they've actually looked at the content. That's backwards. Stephen Hay's approach flips that entirely. Instead of starting with the layout, you start with the content and let it breathe at its natural size. I used to work on enterprise projects where the design system had more breakpoints than I could keep straight in my head. We'd spend two days arguing about whether a card component should shift at 768px or 792px. It was exhausting and it produced mediocre results. After finding Hay's method, the whole process took me maybe an afternoon to get comfortable with.
Understanding the Responsive Design Workflow Stephen Hay
Hay describes what he calls "responsive web design" in a way that's much more practical than most textbooks. The core idea is simple: write your CSS at one breakpoint and let the browser handle the rest using relative units. The only time you need a media query is when the layout genuinely can't work anymore. This isn't a radical concept on paper, but it changes how you actually work. You stop designing for specific viewports and start designing for continuous flow. Content determines structure instead of a grid imposing itself on content. The workflow goes like this. You pick a base breakpoint, typically something narrow like 320px or even 480px if your content allows it. You write all your CSS using relative units — ems, rems, percentages, viewport widths. No hardcoded pixel values for spacing, sizing, or layout positions. Then you test at larger viewports and only add a media query when you notice a genuine problem, like a text line that's too long to read comfortably or a navigation that collapses in a way that breaks usability.
Setting Up Your Environment
You don't need special tools. A browser with dev tools, a code editor, and patience are enough. I recommend writing in ems for typography and spacing since ems compound relative to their parent context, which gives you predictable scaling as you nest elements. For layout distances and container widths, rems or percentages work fine depending on your preference. Here's the thing nobody tells you: start your stylesheet completely unstyled. Write the content HTML first, then apply zero CSS. Load it in a browser. Note how it looks. That default browser styling is your baseline. Now start adding CSS one property at a time and watch how each change behaves across different viewport widths in real time. Test constantly. I keep a phone on my desk connected via USB debugging and resize the browser window repeatedly. The goal is to notice issues early, not after you've written three hundred lines of responsive CSS and then realize the hero section breaks at 1024px.
Get the Full Details
Common Pitfalls I've Encountered
The biggest mistake beginners make is still reaching for pixel values because they feel more precise. They're not. Pixels create hard edges in a medium that is inherently fluid. I once spent four hours debugging a pricing table that looked perfect at 1200px but collapsed into an unreadable mess at 900px. Every width was hardcoded in pixels. Rewriting it with relative units took twenty minutes and eliminated the problem entirely. Another issue: overusing media queries. People treat them like safety nets and sprinkle them everywhere "just in case." This defeats the entire purpose. Each media query you add is a place where something can break at an unexpected breakpoint. Hay's approach minimizes them to near zero for typical content-heavy pages. I ran into a genuinely tricky edge case recently on a project with a complex data table. The columns didn't stack well at any reasonable breakpoint, and the content was wide enough that horizontal scrolling was the only option that preserved readability. Traditional responsive techniques would have forced a stack layout that made the table unusable on mobile. The workaround was wrapping the table in a container with overflow-x: auto and setting the table width to min-width: 100%. It's not the most elegant solution, but it's honest about what the content requires. No amount of media queries was going to make that table read well at 320px.
What This Approach Doesn't Handle Well
I need to be direct about the limitations. If you're building a complex dashboard with multiple competing layout regions, or a multi-step form with conditional logic, this workflow alone won't save you. You'll still need deliberate breakpoint decisions for those components. Hay's method shines brightest with content-forward sites: blogs, articles, marketing pages, portfolios, documentation. There's also a gotcha with images. Even if your text layout scales smoothly, images can still overflow containers if you don't set max-width: 100% and height: auto. This is so common that I now treat it as a universal reset rule rather than something I think about per-case. Any image-based layout will break without it. If your project demands highly varied layouts across device categories, you might be better off with a component-driven approach using CSS Grid and container queries. Container queries in particular are changing the game for component-level responsiveness and reduce the need for viewport-based media queries significantly.
The Mindset Shift
The hardest part isn't technical. It's accepting that you don't need to control every detail at every size. You set up sensible defaults with relative units, you write minimal CSS, and you trust the browser. The results are often cleaner than what you'd get from a carefully tuned pixel-perfect breakpoint strategy. It also means less CSS overall. I've seen projects cut from twelve kilobytes of responsive styles down to three by removing unnecessary media queries and replacing them with fluid sizing. Smaller bundles, faster renders, fewer things to maintain. If you want to see this in practice, Hay published his book "Hello World: Web Development, Component-Based & Unbound" which walks through the entire process with real examples. The companion site for the book itself is built using this exact methodology. Inspect the source if you want to see what it actually looks like when you strip away the breakpoint obsession.
The workflow also extends beyond CSS. Using relative units for font sizes, padding, margins, and even gap values means your spacing system scales proportionally instead of hitting arbitrary thresholds. clamp() functions are useful here as a hybrid approach when you need hard limits on either end. Something like font-size: clamp(1rem, 2.5vw, 1.5rem) gives you fluid scaling between two boundaries without any media query.
