When designing for the web, it’s vitally important to understand and design for different screen sizes. Since it’s impossible to design for every device and every width, developers have created media queries that make it easy to display different layouts depending on screen size. Here, I’ll discuss my philosophy about designing for different widths.
The popular mode of thought for a while was to begin designing mobile first. While some projects might benefit from this type of thinking, for me, it’s best to start with the most common use case. Do most users navigate to the site via their desktop? If so, I think it’s best to start there, while always keeping in mind that the content will need to display on mobile as well.
While some large projects and teams might be easier to manage with universal breakpoints, best practice says breakpoints should be determined by content. Once you have your content in place, design tools like Sketch make it easy to scale the width of designs. Start narrow (mobile) or wide (desktop) and scale the width up or down, to see where it starts to fall apart or become too congested. Where ever that is, that’s your breakpoint.
It’s critical to note, that whatever you decide as a breakpoint, every window that is 1px less than that number will snap to the next smaller layout. That could mean, for example, if you have a breakpoint on a three-column design at 730px, and your next breakpoint is 400px where items are stacked in a single column, any layout from 729px down will display as a single column. That could mean you have an enormous image taking up 1/3 of the screen on a tablet. If that’s not acceptable, then maybe you add another breakpoint that features a two column layout between 730px and 400px.
To preface, I am of the opinion that all content should be available at all display widths. Unless there’s a feature that simply doesn’t pertain to a mobile user, for example, it should be included in the mobile layout.
Starting at the top of the page, the header needs to condense in order to display properly as the width narrows. On mobile, maybe all a user sees is a logo, hamburger menu icon, and a search icon. Simplicity and usability are key.
Next, images clearly need to scale. Seeing a poorly cropped image on a mobile site, or an image that forces the user to scroll left and right creates a poor experience.
As display width reduces, long content boxes may need to hide behind ‘read more’ buttons to help users more easily bypass sections they don’t need to see.
Column count and column width will need to reduce as the display narrows. Mobile designs probably won’t display 5 columns of content very well.
Finally, we come to fonts. I have seen, more times than I can count, designers reduce font size as display widths narrows. Like they think a user’s vision becomes markedly more acute when they look at their mobile device. If a user has a hard time reading 6pt fonts on desktop, it’s not going to be any easier to read 6pt fonts on a mobile device. It’s possible headline fonts may need to reduce slightly as not to overtake a mobile screen, but in terms of body text, keep it consistent across device widths.
Want to really get to the heart of breakpoints? Get Twitter Bootstrap and build a site. There’s no better way to understand how breakpoints work, and how best to utilize them in your work than to actually do the development work yourself. You’ll be a more informed designer and your development team will appreciate it.
Lately I’ve been asked to enumerate my UX design process. My answers have involved use cases for perfect-world processes involving teams, collaboration, and iteration.
What is process? This is the fundamental question that must be answered before any meaningful progress can be made.
Who is consistently the last one to leave at the end of the day? Who updates tasks and tickets just before they tuck in for the night?