Designing with developers in mind: guides, grids, and frameworks

Sure, just about any design is possible as a website—but it doesn’t mean it’s necessarily the best design for the medium.

Especially because responsive design is no longer a luxury, but a necessity, designs for the web need to be thought about as fluid canvasses that both look good and react at all different screen sizes.

As I made the transition from designer to designer/developer, I learned what to pay attention to (or outright avoid) once I had to actually turn my designs into working code. To help you design more flexible, fundamentally sound mockups that will result in cleaner code and fewer angry outbursts, I’m sharing 7 things you can do to design with your developers in mind.

They’ll thank you later. I promise.

1. Know your canvas sizes, margins, paddings, etc.

There’s nothing worse for you or your devs than when you submit a pixel-perfect mockup of your website, and in production it looks completely different: icons shoved too close to text, no breathing room between columns, and a row that wraps to a second, unwanted line.

So what went wrong? Most likely, your canvas size or global margins and padding were off from the start.

Know these things ahead of time:

• Whether the framework your site is built on has specific paddings at different window sizes
• The gutter width between columns
• How narrow the smallest screen size is that you will support

A matter of 5 pixels can literally make or break your designs—and have both you and your devs throwing your hands up in frustration.

2. Use a grid. Know your grid.

In relation to knowing your global measurements, find out or establish early what your grid system will look like.

And if you’re not using a grid, you should seriously consider it.

Many popular frameworks such as Bootstrap and the 960 Grid employ a 12-column system. Why 12 columns? 12 is the most easily divisible among reasonably small numbers. You can have 12, 6, 4, 3, 2, or 1 evenly spaced columns, which makes your design decisions a lot easier when you work with these restrictions in mind.

Using a grid also allows your developers to pre-set classes in their code that correspond to these column sizes so they don’t have to individually size each block you create.

See how this is a win-win?

Related: Sign up for our free e-course, Designing with your developer in mind

Most layout programs have solid grid-based design tools at your disposal. I almost exclusively use Sketch for website layout, due in large part to their built-in grid and layout options. You can also find templates or guide settings in both Photoshop or Illustrator for almost all popular grid frameworks, or at the very least you can take a few extra minutes to set up guides.

By far, being on the same page with your global framework settings will be your biggest time saver and stress-reducer when starting a new design project.

3. Keep things within “the flow of the document”

Designers love to strategically break style rules to increase visual interest or add emphasis. Whether it’s purposely breaking alignment, slightly oversizing a container to stick out just above its neighbors, or overlaying a callout on top of less-important items, taking things “out of the flow of the document” can have ill effects on creating a seamless responsive design.

Imagine you have a rectangular box that folds and expands into 3 different sizes (i.e. desktop, tablet, phone).

Within that container, you place little square objects that have a magnet on their left side that will attach to anything. If you place these squares next to each other, they fit into a nice row attaching at the left edge.

If you collapse the box to smaller size and the container becomes too narrow for all of the squares to fit, the last square in the row simply falls down to the row under it and the magnet pulls it over to the left (i.e. blocks of content in columns).

When you add or remove blocks, the rows either get longer or shorter, but the blocks all move accordingly in relation to each other to fill the empty space.

“UI design is all about getting users as familiar with your site in as little time and with as little brainpower as possible.”

Still with me?

Now, if you add a new block that has no magnets and lay it on top of the other blocks (think layers), this new block is out of the “flow” of these little magnetic squares, and is basically on a layer of its own.

Moving the blocks underneath has no effect on the non-magnetic block, and if you want it in relation to a particular set of blocks, you have to manually move it when the order of squares or the size of the container changes.

Confused? Probably. Let’s look at a visual.

Here we have a container at full size. The blocks fit nicely into 3 columns, numbered 1, 2, 3.

When we make the container smaller, the third block in the row moves down and is sucked to the left of the row underneath. All the blocks are still in order, however.

Finally, when the container gets even smaller, they all sit in their own row—still in order.

Now let’s place a non-magnetized block on top of the “*1*” and “*2*” in the second row and see what happens.

In order to do this, I have to give the exact coordinates for where I want the non-magnetized block to sit. This is called using absolute positioning. We’ll give it a black outline and a semi-opaque white background to see what’s underneath it.

You can see that the bottom layer isn’t affected and remains in place underneath the new layer. By absolutely positioning the new block, we took it out of the “flow” of the blocks underneath and it just sits on top.

Here’s where it becomes a problem when you try to make your designs responsive. If we make the container smaller, the blocks underneath do their shifting thing and collapse into smaller rows. The non-magnetic block, however, is still in the exact coordinates that it started in relation to the container.

If we wanted it to stay on top of our block #*1* and #*2*, we’d have to manually give it new coordinates. If we make the container even smaller, it’s now just hanging off of another block because, again, we took it out of the “flow.”

You can see that placing objects that don’t fit and move with the grid require you to manually position them every time your window size changes. This means a lot more work to keep them where you want them—and more dev time.

Think about this next time you’re creating a layout. Is placing the item in an exact position worth the extra work and harder-to-maintain codebase that your developers will have to deal with? If the answer is no, figure out a way to make it look good within the grid. If not, now that you know the cost, you can choose your battles and sound smart by explaining why absolute positioning is a must.

4. Keep elements to the left, right, or bottom of each other when they degrade to smaller sizes

When your design calls for a lot of columns, or your rows have a lot of elements, sometimes things need to change position in order to fit on smaller screens. While this is good practice, elements can generally only move to the left, right, or below each other. Moving items further than one element from each other usually results in having to duplicate code and/or use some extra scripting to pull off.

Here’s the basic principle: code is written in lines, or multiple lines forming blocks. Without any CSS, the elements these lines and blocks form would either be next to each other from left to right, or stacked on top of each other, depending on the type of HTML tag.

With CSS, we can easily tell elements to stick (or “float”) to the left or right. If we want an item to fall above or below these elements, we can tell them to “clear” each other. If we want to position an element anywhere else, we take them out of the flow of the document, which we just learned is going to be met with some resistance from your development team at the very least, and cause a bad responsive experience at its worst.

If we want to move items away from the elements next to it without using absolute positioning, we need to have the code written in 2 places (one where it appears in the flow on large screens and one where it appears on small screens). We then need to hide the non-active block with CSS or Javascript. This obviously creates extra lines of code to write and maintain, which should be avoided if possible.

5. Stay consistent with icons and the rules you create

User interface design is all about getting users as familiar with your site in as little time and with as little brainpower as possible.

In order to do this, we use familiar symbols to establish rules and communicate information or actions. Think of the hamburger symbol for navigation, or a plus symbol to signify an accordion toggle. These are well-known symbols that any semi-regular web user should be familiar with.

But the problem is that there are many acceptable symbols that signify the same action, and many actions the same symbol can signify. Aaaaack!

A vertical ellipsis does a fine job signifying navigation, and a down arrow is also an acceptable trigger for an accordion. A plus symbol could very clearly mean add a new post to a blog, and the hamburger is also used as a drag-and-drop “reorder” icon.

What’s important to remember is to keep these action/symbol pairs consistent within your own site—have your own set of rules.

If you’re using up/down arrows in one place to signify toggle, don’t use plus/minus in another section, etc. Take a walk inside the logical brain of your developers for this one. Is there really a good reason you’re changing the icon, or did you just download a shiny new icon set and your undying creativity is getting the better of your judgment?

Staying consistent keeps your developers happy—plus it’s a best-practice principle in good UX design.

6. Don’t bother changing font sizes at every breakpoint

This one probably falls more in the “keep your developers happy” camp than improving user experience, but it’s easy to get carried away with different font sizes as you design for smaller screen sizes.

Sure, your 60pt headlines are probably too big for mobile screens, but do you need to change them 4 times between large desktop displays and your smallest devices? As long as the layout doesn’t break because the fonts are too big or small, your users will think you chose those sizes for a reason.

I like to stick to no more than 3 different font-size changes for the same element. When there’s no direct benefit to the user, smaller codebase and shorter development times are a win.

7. Curves=headaches

This one almost feels a little dirty to write considering how prevalent curves are in design, but it’s something that designers take for granted and should be discussed.

When you have a graphic interface like Illustrator or Sketch, curves are pretty simple to create: drag some bezier points on a line and you’ve got yourself a curved segment. What’s really going on, though, is some serious mathematical equations at work between those 2 mouse positions.

It’s easy to realize how difficult creating curves can be in code when trying to explain them in plain language. A line is “the distance between 2 points.” To get the definition of a curve, read the Wikipedia entry and tell me if your brain doesn’t endure a minor internal explosion within 30 seconds.

The point is, creating curved segments in code is a tedious task. CSS3 and HTML5 have made things like rounded corners and spheres a non-issue, but any irregular curvature is most likely going to have to be achieved with images.

The problem with images in responsive design is that they’re pixel-based and rigid. Changing the thickness or shape at any point results in a whole separate image file to include in the code, another HTML request from the browser, and more moving parts in the code where things can go wrong.

Responsive design is about being flexible and fluid, and image-based layout elements—like those curves—are the antithesis of this.

Feel free to disregard anything I just said

I get it: you’re a designer. I’m a designer, too.

In order for your design to communicate effectively, or to match your brand, or to differentiate from your competitors, you need to break these “rules.” That’s definitely going to happen, and many times it’s the right thing to do. At least 3 of these pointers came from mistakes and contrary decisions I made in recent projects.

The point of this article, however, is for you to understand the cost of neglecting these suggestions. When you know that absolutely positioning a flower at the base of your footer or dividing your page in the shape of a handwritten “s” is going to cause challenges, you can evaluate the cost/benefit and make better decisions.

When you can articulate to your developers that you understand their process, they’ll be more likely to help find a helpful compromise to design solutions than draw a line in the sand.

When your creative mind and their analytical genius can work in unison, better products will result. And that’s what it’s all about.

Read more about designing with developers

Learn to work with developers, not against them, in this free e-course by Kevin Tomasso and InVision. Sign up here to get the other chapters of this e-course delivered straight to your inbox, completely free.