Case Study: Elefint’s Responsive Website Redesign
Elefint recently underwent a responsive website redesign. This turned out to be a challenging and confusing process, and finding resources to guide us through it wasn’t easy. A lot of the information we used to guide us was contradictory or incomplete, and we figured there must be a lot of people equally perplexed. With this in mind, we put together this history of our process with the hope that it would be useful to other designers and organizations venturing into the world of responsive design.
Review of responsive web design
Let’s start with a quick review of responsive design. With the multitude of devices that exist today ranging in size from big screen televisions to mobile phones, it’s not practical to design a site for each of these experiences. We say experiences rather than devices to highlight the fact that we tend to use the internet differently on a tablet than on a TV. The differences between these devices are not just sizes but the types of things we prefer and are likely to do on them, such as opening a new account (better on desktop) or quickly checking for updates (convenient on mobile). With people accessing the internet more and more from these devices each year, investing in a responsive site is an important consideration for any redesign.
We began our redesign by listing the needs different users were likely to have on each platform. On a white board we created four columns, one for each device type: mobile, tablet, desktop, and TV. We started with desktop and then added and subtracted features based on each device. For example, we had hover states that explained each of our services on desktop. Since there is no hover state capability on tablet and mobile, we removed this feature for those devices. We did things like moving the navigation from the top of the screen on desktop to a dropdown on mobile, a style that has become common as it is much easier to use on mobile and takes up less space.
An important lesson we learned is to design iteratively. We chose to go one page at a time for each device, designing for example the home page on each device before moving on to the next page. This turned out to be a good strategy as we caught systemic issues before we had created a large number of designs. One of the early adjustments we made was to mostly drop tablet and TV from our process. We found that for our particular site, the added value of designing for these formats was not worth the added effort. All we really needed to do was to design a slightly different header for tablet.
A big point of confusion for us was around how much we needed to design to give the development team everything they would need. This was one of the points where conflicting information was available in abundance. Even when designing just for mobile and desktop, creating modified layouts for each format is a lot of work, so we didn’t want to do anything more than we needed to. At the same time, we wanted to maintain the integrity of our design, and didn’t want to leave our developers with too much guesswork.
Retina, DPI, PPI
One of the most fun parts of designing a responsive site is wasting tons of time grabbing the lower right corner of your browser and resizing it to see how the site responds. This is especially great at breakpoints, the dimensions of the site where the appearance of the site jumps from one device type to the next. Figuring out exactly where these breakpoints should be can also be pretty confusing. Not only are there multiple mobile and tablet sizes, but the physical dimensions of the screens aren’t what matter. Viewports tell the device how to treat the site, and those are what you have to watch out for. For example take a look at a responsive site on an iPad and an iPad mini. You will see that even though the devices are very different in size, the page will display the same. Thats because Apple has made the viewports the same, essentially telling browsers to act as if the devices were the same size. If you and your friends own every Apple and Android device known to man, you can play around with these different viewports and see how they react. If you don’t have access to all these toys, or if you just want to save time, you should be fine designing for common breakpoints – 320px (mobile), 768px (tablet), and 1024px (desktop). This is another place where iteration is key. If you have in house developers and/or can afford to test things as you go along, play with the breakpoints and make sure they work for your content.
Designing a responsive site can be pretty overwhelming. Like most things on the web, this process is bound to get easier as more and more people design this way, and more and more tools are created to aid designers and developers. Until that day, here are a few suggestions:
- Don’t let the perfect be the enemy of the realistic. Just start designing even if you don’t understand all the dynamics, and you will figure it out as you go. Responsive design is complicated, especially when you introduce things like Retina images. There are many ideal practices that may not be in-line with your budget and/or timeline, such as designing for many device types or building breakpoints around content, so do what you can.
- Bring as many members of the team together as early as possible. If everyone from the strategist to the developers can weigh in early, the process will go much smoother.
- This can take a long time, especially the first time around. Proceed in bite-sized but consistent chunks, and you will get there eventually. Busy with client work, we took about six months to finish our site.
Here are some resources that we found really useful in our redesign:
- http://ami.responsivedesign.is/ (didn’t actually use this one, but I think it’s cool. You can plug in any url and see how your site will look on different devices. I put in our old site when it was still up and then our new site when it was done, and the difference was awesome. Should have taken a screenshot!
- http://upstatement.com/blog/2012/01/how-to-approach-a-responsive-design/ I found this article really helpful when we were redesigning. One of the few articles out there that talked about the design side and not just coding.
- http://bradfrostweb.com/blog/web/responsive-nav-patterns/ This guy’s list of responsive navigation patterns was supremely helpful when tackling that particular part of our site.
- http://mobilewebbestpractices.com/ A collection of best practices that I often referred to. Also, a beautiful example of a responsive site!