Setting Responsive Breakpoints

Far too many designers and developers are setting their breakpoints solely based on common screen and device sizes. Some decide on their breakpoints before they’ve finished content or design. Some choose based on the devices and screen sizes they have and use (the most obvious of this group are Apple users, who immediately decide they will work with 320, 480, 768, 1024, and probably 1440, to be safe).

If you’re setting breakpoints based on common screen and device sizes, you’re missing the point of responsive design. Responsive design is about designing for the unknown, for the future, and for all viewports — even those yet to be made. It’s about creating something that is device– and resolution–agnostic.

Past, Present, and Future Screen Resolutions

Years ago, 800x600 was the resolution of the day. As time moved on, resolutions grew. Soon, 1024x768 was king. Since then, we’ve seen the days of the 1200s, 1300s, 1400s, and now we’re creeping into the 1600s. Most designers and developers I know use displays at work (and at home) that are anywhere between 1,900 and 2,500 pixels wide. Mark Huot used to use four of these monsters, apparently.

But, since the 800x600 days, resolutions have gotten smaller, too. With the explosions of the smartphone and tablet markets, there are an overwhelming number of popular resolutions in the wild.

So, with this rapid change happening all around us, why would we choose to focus on a small number of devices? Historical patterns tell us that displays are getting bigger and smaller, at the same time. Predicting future resolutions is as ridiculous as choosing three or four of today’s devices on which to perfect your design.

What about when the most popular devices shift away from their current screen resolutions? I promise, they will (history tells us so). Suddenly, you have site with a design that’s perfected at sizes few people see. Maybe these new resolutions are displaying your site in some unflattering way. Maybe inconsistencies and flow issues, not present at other sizes, have popped up. Maybe things are just a little too spaced out, or maybe those featured images are just a little too overpowering.

This approach doesn’t sound very future–friendly to me. And it certainly doesn’t sound very responsive.

Instead, Let Content and Design Lead

By choosing breakpoints from the start, you create deadzones between two breakpoints, or just before new styles take effect. These deadzones are viewport ranges which have small layout or design issues — hopefully nothing major (but remember, small details go a long way).

Many leave deadzone issues unfixed, out of laziness and apathy. Others try to combat them by applying more styles through media queries, which ends up creating excess media query bloat. Don’t over query — wrangle those percentages, and let them work for you.

The much smarter, more complete, and more future–friendly way to set breakpoints is to let your content and design lead. This means you have to choose a starting point, either large–screen–first or small–screen–first (desktop– or mobile–first, for those that prefer those terms). I prefer a small–screen–first approach, for many reasons (I’m writing something about that now. It should be posted soon!), so I’ll use that approach as a basis for this example. Let’s assume you have just finished your basic, small–screen styles, and are ready to begin moving up through the sizes.

Start expanding your browser, and once something begins to fall apart — be it layout, a design pattern, content size, or otherwise — set a media query at that pixel (or em) value. This is a much easier, more detail–oriented approach (which I find extremely important), and it reduces those finicky deadzone issues. (Sidenote: the good news about starting small–screen–first is that you can keep going up forever! Up to 3,000 pixels, or to whatever value floats your boat).

This approach ensures that your design looks truly great and refined at every size, not just at the dimensions of devices deemed important. A nice side effect of this methodical approach is that it helps you find design issues at (almost) every size. Through my work, I found this process really improves all sides of the final product — including layout, performance, small details, enhancements, future–friendliness, and a ton more.