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.

Our process

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

To complicate matters even more, we decided to include Retina images (those formatted for high definition screens like Apple’s Retina display).  After a fair amount of research a friend of ours directed us to retina.js, a javascript tool that automatically converts images to the appropriate format.  Using this tool, we simply needed to create one image for all resolutions.  These images are the same resolution as standard definition screens, but are twice as wide and twice as high.  Retina.js then shrinks the images to the size we want them, and they therefore show up as much denser higher quality images.  If a non-retina screen is detected, a standard resolution image is substituted automatically.  Side note: if you are looking in the same places as us, you may find long and confusing discussions about the difference between DPI and PPI.  We spent a long time trying to understand the deep dark mysteries of web resolution, only to find out that it didn’t really matter.

Breakpoints, Viewports

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.

Our Advice

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:




Our site is being re-designed and updated as we speak. Please be patient, while you peruse through our old site.

Got it