Understanding breakpoints — How to deliver meaningful specs to developers
A practical guide on the basics of web design, maintaining a healthy relationship with your web developers and avoid embarrassing questions
One of my first “real” jobs was working as a UI designer (that was the “product designer” version of 2012) in a large team with 8 experienced developers. Most of the things I delivered made absolutely no sense — not only it didn't look like an actual website — the developers asked many questions about that design that I didn't know how to answer.
Developers pointed out things like “This text wouldn't fit in one line when we translate the UI to Russian” ,”How would this layout work on a landscape iPhone?” and “How would this carousel behave on desktop without any buttons?”- It was obvious I had no idea what I was doing.
Now, after 8 years of working with web developers in several companies (and learning some front-end code myself )— I gathered some tips on web pages delivery that might also help some of you in your daily struggle.
One of the challenges in moving from print to web is starting to see layouts as flexible system of rules and not a single “printable” output.
tl;dr — Here are some guidelines on how to communicate design specs to developers:
- Design with rule-sets, not single frames
- Deliver breakpoints for one pixel before and one pixel after your breakpoint
- Design for a device you own first and use sketch mirror for small details before creating the edge-cases
- Touch interactions should be available on any breakpoint, not just mobile
Design with rule-sets, not single frames
There are infinitely many screens sizes, and the design you build should look good on either one of them. This means creating a system of rules that looks and behaves well on a narrow iPhone 5 as well as on 4K screens.
Understanding CSS measurements and behaviours might help in drafting these rules. These are a few basic ways to think of elements when designing a responsive layout:
Element size
Here are a few basic ways to determine an element’s size in a systematic way:
1. Fixed pixel width / height — the element has a fixed size on screen, that isn’t related to any other parameter
2. % of screen width — the element takes a given portion of the screen (browser) width
3. Maximum width / height boundary — the element takes as much space as given to it (100% of screen), up to a maximum defined boundary.
You can also set a minimum width / height parameter.
Element scroll behaviour
Another helpful way of defining these rules is thinking of the element’s scroll behaviour. Understanding your page isn’t static and the viewport is changing is a good start for drafting these rules. Here are some 3 basic scroll behaviours that are easy to explain and code:
1. No scroll behaviour— just like you would expect, the content is being scrolled in a normal manner
2. Fixed position — The element has a “fixed” position relative to the screen and it stays there while scrolling
Sticky position — When the element gets to a certain point on the screen, it becomes “fixed”.
Some useful tips regarding size and position:
- Think of what would happen in case of different texts. how exactly would this textbox behave without breaking the design? and a button label? how would it look with a multi-line layout?
- What would happen in case of right-to-left text and layout? how much would the design change?
- In what order would screen-readers (assistive tool for blind or visually impaired) would read the website? does it need to be accessible?
One pixel before, one pixel after
First, let’s explain what breakpoints are -
If you think of your page layout as a set of rules — a breakpoint is a specific window width that these rules would change for a certain element of the page.
Let’s imagine that on our website we use 40 pixels font size for a title when the screen is larger than 600 pixels width, and 20 pixels if the screen is smaller than 600 pixels, you would have a breakpoint at 600 pixels:
For delivery I usually use the one pixel before — one pixel after rule: for the developer to understand the breakpoint you should export a set of mock-ups that best describe the boundaries of the system. E.g. If we have a 2 column design that on screen width of 639px turns into one column, I should create a mock for 640PX (the narrowest state for the 2 column structure) and 639px (the widest state for the single column design) as such:
How many breakpoints should your design have? Most standard websites use 2 breakpoints (desktop and mobile sizes), so it’s a good place to start — but it really comes down to how complex your design is. 1–3 breakpoints should be enough for most simple web layouts.
Design for your screen first
These edge cases mocks are usually done during the delivery stage.
When starting the design process in a more free-formed manner I design for screen sizes that matches my personal devices, so I can appreciate the design in real size quickly and easily.
This practice is good for running small iterations on high-fidelity visual design and getting quick feedback from close by coworkers.
Plus, make sure you take a look at how text is displayed on a mobile screen before sending off the specs to developers. Text leading and kerning might look different on your laptop and on your phone due to the density of the display.
After completing the design in high fidelity for your desktop computer and mobile device — start drafting the edge cases
Can’t touch that
Back in 2007 — when designing a desktop website — you could use hover interaction (just hovering the mouse pointer on an object) for communicating its interactivity (like changing the color of a button or a link). After the first generation of touch-based devices became popular as a way of browsing the internet — designers could no longer use hover interactions on websites in the same way. Touch devices have no hover state. hovering your finger over the screen does absolutely nothing. Designers needed to find a better way of communicating elements are clickable and rethink tooltips and hover interactions.
Your designs need to be touch friendly for both desktop-sized breakpoints as well as mobile sized breakpoints — The size of the screen has nothing to do with it’s being a touch-based device. Some of the larger iPads are larger than my computer screen.
What does it mean to be touch friendly?
1. Mouse interactions (Hover, for example) must have an alternative touch interaction
2. Tap targets must be large enough for a thumb to tap on (~40PX hit area)
To make your developer’s life easier— try designing a similar behaviour for large and small screens that doesn’t use hover as a mandatory interaction (for example — a dropdown site menu that opens upon hover on desktop should also be opened on tap)
I hope these tips would help you to design better websites and to better understand how a website is built and functions.
If you are interested in understanding how a website is actually built and coded I strongly recommend looking at Code Academy’s css lessons. Just understanding the basic structure and what is possible would make you a better web designer by 10X.
