The top responsive web design problems ... and how to avoid them!

The information contained here is based on hundreds of survey responses (if you’d like to add your own answers, the survey itself is still open) along with problems I’ve also come across in my own work at Offroadcode. So without further ado, let's reveal what the most common responsive web design problems are ... and how you can avoid them.

The most common RWD problems

Despite responsive design already having been around more than two years, it’s still in many ways a fledgling methodology. Designers are faced with an ever-changing landscape of devices, code frameworks and scripts – and, of course, the need to work in a new way with clients to manage the process of creating responsive websites.

All of these feature in the most common problems reported by survey respondents, which were:

1. Explaining RWD to clients
2. The lack of a static design phase
3. Navigation
4. Images
5. Tables
6. Converting old fixed-width sites
7. What to serve users of old versions of IE
8. Testing time and cost

Problem 1: Explaining RWD to clients

The 'old' process of designing a website was a very linear one, which made it easy for clients to understand. They’d go through a briefing stage, then some sort of wireframing and structural planning stage, then they'd get a set of pixel-perfect visuals to pick apart. Only when were these signed off would the site itself be completed.

As I’m sure many of you have found, this process is simply not up to scratch any more. One of the things many designers are struggling with is how to explain to clients that there isn’t really a 'visuals stage' any more. Responsive design is a much more fluid process and wireframing, sketching and prototyping are typically more powerful tools.

The solution: Demonstrate the power of responsive design

A better way to explain responsive design is to actually show a client what it can do. Don’t just talk about breakpoints and media queries and multi-device functionality – it’s easy to forget how meaningless these terms can be, even if some of them sound very obvious.

A great way to get any concept across is to show it in action. If you’ve got access to a laptop, tablet and a phone in a client meeting, you could demo how a site (perhaps one you’ve already built for another client) displays and behaves in different environments. This is simple and effective, particularly if you compare it to how a non-responsive site works on different devices.

If you can’t show a site on a range of devices, conside demoing one of the many sites that mimic typical responsive breakpoints, such as responsive.is or Responsive Layouts, Responsively Wireframed (pictured above).

Problem 2: The lack of a static design phase

As I mentioned earlier, one of the big problems designers reported was that a change in the 'old' design process is required to make the most of responsive design. Rather than creating static screenshots, designers rely even more than ever on quick sketches, wireframing and making rapid HTML and CSS prototypes by 'designing' in the browser.

The solution: Design more elements and fewer layouts

Before we look at possible solutions, I should point out that processes and workflow can vary. I’m a big fan of using whatever gets results, so if you’re happy with your process, stick with what works for your and your clients.

However, my own personal preference is for making as much use as possible of paper as normal, but using it to test ideas at different sizes. It’s quick and easy if you follow Sam Hardacre’s great suggestion for responsive sketching.

I also recommend designing in the browser and working with HTML as early as possible, then using Fireworks/Photoshop for creating assets rather than full layouts.

In bigger projects, you may struggle to even wireframe everything. A good idea here is to take a tip from Dan Mall’s case study on the redesign of Crayola.com and create paper/wireframe widgets that you can move around. It gives you a great deal of flexibility and enables clients to provide solid input.

For some useful information on other people's personal workflows, you can also check out Stephen Hay’s responsive design workflow slides or a very detailed overview from Yellow Pencil on its responsiveprocess.com website.

Problem 3: Navigation

In the past, navigation on sites tended to be horizontal along the top of the page, or sometimes down the left of a page. It now needs a more considered approach. The number of responses to the survey that mention navigation reflect just what a tricky problem this is to solve – and not one that has a simple canned solution.

The solution: Use good, consistent design

Choice of navigation strategy is is a wide-reaching decision, and should be based on your site's content and information architecture, along with a number of design considerations. Rather than simply downloading a script or demo, I'd encourage you first to evaluate how it works, why does what it does – and most importantly, how it works for the site you’re building.

The following articles may be useful here:

• Responsive navigation patterns, by Brad Frost
• We need a standard show navigation icon for navigation, by Andy Clarke
• Don’t let your menu take over, by Stu Robson
• Scalable navigation patterns in responsive web design, by Palantir's Michael Mesker

And remember: test how your navigation works on as many devices as possible, and in as many cases as possible. It’s amazing how often I come across sites where the navigation just doesn’t work in any sensible way. Don’t be responsible for creating one of them.

Problem 4: Images

Much like navigation, the set of options available for handling images in responsive designs is incredibly fragmented. As yet, the W3C community group hasn't backed a specification, so we’re left with what amounts to a personal choice of a wide range of scripts to fill in for this missing functionality, and deliver appropriate assets to devices.

To further complicate things, designers must also consider the next generation of devices with high-pixel-density displays such as the new iPad and Macbook Pro, along with a range of non-Apple hardware. Like code, images and icons should be as flexible as possible to ensure that graphics on high-pixel-density devices don't look blurry because they’ve been scaled up poorly.

The solution: Scripts, SVG and icon fonts

While there may not be an 'official' solution for responsive images, there are some really great solutions out there that are good to use right now, and give us positive results without resorting to too many hacks or code workarounds.

Here is a selection of techniques and resources to consider on your projects to cover adaptive images and differing pixel-density displays and devices:

• Adaptive Images by Matt Wilcox
• Using SVG graphics today, by Josh Emerson
• Resolution independence with SVG, by David Bushell
• Using CSS sprites to optimize your website for Retina displays, by Maykel Loomans
• Flowchart: how to retinafy your website, by Thomas Fuchs
• Symbolset icon fonts, by Oak Studios

Problem 5: Tables

A number of survey responses mentioned data tables as being problematic, particularly when they had to contain complex information or simply a large number of rows and columns. Squashing all of this information into a small-screen device in a usable way remains a challenge that I’m not sure has been adequately solved. However, some promising steps are being taken.

The solution: Take your pick of the different options

Chris Coyier has blogged reviewing a number of well-thought-out suggestions for tables. Having worked for several years with travel websites, which often involve large, detailed flight timetables, I have to say that none of the solutions outlined by Chris quite met those requirements. However, for most use cases, I’m confident there’s an option for your site that would at least provide a good foundation on which to build.

A couple of particularly strong responsive table options are:

• Responsive Tables, from Zurb
• Responsive Tables, from David Bushell
• Break a table out of its container (creator unknown)

I have seen a couple of solutions where hiding "less important data" is suggested. While I appreciate the experimental nature of the tables, I would personally recommend against the practice of hiding content from users depending on their viewing device.

Problem 6: Converting old fixed-width sites

One of the biggest issues reported in the survey was the problem of how to update the code base of an old fixed-width site to make it responsive – and indeed, whether you should. As I mentioned above, the responsive design process is often quite different to the old fixed-layout design process, and code is engineered in a less flexible way.

The question of what to do when faced with updating an old site is whether to reverse engineer existing templates and stylesheets, or to opt for a greenfield rebuild.

The solution: Aim for a greenfield rebuild

Almost without exception, those surveyed said either that they’d opted for a greenfield rebuild of templates and stylesheets, or that they only reverse engineered code because there were other factors involved and they had no choice.

Typically, older fixed-size websites didn’t need to take into account mobile-first design, and the sometimes different ways in which content must be structured. While it’s possible to reverse engineer code to make it responsive, on bigger sites it’s almost certainly going to be easier (and actually quicker) to rebuild than to work backwards.

Problem 7: What to serve users of old versions of IE

I’m sure you’ve all been waiting to for me to mention Internet Explorer in a negative light. I can indeed confirm that when working with older versions of the browser (IE8 and earlier), the main issue you’ll encounter is the lack of support for CSS media queries. This means that if you’re working with a mobile-first technique such as 320 and Up, your media queries won’t kick in and your layout won’t display properly on desktop browsers, so you’ll effectively end up with a small-screen layout on a big screen.

The solution: Polyfill or gracefully let go

The bad news is that, despite the wishful thinking of the design world (and to be fair, actual progress from Microsoft), you do still need to consider older versions of Internet Explorer (particularly 8) when you plan a site. The good news is we have some strong options for supporting older versions of IE while pushing forward creating great responsive sites.

If you’re keen to maintain your layout as much as possible in older IEs, consider conditionally including the respond.js polyfill from Scott Jehl in your pages. For a fuller explanation of options, I recommend reading Techniques For Gracefully Degrading Media Queries, by Lewis Nyman.

If you’re looking to phase out support for older versions of the browser while keeping content accessible, it may be worth considering … doing nothing. If you’ve built your site mobile-first and you don’t include a script like respond.js, your old IE users will effectively see your mobile view.

This may not be a perfect experience on a bigger monitor but at least the content remains accessible. Failing that, you could consider a simple conditional IE stylesheet and add in some rudimentary styling (fixed widths) because a simple linear view may not be best for a lot of users.

In my opinion, what to serve users of old versions of Internet Explorer comes down to the requirements of your client. I just ask that you don’t discount versions of IE earlier than 9 without at least considering the people using them.

Problem 8: Testing time and cost

One of the most common answers in the survey was the issue of testing: how to test, what devices to test with, and the potentially huge cost of building a test suite of devices.

For many designers, especially freelancers and very small businesses, it’s difficult to build up a test suite much beyond the devices you own personally. This came across loud and clear in the survey. Many people are making do with browser inspection and window dragging, along with testing on a personal handset and maybe a tablet. Obviously, this isn’t ideal. Building even a modest collection of devices is now a necessary business expense.

Testing time is also an issue. Although the time needed to test a site has certainly risen, I do feel that some of this is offset by better prototyping, designing in the browser and less reliance on static, fixed-size visuals.

The solution: Share devices and keep resizing

It’s great to see bigger agencies such as Clearleft sharing their huge range of test devices with anyone who wants to visit their offices. While this is not yet commonplace, I’m confident local creative communities can do their bit to get organised and at least discuss this sort of initiative.

If you’re interested in seeing what other fellow designers have in their testing toolkits, I recommend taking a look at Stu Robson’s My Test Suite site. Brad Frost has also written a useful guide to how to test on real devices without breaking the bank.

There’s no substitute for testing on real devices but if you can’t afford to put together a large device collection, you can at least make sure the bigger parts of your site work as expected by using one of the many responsive testing tools, bookmarklets and frames. It all helps!

Fill out the survey yourself!

Thanks for staying with me, and thank you to everyone who has filled in the survey. (Don’t forget to fill it in if you haven’t!) I’d love to hear of any other problems people are having in transitioning to responsive design, and what steps you’re taking overcome them.