Best wireframing breakpoints to work with new frontend developer

Question

I've searched tons on this topic, e.g.:

1. https://medium.freecodecamp.org/the-100-correct-way-to-do-css-breakpoints-88d6a5ba1862
2. https://graphicdesign.stackexchange.com/questions/39433/what-are-best-practices-for-determining-responsive-design-breakpoints
3. https://graphicdesign.stackexchange.com/questions/247/is-there-a-standard-width-for-designing-web-page-mockups/277#277
4. Determine correct breakpoints to wireframe to a responsive website!
5. Responsive design: Should I go bigger than 1024px?
6. Responsive Breakpoints?
7. https://seesparkbox.com/foundry/there_is_no_breakpoint

QUESTION remains: when You're building new team, want to incorporate some standards to work fast and efficient on as few breakpoints as possible, Your developers don't know Your approach to design ("My UX teams understand responsive design, so they are able to "interpolate" between two layouts without having to create a wireframe to illustrate exactly how flow changes"), how do You address changes in layout?

Going the "100% correct way to do CSS breakpoints" (first link) gives You 4 breakpoints. As far as I get it, one should design a:

• 600px breakpoint so devs know how to address phone devices
• 900px breakpoint so devs know how to address tablet portraits from 600px to 900px
• 1200px breakpoint so devs know how to address tablet landscape from 900px to 1200px
• and now what? 1800px? How would devs know how to e.g. compress some tables on 1280 if they don’t fit and one column should be removed on small resolutions? Or how would they know there’s a change in some element that now works with hover effect (since tablets don’t accept hovers)?

Should 1800px breakpoint tell them how the website/app should look like on all laptop and desktop devices? If so, from our experience it’s almost impossible to include every of that information in just one big breakpoint. And as You know, it’s easier to show something than to make notes when You want to eliminate misunderstanding.

Some of You will say - "mobile first then scale up" but in real world noone presents 380px layout in front of client. Some will say - "everything runs on % so it will scale up" but it's also almost impossible to calculate the proportions of every whitespace so well they will perfectly scale up.

Going the "There's no breakpoint" way means designing a tons of wireframes instead of 4 or 6 since You must design a new one every time an element doesn't fit. No time for this in rapid prototyping/wireframing.

What's Your approach?

Answer 1

This is indeed a complicated topic and I have used many different approaches. I never believed in a mobile first strategy – it might sound nice but is really impractical because of the reasons that you mention. I believe the one working best is letting your UI Designer build a HD Desktop, SD Desktop (Laptop), tablet and mobile design. If all of those are actually needed is dependent on the design anticipation ability of the developer implementing it. The exact breakpoint values are not as important as one might think, as long as they're in the range of what is expectable for that specific device. Instead of thinking in absolute pixel values, it makes more sense to consider screen aspect ratios, because they are the ones that will remain (relatively) consistent for each device type.

Regarding implementation in CSS, you will find that it is almost impossible to find breakpoints that work for every resizing situation of your website. Because of that, I use to regard the device designs as a guidance as to what elements are expected to break and how they should resize.

I use many different media queries and fluid/relative width definitions for different elements of the site, making sure that no odd things happen while I resize the dimensions in the browser. It however makes sense to try grouping breakpoints that are in close range to a variable to create a more consistent experience. It is important not to think in stiff breakpoints, but in a fluid design, that adapts to display dimensions in the most seamless way possible, which means using as many media queries in your css as necessary to achieve that. CSS Preprocessors like SASS/LESS can be a great help with that.

Answer 2

The breakpoints you mention above seem realistic. I also do the research and decide what the breakpoints should be.

After the website has a fair amount of traffic we check the screen resolution sizes (analytics) and usually end up having a good idea of how we're doing (and sometimes changing breakpoints slightly at that point).

Answer 3

I normally go by bootstrap's standard breakpoints because it's easy to use and seems to work very well.

Here's their latest version's breakpoints:

// Extra small devices (portrait phones, less than 576px) // No media query since this is the default in Bootstrap

// Small devices (landscape phones, 576px and up) @media (min-width: 576px) { ... }

// Medium devices (tablets, 768px and up) @media (min-width: 768px) { ... }

// Large devices (desktops, 992px and up) @media (min-width: 992px) { ... }

// Extra large devices (large desktops, 1200px and up) @media (min-width: 1200px) { ... }