Responsive Design & ROI - observations from the coalface

Over the past year or so we’ve been lucky enough to be asked by a number of exciting companies to undertake ‘Responsive’ redesigns.

The ‘Responsive’ approach (as advocated by the wonderful Ethan Marcotte) is one where a single CSS/HTML site adapts to the device on which it is being viewed, as opposed to a collection of separate sites that are designed with particular devices in mind.

The advantage of Responsive sites is that one codebase covers all devices, meaning that changes can be rolled out to an infinite number of devices by amending one set of code, and one set of assets (images, videos etc).

Device-specific sites, however, are often completely separate to their desktop equivalents, which can mean greatly increased ongoing costs to maintain your suite of sites.

Here at cx we regularly undertake detailed user testing on all sorts of tablets, smartphones and desktops, which provides us with insights that we can draw upon when making decisions during Responsive projects, however it is still a relatively new approach - one that presents unique challenges along the way.

As the approach matures and starts to be recognised as a valid mainstream approach to maximising ROI, we thought we’d share some of our observations from being at the coalface.

Wireframes are no longer enough.

Responsive sites tend to be built around a number of ‘breakpoints’. The sites detect the browser width and deliver the most appropriate layout and content (via media queries - for more info see this article). This commonly results in at least 3 distinct layouts for desktop, tablet and mobile.

Traditional wireframes are very useful for establishing the initial, broad approach, but they fall down when it comes to filling in the gaps between breakpoints.

Developing HTML prototypes from the initial wireframes enables the team to cement their approach to the adapting layouts in the browser. HTML prototypes (with fully functional media queries) enable realtime responsive testing on the devices they are designed for, allowing rapid feedback and iteration based on informed decisions.

The addition of HTML prototypes may be an addition to your usual wireframing process, but they will help your team maximise the value of the wireframing/UX process.

Design your layout according to device type.

Our user testing on a variety of devices uncovered a surprisingly uniform pattern of behaviour. On smartphones, all the users we’ve tested viewed websites in portrait mode (upright). On tablets, however, all automatically held the device in landscape orientation.

This insight can be used to inform the wireframing and prototyping process and ensure that the site’s flow is optimised to the most common use case.

The 960 grid may not be the most efficient any more.

The 960px grid system has been used for years to design websites that work perfectly on fixed size desktop screens.

The Responsive approach, however, is all about designing for a multitude of screen sizes, and uses percentages to determine layout, which can prove to be a rather inefficient process when using a 960px grid (resulting in some crazy numbers).

More appropriate, and potentially much more efficient, are grids that adopt a more rounded, percentage-friendly approach, such Elliot Jay Stocks’ 1000px grid, and the 1140 CSS Grid.

A pragmatic approach to fluid layout.

Fully ‘fluid’ Responsive sites reconfigure their layout and visual hierarchy in realtime as the user resizes their browser window.

Whilst this approach may be seen as technically impressive, it is usually at best an edge-case requirement for users, who are more likely to find unnecessary rejigging of content a confusing distraction.

That is not to say fluidity is completely inappropriate - indeed when designing the breakpoints for tablets and mobile devices it is a good idea to allow for a certain level of flexibility in layout to accommodate for the many differing screen sizes.

Retaining the use of Photoshop maximises the efficiency of the visual design workflow.

There have been a number of calls from members of the design community for designers to start working exclusively in the browser, designing on the fly with CSS/HTML and Javascript.

Whilst this is a nice idea, we have found that from a practical level it is much more efficient to begin the visual design process in Photoshop (and/or Illustrator), and move in-browser once a visual direction has been determined and the more intricate assets created.

In most cases we’ve found working in the browser from the outset to be considerably more time-consuming, and more restrictive, than working with Adobe’s suite of tools.

Time to get agile.

The Responsive approach to designing for multiple devices demands a certain level of experimentation, of trying out concepts in realtime, of iterating regularly - more so than the traditional fixed-width development process.

This iterative approach naturally lends itself more easily to an Agile process than a Waterfall one, which means some changes in the project management process are often necessary to allow for more collaborative ‘sprints’.

The need for buy-in.

"Embracing the Responsive design approach is like shifting from tables to CSS."
— JAMES DRINKWATER, TUI

Media queries, the building blocks of Responsive design, demand a complete rethink of how CSS/HTML is put together, therefore a complete change of approach is needed.

If your development team is going to become a lean Responsive team, they will need to be completely sold on the benefits of it, which may mean an evangelical approach from the project leaders - providing insights where needed, encouraging ongoing experimentation and ensuring everybody is fully versed on the reasons why you are adopting the approach.

A new approach, with fresh challenges..

Whilst we have worked on a number of successful Responsive design projects now, we are aware that it is not appropriate for every situation. There are instances where dedicated mobile-specific sites or apps are the right option, especially where device functionality (cameras etc) are utilised, or where large amounts of content need to be navigated on the go (e.g. Twitter, Flickr etc).

And of course, whilst it is no doubt a cheaper alternative to a device-specific approach, the changes to your UX and development process do need to be factored in.

However our pragmatic approach to Responsive design has excited us about the possibilities of multi-device design, and we’ve a number of sites in development at the moment that we can’t wait to launch upon our clients’ customers.

It would be great to hear of your experiences, so please share in the comments section below.