Let's drop ‘Responsive’ from Responsive Design

In a meeting a while back, a client who had their web site built on a shoestring asked me with a slightly panicked expression: is my web site ‘Responsive’? I looked at the site and squished the browser around some and saw rudimentary things happen to the layout. It didn't look great. The only answer I could give to try and appease the anxiety of said client was 'a bit’.

It did make me start to question what Responsive Design was and question all the current 'attempted' classifications around fluid, reactive and adaptive, etc. I won’t go into the detail here, but you can use the interweb to find out more :

The truth is that there is no one answer and the lines between fluid, responsive and adaptive design are blurred and ever changing in a world which is producing devices of varying dimensions and capabilities faster than people can pour buckets of ice over their heads.

Responsive Design is not an end state, it is a process which tries to deal with many challenges of building web applications that can be viewed from your phone through to your TV through to gigantic projections on one side of the Grand Canyon (should it be so lucky).

The challenges are centered around these areas:

• Cost : Building a web experience that looks beautiful and meets business and user needs on ‘n’ devices has increased the cost of web projects.
• Design : Designing interfaces for multiple sizes, aspect ratios and transitions between has made static approaches to design such as PSDs or Wireframes an often inefficient and incorrect way of depicting how a web site work look and work
• Testing : Manual testing is labour intensive, costly and error prone. In the modern world, testing now encompases a myriad of devices. How to automate this and make the process more efficient is at the early stages of being solved.
• Technology : Responsive design has increased the complexity of front-end development. Knowing which frameworks to use or when to build your own on a fragile and frustrating matrix of browser and device capabilities is an ongoing technical challenge. 

The Responsive Design Process aims to deal with these by putting the following practices in place.

• Increasing the collaboration between visual designers, interaction designers, UXers and developers (mainly front but also back-end).
• Reducing waste and inefficiency by not investing a lot of time in producing a lot of PSDs or incredibly ornate and interactive wireframes.
• Prototype on the web where possible because it is the closest approximation to how it will look and work, and there is actually a low barrier of entry into doing this. The Responsive Workflow is great book which presents a very detailed workflow for this.

Digesting all of the above, the following is clear.

Web development these days has to include a mobile device strategy, baked into the thinking from day minus one. Doing this increases the complexity and challenges of web development, but that’s just life so deal with it. That thinking is essentially called ‘Design’ and needs all skills across user experience, visual and technical areas involved in a highly collaborative model which eliminates waste.

And since what we are doing is ‘Design’, why do we need to call it ‘Responsive’?