Breakpoints, Margins & Gutters. Frameworks have their own recommendations, but your project may have its own needs.
Desktops, tablets and phones, oh, my!
While each website is unique, the fact is that more than half of the internet traffic these days comes from phones. Back in the day (like 5 whole years ago) folks trying to keep up to date with the growing worked to make their websites ‘mobile ready’. These days, however, the saying is ‘mobile first’.
What does ‘mobile first’ mean? It means a couple of things.
First, it means that, since most of your traffic is likely to be mobile, that mobile is important enough that it should be considered at the very beginning. Not as an afterthought or nice-t0-have. If your main focus is on the desktop, you’re PROBABLY wrong.
Second, mobile first is a design mindset. If you can design the site for a phone, it will also work on the desktop. Not always so the other way around. And even if you CAN squash your beautiful desktop site or app onto a phone, it often takes longer and costs more to work in that direction.
Does this mean that desktop designs are going away? No. While its true that more initial connections are made on the phone and tablet, many sites still have longer engagement times on desktop. So, folks use the phone for search and quick information hits, but if they are going to spend lots of time on a site, are more likely to follow up with a visit from their desktop.
So, design for the phone first, and work up.
In addition, with some forethought, you can minimize the amount of work you do when building responsiveness into your designs (see image above). Sure, you COULD program for 5, 6, 7 or more distinct sizes, but you may not have to.
Each development team has its own way of handling things. Whether I’m designing for infinite breakpoints, or fixed breakpoints, a critical deliverable for web applications are the component specs. Each individual component should have its own set of specifications, showing where it breaks, how it breaks, and how it interacts with the neighboring components in the application.
When necessary, that is.
Modern tools have made most of this very time-consuming work a thing of the past. Still, there are always places where the designer needs to call out items that might not be obvious in tools such as InVision Inspect, Avocode or Zeplin.
These items were spec’d out old-school. By hand. In Photoshop. Likely, to the delight of both you and me, we won’t see anything like that ever again. 🙂
Often, templates have fixed breakpoints. In this case, you need to account for design shifts across these predetermined breakpoints.