To build a mobile site or not to build a mobile site; this is a question at the forefront of many a discussion. There is, however, another option: responsive web design. When, why, and how should you go about designing a responsive website?

With mobile internet users set to surpass desktop internet users in the US by 2015, with tablets becoming more popular, and even with TV internet usage increasing, it’s important for companies to provide a great user experience for all their visitors no matter what device they’re on. How does responsive design help us do this? Well, by allowing us to create one website solution that is flexible for different screen widths. It uses flexible grids and clever styles to present the same content to a user, but displays that content in a format that suits the width of the device. Check out this beginner’s guide to responsive web design for a more detailed introduction.

Why should you design a responsive site?

There are many options to consider when a client asks for a mobile solution for their website, and the suitability of these options depend on the business requirements and budget; it’s also important to consider any existing solutions or sites they already have. Creating a responsive website isn’t a complete mobile strategy, and won’t answer every brief, but, especially if you are starting a website from scratch, you should consider it as a very serious option.

So why would you decide to create a website this way?

You’re starting from scratch

Developing a whole new website or web application is a challenging process. You won’t know if the site will be successful until it’s live and in the world, so creating a separate mobile site or a mobile app in tandem with a website project could be a big waste time and money. It’s more efficient to get your new site performing well before you create an additional mobile site or application.

You want to keep costs low

Solid responsive solutions require additional design and front-end development time, but doesn’t too heavily impact application development. It could take around 20-30 per cent longer to develop a responsive site, but it’s still faster than creating an additional mobile site or app. Developing a site this way also means that you only need to develop, manage, and maintain the one site, so it can reduce these costs too.

You want it to work even when new devices are released

A mobile site needs to be able to recognize the user’s device; when new devices are released, the site needs to be updated. As the responsive solution only recognizes the browser’s width, no new updates would need to be made. This means it’s much more future-proof and scalable.

The process

Let’s talk through the process of creating a responsive website using a hotel website example. This last September, Equator released the new Macdonald Hotels website. Macdonald Hotels are a UK hotel chain with 47 hotels and resorts across the UK and Spain. We created the new site for them that included a new site structure, extensive hotel content, and a new booking engine. Here are the steps we went through and also some considerations you should think about when designing a responsive website.

These are the key steps:

Research/scoping: Understanding the additional requirements for a responsive site

Wireframing: Grid structures and layouts for the site considering different screen widths

Look and feel: Style considerations

Building the site: HTML & CSS issues

Research and scoping

Research is always a very important stage in the design process so it’s worth putting a little extra consideration into the people who will be using different devices. Understanding how these different users may want to use the website on a variety of devices will help you to decide what the priorities are on the project.

What different goals will a user have on different devices?

Questions like this are starting to become more redundant. In the past we’ve assumed that mobile users have been task-driven, e.g. I want to get the hotel’s address; I want to book something quickly. But now people on any device are just as likely to leisurely browse the Internet as they are to need to complete a task quickly. It is worth considering though, as thinking about users’ goals in this way could help you prioritize content for the site, irrelevant of what device the visitor is using.

What technical considerations do we need to make for functionality and content?

Think about how any complicated functionality may work on different devices. Although a responsive site will only change the CSS depending on the width if there are complicated elements that rely heavily on JavaScript, they may not translate well on a smaller device and it could be worth hiding these.

Wireframing

The logic behind how the styles should change can be a bit hard to define and the magic of it will really come out in the build of the site, but we need a way to start defining the different width stages of the layout. We choose to look at 3 screen widths, a desktop, iPad and iPhone. We felt these covered what our requirements were, but for your project you should consider what widths are important for you to think about—you may even need to look at bigger screen widths for TV internet usage.

At this point of the project you should already the key templates that you’ll need to wireframe, but you shouldn’t need wireframes for all these templates in the different widths. The main goal here is to help define the logic behind how the CSS will change the look of the page, so focus on pages that have very different layouts. For us we looked at the home page, all the booking process pages, the hotel pages, offer pages as well as some generic layouts. Each of these covered our different column layouts, content types and key functionality.

Getting started

First, define the grid structure for each key width. We created 3 pages for the screen widths 1024px (Desktop), 768px (iPad portrait), 320px (iPhone portrait), then we needed to define a grid structure for each of these widths.

A very simple grid structure with equal column widths on each layout made it easier for us to plan for components wrapping as the width changed.

Creating the master template

As you create each wireframe you’ll need to think about the columns and how the components within these will adapt as the page width shrinks&mdashe.g. what happens When you have less space? If you have four columns of content? When you change to a three-column width? There should always be ongoing communication between the designer and the front end developer to answer any issues about what you can do with components visually and in the CSS.

Starting on the home page

You may feel like there is another page that has a higher importance than the home page, but this was where we started. Here is our finished original wireframe. You can see the mobile page length is quite a bit larger due to the content wrapping over one column.

Main navigation

We created a simple horizontal top navigation that would have a fluid width to change with the screen size. As the screen reduced the menu items would get closer together, then wrap on to the next line when necessary. This works for desktop, laptop and tablet widths, but going further down we wanted to create a menu that would suit the devices better. This gave us the menu spilt over two columns for the mobile device.

Other header components are aligned right and would just shift along as the page width reduced.

Remember when you are styling the navigation to think how it will work as the screen sizes changes. Certain styles, such as using tabs, may be difficult to get to work and look good as the screen width reduces.

Footer

Our footer is pretty simple, just think about what content you want and how it will change as the width changes and the columns reduce—this could be as simple as components wrapping underneath each other.

Other components

Our simple grid structure made it easier to plan out our components. On the home page we used a horizontal scroller that had four components that would scroll across on a click. Our tablet layout let us keep this component but just amend it to only show three items, then on our phone width we removed the scrolling functionality completely and instead displayed each item vertically. Each component you design may require different behaviours, so think about how the visitor will want to use the component on different screen sizes. Phone users are more comfortable scrolling down a page than using small buttons to interact with the page.

Test it straight away

As soon as you have created your first wireframe test it on the relevant device straight away. It’s easy to get the image on a simple web page and take a look at how it looks and feels to scroll down. This will let you know early on if your wireframe is working. Testing in this way gave us clues really early on what was and wasn’t working. If you look at this wireframe you should quickly see our first issue.

As the user navigated through the site they would only see these first two page elements&mdashthe navigation and the search panel. This means that the user may be unsure if the page has changed, as well as where they actually are on the site. This was solved simply by putting these items in show/hide panels—letting the user get into the content much faster.

Adding the tablet and mobile versions to your user testing process will give you a lot of useful feedback too. Now that your wireframes are created, tested, amended and approved it’s time to make them look good for all your screen widths.

Look and feel visuals

It isn’t necessary to create visuals for every wireframe. The main objective is to cover all the styles that will be required to create the HTML and CSS. There will be a little bit of a crossover for wireframes and visuals, some styles that will be required for the mobile where there wasn’t a need for an initial wireframe.

Styling the page: Think about keeping your styles simpler for your mobile version—what’s great about CSS3 is that you don’t need lots of images to get great styled effects, but these still take a bit of time to load.

Thinking about font: Make sure your font sizes are going to be readable on each device. They’ll have to be much larger on the mobile device to ensure readability.

Also, be prepared for your visuals to change when it gets translated into the build of the site. There always should still be balance between what looks good on a flat visual and what will work when the site is being developed. The final site isn’t too far away from our look and feel visuals, take a look here and you can compare with the live site.

Building the site

Building the HTML and CSS is a challenge all of its own, so I won’t discuss this is much detail, but here are a few things to think about.

The impact of image sizes: The site will need to load in the full size images even if the CSS scales them down, so try to keep image sizes as low as possible. There can be some nifty JavaScript tricks though to make the site run smoother. On this site we initially loaded in the smallest image size, and then used JavaScript to decide if a larger image was then needed.

Use advanced CSS:
It’s important to get the client behind the idea of using advanced CSS styles, allowing the site styles to degrade as the browser capability does. This lets you keep site loading times low.

Constant communication is required: The project will always go smoother if the team speak to each other, so from both designer and developer it’s good to discuss problems and solutions as soon as they turn up.

So what does all this mean?

If you are thinking about convincing your client to have their new site designed and developed in a responsive way, firstly you should consider if it really is the right solution for them, then you’ll need to be able to persuade them of the benefits and communicate that it will add more time to the project. But, I do believe that this is how more sites will be developed in the future.

We’ve all learned so much on this project about developing a responsive website. We were lucky to have a client who was as keen as us to create something new and innovative and from that we’ve created a site we’re all proud of.

About the Author

Elaine has been designing websites for over 14 years. User experience and design have been a passion, and something she loves talking about, writing about, and – if it's been a long day – maybe even mumbling about in her sleep. Elaine is an experience designer in London.

Wonderful article on responsive design. Thank you so much for including wireframe/mobile site/whole process image examples – made the article more digestible than some of the other responsive design articles I’ve read.

I’m working on a new project and I’m totally passing this article along to the PM. Thanks again!

Very helpful article! I am just starting to get into mobile site design and responsive site design seems to be the best solution moving forward, even with the added development time. How long do you think it will be before most sites develop this way. 2015? Hopefully it will be sooner.

Hi Aaron. Responsive design was an approach and technique we had had limited experience with before this project, and certainly on a project of this size and complexity. So we took a fairly conservative approach to its implementation and the browser platforms we decided to support.

The desktop-first approach to building the media queries allowed us to create a solid, fixed-width experience on the legacy browsers that didn’t support MQs (IE7 and 8) with very little effort, and then focus more time on getting the responsive layouts right. It was very much in the spirit of progressive enhancement, although obviously, as Elaine has shown, an enhancement that informed our design and development thinking from day one.

Research and Scoping
– “if there are complicated elements that rely heavily on JavaScript, they may not translate well on a smaller device and it could be worth hiding these.” Instead we should be considering the lack of robust Javascript support as a default and then build up to full-blown modules. Mobile users deserve that content; hiding it risks alienating potential customers.

Wireframing
– Static wireframes. This is something I feel we need to get away from. There’s nothing from stopping talented UX designers from designing these flexible systems in the browser itself. Because UX typically happens before development, this step in the process is crucial for client and team education. Establishing the grid system on paper to get the concept and flow down is great, but I’m a strong proponent of moving into the real environment as soon as humanly possible.
– Avoid saying “iPhone” “iPad” and “Desktop”. This limits client/teams perspective and it risks forgetting about the rest of the (massive) mobile market. Opt for “small” “medium” and “large” instead. There are worse problems though. I hear this a lot: “Ok, well for mobile we’ll do this and then for web we’ll do this.” O_o”
– Don’t get too caught up in specific values: 320px and 768px are of course popular but again getting that specific runs the risk of becoming rigid in those exact dimensions. They’re great for “optimal” design patterns, but ultimately the site needs to ebb and flow with similar but not exact values.

Main Navigation
– This site does a great job, but I’ve seen sites that remove padding for smaller screens, but this is exactly where that padding is needed in order to buffer for touch input. Too many sites forget that most people using these small screens are using their fingers instead of a mouse.

Other components
True, mobile users are more comfortable scrolling top to bottom. However, those little modules are great places to take advantage of touch. A swipe gesture could be a great way to advance the content. Just make sure it’s obvious to the user that the gesture exists.

Some great points. I definitely agree with you on wireframes. Looking to the future for that I’d much rather be making prototypes. Agree on using the terms iPhone, iPad etc. Helped me define the wireframes to create, but it wasn’t what we were basing the front end development on

Hi Brad. I was the front-end development on the project. I absolutely agree with your point about getting caught up on fixed, if optimal dimensions. I really used the wireframes Elaine created as the jumping-off points for creating a responsive solution that was optimised for any screen width from 320px upwards. This was actually the most interesting part of the process for me.

We’d anticipated that parts of the layout design would emerge from the process, but starting with a set of initial layout transition breakpoints (optimal mobile, tablet, desktop) allowed me to create a first cut of the HTML and CSS to build on. Elaine and I then evolved the design in code, looking for areas of stress, generally to be found just the wrong side of the initial breakpoints, and adding new, intermediate media queries to address these issues and others than emerged from things like ad-hoc usability testing.

I think understanding responsive design as an evolving process is really the key to making it succeed.

Mobile First was in the back of our minds when planning the project, and definitely key to how we planned the functionality and site architecture, but honestly I think it’s just being a little set in my ways that led me to wireframe and design the desktop version first.

We were lucky to have a client that trusted our experience, but you’re right, often people just need to see a visual to understand it.

Great article Elaine. I would agree with @Brad Frost on several of his points. Specifically moving from UX to live development as part of the process early on. I recently redesigned my site and it was a bit of a challenge. Starting out with mobile first then moving up the chain is the best method.

I would also agree with image sizing. I didn’t implement any image sizing techniques at this point as there is no tried and true method yet. The downside is the images don’t look great on mobile yet.

Good advice which highlights that you can’t just apply a “mobile” template to your existing site and then claim that you’re mobile ready.

How do content management systems handle the issue of using different content for mobile devices? WordPress, for instance, has a number of mobile themes which address the visual interface. It also has a number of plugins which do things like browser auto-detection, but do any of these plugins allow the site owner to specify different copy for mobile devices? If they don’t, they have limited usefulness if you’re using WordPress for a business website.

Real mobile design is expensive because there is much more to do than just addressing layouts for the small screen.

One wonders why use the knowledge of mobile users surpassing the desktop users as a reason to build desktop experience on mobile instead of building the best experience on mobile that will responsively expand for desktop users.

Those are good points about the need for communication between designer and developer. We’ve also found that content people should be in the loop from the start of a project.

As you’ve suggested above, that will help you prioritize content. One practical approach is to create a message hierarchy – this focuses everyone’s minds on what content needs to be presented first in order to engage your visitors.

Content creators should also make it clear how they’re understanding the user journey. They should explain it as a narrative. A marketer, for example, should be explaining the sales funnel on the site; a writer should be making it clear how an article is structured and how it can be adapted for smaller screens.

The technical aspects of building a responsive site shouldn’t be much of an obstacle to anyone these days. There’s great tools such as semantic.gs in combination with “320 and up” that provide a responsive grid to design on and generally take care of the basic “plumbing”. I built a responsive theme over WordPress in a matter of 2 days using the techniques above.

Personally, I feel the biggest challenge is to actually decide which elements and components to leave out from mobile-width versions of responsive designs. Simply shrinking everything in width won’t do, some of the elements have to be eliminated from mobile width layouts.

Elaine, you just got a huge fan. Outstanding article and example! I’m a webdesigner and front-end developer trying to follow new trends in best practices. And I am realy impressed about your case study. Wonderful color pallete and amazing “responsive image slider”. Definetly a flawless victory! :) Best regards from Brazil!

I think the premise of building a website that responds well to all devices its being loaded on is smart in theory. However, I think that the reasons people come to your site differ depending on the device they’re using it to access it. Luke Wroblewski’s new book at A Book Apart has a pretty keen concept – Mobile users are “One eye, One Thumb” and it refers to the fact that mobile users are looking for specific functionality without the pain of having to pay exclusive attention to the mobile site. Mobile users are waiting in lines, at stop-lights, checking their device under the tables in meetings – and so on. Rarely do they have the time to sit and devote their full attention to the website. Because of this, the site needs to push different functionality to the front for users – which means removing a lot of the information that would be found on a desktop version of the website. Just adding a “disply:none” is still going to load the scripting and increase mobile load times – and that doesn’t cut it.

Examples would be pushing “Get Directions” utilities so mobile users could get directions quick if they get turned around on their way to your office. Or possibly pushing “Call Us” to the forefront – where a desktop app would take advantage of the larger screen to collect more customer info via a full fledged contact form. With the reasons people access websites varying so wildly between devices, the functionality needs to differ to match it or you end up with a site that works in a mediocre fashion on desktop AND mobile.

The bottom line, I think its rare that a desktop app and mobile web app should have exactly the same functionality. Because of that, responsive design (as you extend it to mobile devices) doesn’t take full advantage of the capabilities mobile devices have to offer.

I’d love to hear folks thoughts about this. Thanks for the great read.

Regarding images, i wonder do we need to ask the designer to create images for different devices to ensure the image size and quality is present always? However i think this will add up the cost to designs.

Not sure if there are any popular techniques which scales the image up/down dynamicaly?

I’m interested to understand the theory behind why the sub-navigation column wraps to below the main content.

In this example, the sub-navigation column isn’t a critical navigational route, but in a site with a stronger emphasis on ‘category’ pages (deeper nav structure), the navigational column becomes more crucial, and making it wrap below the content pane would potentially limit the content presented below any primary content – in order to move the navigation items higher up the hierarchy.

So I get why sub-nav should wrap below main content as a logical next step, but it could result in superfluous (related) content appearing between the primary content and the sub-nav. Is the answer to hide such content on smaller displays? Or present a nav menu directly under the content for these devices?

It can be a balance to consider, depending on content and context. We need to make sure the nav and sub-nav don’t fill the full screen on a mobile as a user navigates between sections – it may cause confusion as the user may not realise a new page has loaded.

You saved my life :)
I am in the process of launching my website and didn’t have any idea about mobile optimised designing. You explained it beautifully.
This is a great article. I learnt a lot from it.
Thanks a lot.

There are a lot of tools out there that make responsive design prototyping/wireframing pretty fast. My current favorite is Foundation from the people at Zurb (http://foundation.zurb.com)…if you’ve used 960 grid (or any grid), you’ll be fairly comfortable with this. Twitter bootstrap (http://twitter.github.com/bootstrap/) is another option.

Good post – but your missing the real reason of why you should be implementing responsive design into your work. The amount of Google searches conducted from a mobile, tablet or any other non-desktop device is increasing every couple of months – it’s absolutely crazy. Responsive design is becoming a fundamental feature for websites in today’s generation, the amount of users viewing websites, navigating the web and using apps is growing at a rapid rate. I use my mobile phone to browse the web more than my desktop – because I’m constantly on the move.

Most design agencies are taking advantage of responsive design – it’s becoming a ‘must have’ feature – I read a similar blog post over @ http://www.stellasoft.co.uk/ this week – they mentioned that Google is now taking into consideration responsiveness as a ranking signal – which is superb.