Break Before the Breakpoints in Responsive Web Design

We all know that today we have to design websites using Responsive Web Design. I even wrote an article in Gonzoblog in 2012 where I stated that RWD is our responsibility as web professionals. So, now that everyone agrees that RWD is the way to go and has being creating websites for this technique for years, I would like to discuss the three approaches to use breakpoints in our designs and recommend a slight modification so we can create better future proof designs.

Only Common Screen Sizes

This approach takes into consideration only the resolution and screen size of popular smartphones, tablets and desktops in order to create the breakpoints. But, it does not cover the resolutions of less known or future devices. This is like having a fixed width for several devices and ignoring less known screen resolutions. You will probably have to go back and add new media queries every now and then when new devices become mainstream.

Popular Screen Sizes and Fix in Between

As most designers design and plan their websites using external tools and not the browsers, they usually design for popular screen sizes. Then, tweak and fix for the resolutions that are in between the planned ones. This is a better approach because it is more future proof as you don’t know what screen sizes new devices may have. Also, you have an idea of how your design may look on devices that you don’t have and haven’t test with.

Breakpoints only

This is the most future proof because it is completely independent on the resolution of the devices. The breakpoints are located where the design itself breaks. So, in every device you design it will look as you expected because you create a fully device agnostic web page.

So, what is the problem?

The main problem is that even though we are creating a device agnostic design, we are not dealing with future modifications of the web page. Active websites usually evolve adding new pages and new content. For example, when we plan a menu with 5 items, we usually make the breakpoint right before last item goes to the next line. Instead, we should consider a 6th item for the breakpoint so we don’t have to go back and modify the CSS if the user decide to add another item to the menu. If we create breakpoints considering future changes , we will have a more future proof design that allows the client add new items to the menu without having to calling us that the design is not looking “right”.

Just remember that most studios or designers offer the CMS so clients can tweak and add content. Thus, if they decide to make some changes, the design should be flexible and allows them to make changes without modifying the CSS when a new item is added or an item is removed.

Teylor Feliz
Teylor Feliz

Teylor is a seasoned generalist that enjoys learning new things. He has over 20 years of experience wearing different hats that include software engineer, UX designer, full-stack developer, web designer, data analyst, database administrator, and others. He is the founder of Haketi, a small firm that provides services in design, development, and consulting.

Over the last ten years, he has taught hundreds of students at an undergraduate and graduate levels. He loves teaching and mentoring new designers and developers to navigate the rapid changing field of UX design and engineering.

Articles: 182