As the web landscape grows in complexity, it’s becoming extremely important to deliver solid web experiences in a growing number of contexts. Responsive web design gives designers & developers an important tool for making layouts that respond to any screen size. The use of fluid or reactive grids, together with flexible images and media queries to get optimum look and feel from a layout – regardless of the size of the device’s screen dimensions – is at the heart of this digital framework.
In September 2012 we launched Which? University which was the first digital product where we decided to pilot both the new digital brand AND a responsive digital layout. In developing a solid framework we needed to bear in mind a few basic considerations, the most important of which was a flexible grid that could accommodate a variety of screen resolutions.
Initially we decided to use the Bootstrap framework – created and popularised by Twitter. This worked well to a point but going forward we decided that a more robust (and less fluid) grid would be required. We then moved to a more reactive grid (based around the Frameless concept) which is actually fixed-width, not fully-fluid, but retained many of the properties that are desirable in developing in a multi-device, multi-screen environment. By conforming to a fixed width, the reactive grid also gave us tighter control over the designs at different resolutions (and thus consistency); and furthermore because we only had to optimize for four or five variants, we thereby streamlined the testing process. In addition Bootstrap is a ‘top down’ (or desktop optimized ) solution and we had some desire to shift the focus from this approach to a more mobile (or at least tablet) focused solution.
Mobile First or Progressive Enhancement?
Starting from the smallest screen size and working upwards is the most logical and productive way to design user experiences. By considering mobile first, we can progressively enhance the experience for other devices, focussing our content as we go. This has a beneficial effect for tablet, desktop and other screen formats too. It forces us to focus on information and user needs first, before enhancing the UX as our work progresses to larger screens. This often means we take a linear ‘one column’ approach. It gives us a basic hierarchy, and helps us prioritise our content.
In practice this means paying close attention to both interface, way-finding and information hierarchies – as well as a highly organised structure for base styles from text to imagery display. Although it doesn’t sound it at first, these constraints can open new opportunities – making very conscious, and somewhat brutal, prioritizations of content structure can feel strangely liberating!
Developing mobile first is efficient. But we also need to think about browser technology and screen real estate for desktop and tablet. Using these efficiently is hugely important for Which? audiences. With that in mind, we’ve moved towards a tablet-optimal approach which targets the devices most of our audiences are likely to be using.* So although mobile first is a good starting point for developing our products, we rarely see it as the endpoint.
*It should come as no surprise that currently (July 2015) our dominant OS and browser combo is actually Safari on iOS (largely due to the prevalence of iPad tablets and iPhones in our core user demographic)
From design to realisation
Obviously in practice some of the ‘ideal world’ methodologies are not always practicable. Many articles have been written around the lack of need for the traditional process of website development e.g. shape the UX and content, deliver wire-frames, pass on to the designer to ‘design in Photoshop/Illustrator’ and deliver a load of finished layouts to the developer to painstakingly craft in HTML. A more integrated, tightly knit “three-some” of UX, designer and developer working together (preferably right next to one another actually!) is the much favoured approach for developing these responsive frameworks. However, we found that to get buy-in (and crucially sign-off) it IS still necessary at some level to visually design something representative before coding begins in earnest, so that stakeholders can judge the holistic ‘look and feel’.
Style Tiles were touted as a possible solution when we started out – however, we found to keep the ‘faith’ in the end product we did need to knock out the odd ‘polished up’ design layout (usually a couple of ‘flats’ in Illustrator) … especially around homepage or landing page designs! Where possible the UX and visual designers should garner as much input from the developer as possible, so you don’t end up making promises you can’t (or shouldn’t!) deliver. We also found that you should do this as early as you can in the process (almost like an initial ‘pitch’) to set style and tone. Where we are now is a combination of using flat designs and (where practicable) using a simple responsive rendering tool such as WebFlow. The enables the visual & UX designers to craft the UI as close to a working prototype as possible and communicate interactions, visual look and feel and how the breakpoints should work. These are great for getting buy in from the Product team as a whole and also to give stakeholders an idea of what is proposed. It also gives the development team a chance to assess feasibility and flag up possible concerns when they start production coding (as obviously the WebFlow rendering is purely a visual prototype and the code it generates is largely throwaway in most situations!)
The main lesson is that you can’t involve the development team TOO early – whether from testing font-styles through to visualising how the layout can re-configure across resolutions and browser, it is essential to work as close to the developers as possible from the outset – particularly in complex, feature-rich, data driven, multi-screen optimised digital products. This is where the ‘irrelevance’ of grandiose layouts in the design process is exposed (except for the occasional exception as outlined above) – building up the ‘pattern library’ and testing it as you go saves time (and overall pain!) in the long-term.
We’re developing a UI Kit and front end framework to give us a digital knowledge base and repository of digital assets that will help us in all future digital developments. This is aimed at doing the following:
- Achieve a consistent brand and UX experience for customers across all Which? products
- Speed up development and prototyping through code re-use
- Apply learnings (UX, design and code) across all Which? domains (e.g. improvements in one project get pulled into framework and can be used by other projects including upgrading older projects)
- Prevent the need to re-think an approach each time a new project is started
- Define and document Which? coding standards
- Ensure adherence to agreed Universal design† and accessibility standards
† Universal design, also known as inclusive design, is the practice of making products inherently accessible to all users, regardless of ability. It dove-tails with our need to make our information and services available on as many devices as possible – from mobile phones, through to tablets, Smart TVs and other smart devices. It also defines our supported browser stack and OS (from Android, to iOS/OSX and Windows). At Which? we aspire to be setting an example in digital user experiences by being as inclusive as possible. When developing features we will be aiming to make our website accessible to all.
We’re still learning and perfecting our approach but what we learned in Which? University and progressed through to Consumer Rights, Campaigns, Birth Choice, Elderly Care, Which? Switch and even the Which? homepage has been invaluable; and we have accordingly streamlined and augmented this approach as we rollout the updates to our flagship product, Reviews ( for example our see the Televisions or Washing Machines categories).
The framework is still evolving as we explore new technologies and frameworks from CSS pre-processing with SASS and LESS, through to web components and single page applications with ReactJS and AngularJS. In parallel we have also evolved a more hybrid grid – which is fluid at the bottom end to allow for the plethora of smaller-screen devices (thus optimising for the increased fragmentation we have seen in the mobile and phablet market), fixed in the middle ranges (to enable maximum control over the majority of our traffic coming from tablets to laptops and desktops) and again fluid at the top end (with end points to stop it scaling forever when you get up to high definition wide-screens!)
Our overarching aim is to produce digital web products that are both Elegant and Simple to use – and to that end, as well as the technical and visual design framework outlined above, we have developed a core set of UX principles to guide all our digital product design decisions. More on these later …