Responsive web design – problems from the coalface

Some initial notes and answers from a survey of the design community on their experiences working with responsive web design.

I’m currently doing some research for a project which I’m specifically interested more about the problems fellow web designers and developers are experiencing when working with responsive web designs on new and existing client builds. The results so far have been interesting so I thought I’d share a few of them.

If you’ve not filled in the survey yet – please do, and then share the link: Survey – Problems you’ve encountered working with responsive web design

Q1: What sort of problems (if any) did you encounter with the design & development process creating a fully responsive website?

Conclusions from Q1:

Above is a selection of answers, but there were several recurring answers from people, these were:

Q2: Have you worked on a project which actively chose to run a “mobile” site as well as a desktop site instead of a fully responsive single site? If yes, what were the reasons behind that decision?

Conclusions from Q2:

I should note here that the above answers are only from people who said they’d built a separate mobile site, about 50% of the responses to this question were “no” so I can only assume that either those people haven’t worked on a mobile site or opted for a responsive approach. Either way, the answers above are interesting and a couple of trends can be observed.

Q3: When working with an existing “fixed desktop” website which is being updated to be responsive, what do you do with existing templates and content? A full greenfield rebuild or reverse engineer existing code?

Conclusions from Q3:

I can say from personal experience we always try to greenfield rather than reverse engineer templates and CSS as we work mobile first so it’s often quicker and more cost effective to do so but it’s clear in the real world a lot of fellow designers and developers (for varying reasons) also have to reverse engineer code to give sites responsive features and functionality.

It should be noted that most responses so far were either simply “greenfield” or at least mentioned that starting from scratch was their preferred option if given the freedom to choose.

Q4. Do your responsive projects require larger budgets than older style fixed layout sites or have you been able to make savings elsewhere – eg: quicker prototyping/design in browser etc?

Conclusions from Q4:

This was pretty encouraging, quite a high percentage of people mentioned the cost of working responsively was higher than it used to be working with fixed size layouts but on examination, several respondents noted that some of this was down to them still learning or adapting their own technique and process so these “costs” would be internalised and not passed directly to clients in their invoices.

I’m glad to also see a number of responses saying that while some things related to working responsively such as the potentially massive increase in the amount of time testing takes due to different devices, breakpoints etc, there are corresponding savings that can be made with making use of frameworks, rapid html prototyping and designing in browser so where in places costs and time taken have risen, in others there are savings to be made and the more experienced people become the more costs seem to fall back to a similar (if slightly elevated) level to traditional fixed width design.

The increased cost and complexity of testing was mentioned by a high percentage of respondents.

Please help and take the survey

If you’ve not filled in the survey yet – please do, and then share the link: Survey – Problems you’ve encountered working with responsive web design

Posted 2 years ago on · Permalink