You’ll never guess what they said after I discovered this one thing about responsive grids…

Step 1. Add more babies.

Okay, grids are probably boring to a lot of people. There’s no magic trick, no ‘one thing’ I discovered that no one else has, but I did figure some things out that I think might be helpful for anyone who’s designing on a grid for web. It’s just math, but the real magic is delivering fluid, accessible designs that look good for everyone (or… most everyone).

So Policygenius just rolled out a big rebrand. After months of branding work, dozens of sketch files, hundreds of artboards, and thousands of engineering tickets, we launched a full rebrand of Policygenius.com to the world this week, along with a substantial ‘out of home’ campaign (Look for us on buses, trains, and billboards in NYC, SF, Chicago, and LA!).

We literally redesigned every single page, and touched every dark corner of legacy code. Luckily, we have a crack team of designers, engineers, and PMs who made it all happen. The toughest thing about this rebrand, was staying organized — which means everyone needed to get on the same page very quickly, and use the same components.

One grid to rule them all

As we were working out those first designs, our use of the grid was one of the first things we had to define to ensure every designer was working with consistent layouts. It seemed as though our old system could use some dusting off- an initial audit of the existing website turned up tons of layouts, with different grid rules. This was our chance to fix it all, so it had to be done right.

There are a lot of opinions out there for where your breakpoints should be, and we know that screens are getting bigger, and mobile traffic is increasing. It seems like the general theme coming out of the industry is ‘don’t use screen sizes to dictate your breakpoints, because screen sizes are going to always be changing.’ A quick scan through this table will prove how true that is…

So whats the right answer? Google probably knows right? They’ve documented how material works responsively, and provided optimal breakpoints: 480, 600, 840, 960, 1280, 1440, and 1600. Great! Except… if you resize this page where they define those rules, you’ll notice they’re not even following their own rules, with their designs breaking at 375, 800, 1240, and 1480… curious. Everyone seems to have different ‘best practices.’

Ultimately, I realized that there is no right answer; however, the more breakpoints you have, the more control you have as a designer to keep things looking good (like how Google suggests 7 breakpoints). It doesn’t really matter where they are, as long as you’re considering every size. So for those of you who have nice, big design and engineering teams and deadlines to create and maintain 7 layouts for every page, go for it. For us though, we needed to optimize because we were up against a tight timeline, and we did that the same way we optimize everything else — look at our own data, and design for the most common uses first.

Here’s what we found.

There’s a long tail of device sizes, but ~80% of visitors could be categorized by the most common device sizes. The usual, 375, 768, 1280, 1366, 1920 that we’re used to seeing.

Here’s where we settled on our breakpoints:

Mobile: 320 (the smallest most common)

Tablet: 768 (the size of the most common tablet)

Desktop 1025 (1 pixel up from Tablet landscape, and smaller desktops)

Since the desktop span is so huge though (now 1025 and up), we ended up deciding to design at 1280, and every new layout we create would need to be checked at 1025, and 1440 before passing to engineers, so we can be sure we’ve thought out how different elements need to scale, shift, or wrap. 1920 monitors just get more whitespace on the left and right. Eventually, I’d like to add a bigger breakpoint for these larger screens.

The overall idea here, is to design for the highest number of people, and consider worst case scenarios by designing at the lowest end of the breakpoint. As long as we know how it will scale up, more space isn’t as likely to cause more problems. Theoretically, these breakpoints could have been arbitrarily set, but why not define them by common devices?

Rolling it out

To ensure our new design language had clear and replicable rules across all the different possible layouts, and to make sure all designers are working at consistent sizes, it had to be as easy as possible to use. One thing that helped us stay organized within our design team throughout this rebrand, when our components were constantly being tweaked and changed, was consistency in our sketch files. We used Sketch’s Libraries feature (back when it was still in beta) to make sure we were all using the right elements.

Making the grid fluid

This is the goal: Isn’t she beautiful?

1. Set your gutter to a fixed width. 24 is what The Google uses, and all our components are sized to a factor of 6, so hey that’s good enough for us.
2. Build your symbol components

I made my gutters 5% opacity, and my column 20% opacity so I could tell them apart

Your left and right gutters will be their own symbols (make them half the width of your total gutter), and take a fixed width. Your right gutter pins to the right when resized, and your left gutter pins to the left.

3. Nest those symbols into another symbol, and add your center column in between. If you’re designing at 12 columns, the individual column width will be determined by the following formula:

([viewport or artboard size] - [left and right outer margin] x 2) / 12 (columns) - 24 (gutter).

So in my case, since I’m designing at 1280, its {[1280 - (64 x 2)] / 12} - 24 = 74. My column starting width. Ideally, this will be a number that was evenly divisible by 12, resulting in no decimal point values.

So for example, if I wanted to design at 1920, I would choose to make my margins something like 168 {[1920 - (168 x 2)] / 12} - 24 = 108. Play with the margins to get a reasonably divisible number.

1.) make your gutter symbol, and put those in a column symbol; 2.) drop that into a new symbol, and copy/paste it 12 times. 3.) Remove the two outside gutters. 4.) make it a symbol

When you’re finished, you’ll have your symboled fixed width left and right gutter in another symbol with your column (not fixed width), repeated 12 times in another symbol. So, its a symbol, in a symbol, in a symbol.

Then repeat this process for as many breakpoints as you have.

Now with Sketch Library, all our grids live in a global pattern library file, and we can drop one in from anywhere, giving no one any excuses for using the wrong grid or artboard size.

Note: Sketch isn’t great at doing math. Even if you’re doing a lot of resizing resizing your grid, a simple ‘round to pixel’ isn't going to make it perfect. Your gutters may get off a tiny bit, so it’s best to double check them after resizing. Thats why we still use one grid for each breakpoint — unfortunately, one grid to rule them all for every size just isn’t possible in Sketch yet (that I’ve seen).

Benefits of making a fluid grid:

• Available to every designer from our symbol library
• Standardizes the size of our artboards at each size, which reduces engineering churn
• The Fluid Grid resizes to allow for nested grids, while preserving static gutters
• Helps you predict what designs will look like between breakpoints

How did you determine your breakpoints and grid? Know a better way? Let me know!

Download the sketch file