Recently, I was asked by a designer client to review a design he was working on. He hadn’t yet designed for responsive, and he was curious about things to keep in mind while he was designing. This proved to be a good exercise for me as it allowed me to document some things I’ve learned over the past few years, and I thought it might be helpful to share them here.
Content Priority
This first consideration is less a design thing than a planning thing, but it’s super important for the designer. At Sparkbox, we religiously map out the order that the content should appear on each page when at the smallest browser width. We call this the Content Priority. It’s helpful for the designer as it allows us to make informed decisions and helps us know where content should go if we decide to have content side by side on desktop width for example.
Think About How Things Respond
Okay, captain obvious, thanks for the tip! Seriously though, if you’re designing at desktop width and in a creative zone (or in a hurry), it’s easy to overlook how groupings of content collapse down at smaller viewport widths. Hopefully you know where the content should go at these smaller widths (Content Priority FTW).
The other day, I designed a module to a website that had text on the left and an image on the right. Both these elements were contained inside a white box, and the photo was cropped on the top, left, and bottom. Even though the photo had a white background, a shadow bled off the top and created an issue when, at smaller viewports, it appeared below the text. There was an abrupt transition below the text to the image when my plan was to have the white bleed into the photo. Completely missed it until we got into dev, which leads us to the next point...
Where does it break?
Inevitably, there are going to be things that you either don’t anticipate or don’t know how to handle when content is displayed in smaller viewports. That’s okay. In fact, I’ve found it’s often better to leave as much of this as possible for the browser because A) things appear very different when viewed and interacted with in the browser and B) it allows our frontend developers to make some design decisions and come up with something maybe I wouldn’t have thought of.
For us, a lot of design of the sites we build happens in the browser, by seeing when the design breaks down and addressing those elements when that happens. Often, we’re asked about what breakpoints to use, but with new devices being released so frequently, it makes sense to create breakpoints when needed as the design requires it. It’s like Stephen Hay said, “it doesn’t matter how many pixels it is or how many ems it is. Where it breaks, that’s your breakpoint. Hence the name ‘breakpoint’.”
Reuse of Styles
This is one I often struggle with. As a designer who’s not building production code, it’s easy to crank along in Photoshop or Sketch and create tons of variations on styles. For example, I tend to create many different shades of gray to achieve just the look that’s right. Well, this drives devs crazy because in actuality, we could probably use just a few to achieve a great design with far less budget impact.
Source Order
HTML source order is important to keep in mind because it can often affect design as it gets translated across viewport widths. Why? Take for example, if at a desktop viewport width you have a sidebar column with a search field. When the viewport is at its smallest width, the sidebar elements may then appear below the main content. This means you’ve placed the priority of the search field lower than almost anything else on the page, and that may not be desired. While there are ways around this using JavaScript, it’s always nice to make the source order work to your advantage whenever possible and start to talk about how the code is structured during the design phase.
Stacking Items
Displaying images or text or a combination of the two in multiple columns on a desktop viewport width is a nice way to display like content. However, it’s good to keep in mind what happens to these items when the viewport width is smaller. You may know that on smallest width, these items will simply stack. But what happens if you have 3 columns of information at a tablet width? What about 4? What if your client manages content and there could be any number? Obviously, this presents challenges. Many times, these problems can be solved in-browser and sometimes with the creation of optional styles such as full, half, or third-width versions of the specific module you’re working on to give the client options that don’t make the design fall apart.
Performance
This is a hot topic now in responsive web design. One of the “knocks” on responsive web design is that it performs poorly and drives up load time. We believe that it’s not an issue of responsive web design, but the lack of making effort to address the true problems when building a site. Designers love to load the page with beautiful, full-width photos and videos, which can be great. Just make sure to keep performance in mind and keep the lines of communication open with the rest of the team.
Navigation
We spend a lot of time working on site navigation. There’s a lot to consider here: What kind of trigger will be used to open the nav at small viewport widths? The hamburger icon? Something else? If it’s a multi-level navigation, designing expandable menus for mobile devices is an art form in itself. Make sure to know how users want to navigate and where you or your client want to drive traffic as that could–and should–play an important part in how the navigation is designed. For example, is the desire for the user to drill down into the menu as deep as possible, or is there a desire for the user to hit a “parent” level page that has content or products that will help the user navigate?
Javascript fallbacks
We all love beautiful transitions and animations that make websites a joy to experience. I believe these are important, and often necessary, polish items that can give context to the user when the navigation opens or content is revealed. However, keep in mind that you should implement fallbacks for those users with javascript turned off. I’ve seen a few examples of this where main navigation wouldn’t work with javascript off, which is obviously a bad thing.
Typography
There’s much attention that needs to be paid to typography as the viewport width changes. Type sizes, line lengths, paragraph spacing, and margins all may need to be adjusted. Headlines reflow and may need to be re-evaluated at various widths. Spacing between content sections may need to be emphasized more at smaller widths. It makes most sense to tweak this in browser as you can test typography on actual devices.
And Also...
This is obviously not an exhaustive checklist. It’s simply things I’ve found that are helpful for me to think about when designing a responsive website. I’m sure there are other important considerations too–some specific to designers, developers, or both.
