Grids, why I love them, and why you should not run away from them

Grids, why I love them and why you should not run away from them

I am a designer, a UX/UI designer to be precise, and I love grids. But wait, which designer doesn’t? Okay, I know designers are not all the same and perhaps not all designers love grids, but we have to admit that in general designers do love their grids and there’s a reason for that. Grids are cool and very useful, this post is all about grids, why I love them, and why developers should have a better understanding of them.

Grids are used to design all kinds of things: logos, books, furniture, posters, flyers, websites, apps, webapps, icons, and so on. Whenever possible, I start with a grid, no matter what kind of project it is. It can be just what you need to break free from that fear of a blank sheet in front of you, and to start realizing all the potential stored in that [brand new] canvas.

Grids bring order; they help you decide sizes, proportions, and the placement of elements. Grids bring clarity and consistency; they help you collaborate and speed up production. A grid always works with, rather than against, the designer and the developer.

Grids are gradually shifting from mere helpers to an important part of the whole work process. If you are a developer you might think “Okay cool, this guy loves grids and the framework I love has a grid system, problem solved!” but what if I ask you to work with a grid that was specially designed for that project? You would have to develop that grid, and make it responsive and understand how it works across all platforms and have more work. Why? Because development frameworks take a “one size fits all” approach when it comes to grids and sometimes it’s okay to work with but that approach generally doesn’t work. For one reason or another I am never fully satisfied with the grids that most development frameworks provide, because they demand compromises I am not willing to make.

Grids are not static! These days, dynamic is a word we use a lot, and with good reason; things change all the time! Design needs to be fluid, to use more relative values, not absolute ones. Design needs to adapt to content, not dictate it. Design needs to accommodate, not disarrange.

In my process I take two things into consideration when preparing a digital grid. First one is screen sizes aren’t standard , and the second one is different projects have different needs. These starting points warn us that things need to adapt, breakpoints are not always going to be the same, the number of columns may vary, their size, the gutter between each column, if the grid has margins or not, all may vary.

Now, why do developers need to better understand grids? Because if you take part in this process there is as much in it for you as there is for a designer. You will gain independence, and will not need to constantly ask for changes. You will be faster in your work. Your code will be cleaner and tidier, in order to accommodate what the grid asks, and you will collaborate more, leaving time to what’s important. All this because you understood the grid, the structure, and how things move and evolve.

If you reached this far in this post, I will assume you are interested in grids (Who isn’t!?). So let me introduce you to some types of grids:

1. Responsive grid

The responsive grid is a grid scheme designed that uses around 12 columns and is complemented with gutters and margins. As the screen becomes smaller, the responsive grid adapts by losing columns in order to fit the screen, so for example in a 3 breakpoint scheme it would be: desktop 12 columns, tablet 8 columns and mobile 4 columns.

Responsive grids are great at adding order and balance and a great resource for less complex project.

2. Fluid grid

Fluid grids are similar to the regular responsive grid but these scale with browser size. There are several ways to do this, and one of my favorites is nested grids where smaller grids are nested into bigger ones, also fluid grids usually use relative values instead of absolute.

Fluid grids usually produce better mechanics for responsiveness since they are more agile and they prove to be a better option for more complex projects or heavy content projects.

3. 8-point grid

This system should be used in conjunction with another system (a fluid system for example), because the primary goal of this 8-point system is to create a consistent ratio of measurement (all sizes, paddings and spacings should be divisible by 8).

8-point grid systems are a great tool for teams because they create an easy system of communication between designers and developers (no fussing over pixels). A developer can easily eyeball an 8pt increment instead of having to measure each time.

There are plenty more grids to explore but these three are a good start, they can lead to some huge improvements in your work and help you in complex projects. Understand that when someone puts time and effort into a grid, it is usually not just because that person loves grids, but more so that they have studied the problem and have developed something that could help everyone. It’s not only about the user, it’s also about you.

I am UX/UI designer at Runtime Revolution who is quirky and loves a good laugh that has wonderful brain to memorize idiot things and forget important ones. I love all kinds of design and I’m all about making questions and finding solutions.