Newfangled works with independent agencies to create lead development web platforms for their clients.

Newfangled works with independent agencies to create lead development web platforms for their clients.

What We've Learned About Responsive Design

I was nervous when we decided to start doing responsive design. I thought it would completely disrupt our workflow, causing projects to be much more complicated, stressful, and far less profitable. Fortunately, that hasn't happened. It's not that it hasn't required us to make changes to our process, or that it's been stress-free. But it hasn't been a disaster, and that's what I tend to expect from change…

After a year or so of doing responsive design projects, we've learned a ton, and I've solidified some of my opinions about what we're doing and how we're doing it. I'd like to share some of that with you here, but first I think it would be helpful to review the basic idea behind responsive design and take a critical look at some of the philosophical stuff that gets wrapped up with it. If you're anxious to get to the examples and pictures, feel free to scroll down a bit to the "Planning is still necessary" section.


In a nutshell, responsive design is really about the nut, not the shell.

For those of you who could use a refresher — or for those of you who have never really been clear on what responsive design means — I'll do my best to sum it up for you as simply as I can: Instead of building an entirely separate site that users are redirected to based upon the devices they use, or creating alternate templates that are swapped in based upon a user's device, responsive design is an approach to creating a website that simply amends its CSS file with unique ways of displaying information based upon the size of the browser window. Because there are so many different devices from which users might access a website, the most efficient approach to consistently presenting information across such a wide variety of contexts is to make the information itself flexible, rather than the container. Sounds good, right? Well, that depends upon what we mean by making the display of information flexible. Or, really, how flexible we can truly make it.

The more flexible the information, the more variables there are to manage. And, since we designers and developers have no control over the number of unique little screens that are out there, we need another way of keeping this responsive thing manageable. Otherwise, we might feel pressured to tweak our designs for every unique screen dimension that exists (turns out there are a lot of 'em). So what we do to remain sane is decide upon a smaller number of breakpoints — typically 3-4 — between which are ranges of resolutions that fit general categories of "desktop," "tablet," and "phone." Our CSS file responds to the user's viewport by applying the display amendments — we call them media queries — that we've written specifically for those ranges. This way, visitors who are using 7 or 10-inch tablets, which have different screen resolutions, will trigger the same media queries that correspond to the range between two breakpoints: the smallest "desktop" resolution we've anticipated, and the smallest tablet resolution. The difference in resolution between those two devices is small enough to be accounted for by other, more general flexibilities, like text wrapping, padding, margins and the like. I know, it's complicated. If it helps you to visualize, this is essentially the same technique we've been using for years to optimize how a webpage is printed — in that case, the media specified is "print" — it's just that we've pushed the idea into much more rich and complex territory. Ideally, this approach is the most efficient means of optimizing user experience across the widest variety of contexts. Ideally. I'll come back to some of the not-so-ideal subtleties a bit later, when I grumble about testing and device support…


Responsive design is more work. And more expensive. Maybe you don't need it as much as you think you do.

I've run into the idea that since responsive design is a more efficient mobile solution than creating unique mobile sites or alternate page templates, it is therefore going to be cheaper and simpler than what everyone is expecting. Not true. The fact of the matter is that doing responsive design requires work that just wouldn't be done at all if mobile wasn't a consideration. Now, I'm not advocating that we ignore mobile. But in some cases, I'd argue that mobile is probably higher on the priority list than a serious cost/benefit analysis would merit.

Our audience is primarily comprised of people working in the advertising, marketing and design industry. They're people who influence or make decisions about design and development projects. With our audience in mind, if you were to ask me if mobile should be a higher priority I'd say absolutely. I'd think of all of our hip and stylish visitors and how many of them probably already have an iPhone 5. But you know what? In the last month, just under 10% of our website's visitors accessed it with a mobile device. That includes phones and tablets. If I extend my look to the last six months, the mobile population is exactly the same. The last year? It drops to 8%. So, mobile traffic is growing, but not as rapidly as I would have assumed based upon what I think I know about our audience. With those numbers, should mobile be prioritized as much as it has been (we're about to launch a site redesign that makes heavy use of responsive design techniques — more on that later)? With over 90% of our visitors still coming in through a "desktop" computer? Probably not. But for us, there's an additional consideration of needing to demonstrate our capabilities in this area, which pushes the benefits over the cost. For many other businesses, though, that additional benefit doesn't exist.

Very few of our clients have a "money is no object" attitude when it comes to budgeting for a web project. In fact, for many of them, our costs are a bit of a stretch. But they believe in the value of what we offer and trust us to lead them to the best outcomes. It would be wrong for me to push responsive design on all of them, indiscriminate of what they know about their audience, their actual visitor data, and their actual budget. If their money could be better spent in some other way, then it should be.


C'mon guys, mobile shouldn't always come first.

If your cost/benefit analysis backs up doing responsive design, great, let's roll up our sleeves and have some fun. But, where to start? Perhaps you've heard people talking about taking a "mobile first" approach to web projects. It's become a bit of a dogma at this point, so I think it's important to clarify what we mean when we say it. Generally, I think it tends to mean two different things, though sometimes both are relevant.

Thing #1 is that mobile devices are so prevalent at this point that we should invert our usual sense of design priority — designing for "desktop" use first and then figuring out how to make it not suck on tiny screens — so that we start with tiny, get that right, and expand from there. That, of course, assumes that a large enough population of your website's visitors access it — or can be expected to access it — with a mobile device. Yes, mobile device use has exploded. We're practically cyborgs and all that. But, is your site the kind of site that will be accessed mostly by mobile device users? Look at your personas. Check the data. If so, then, great: Mobile first! But if not, then refer back to the previous section about cost/benefit analysis.

Thing #2 is that starting with mobile forces a certain economy of design thinking that should make for good design no matter what — whether tiny phone screen or enormous cinema display. This is just false. Designing something that is a perfect fit for a phone, no matter how good the design is in terms of classical, formal considerations, will never also be a perfect fit for something vastly bigger. Remember when the iPad came out and Apple had to spin it to all the iPhone app developers by saying, "Good news! You don't have to redesign your app for this new thing. You can just center it in the bigger screen or stretch it out to fit." Uh, wait. So, what's the good news? Right, there really wasn't any. Centering was lame, and stretching made everything look less crisp. If an app developer simply rewrote the app to natively fit the dimensions of the new iPad screen but didn't actually rethink it, sure, it would look crisper, but it would still look like an iPhone app stretched out. The point is, good design takes context into consideration. Just because a smaller screen forces us to make strong (even cutthroat) prioritization decisions doesn't mean it will produce the best of all possible designs.

One last thing: The reality of your audience should really dictate your design philosophy. It's one thing if a significant portion of your audience uses mobile devices to access your site. It's another if those users who match the personas that matter to you use mobile devices to access your site and actually engage — by responding to your calls to action — while using these devices. We really need to think deeply about this and then verify our thinking by talking with people who are representative of our core audience. Ask them. Do they consume your content most often using mobile devices or at their desks? Do they respond to calls to action most often using mobile devices or at their desks? Based upon the conversations I've been having for years now, our audience may be increasingly consuming content from a variety of devices, but I get the sense that when it comes to business transactions, they're still at their desks. That puts the mobile priority in a very different light for me. Yes, it's anecdotal. Other than my analytics data, I don't have numbers to throw at you, so I encourage you to start by asking these questions yourself.


Planning is still necessary.

We're all about planning, so it should come as no surprise that I'd reserve a section to briefly mention some ways to plan for responsive design projects.

We prototype every website we build using an interactive prototype builder, similar to something like Protoshare. Instead of wireframing on paper, we are essentially building the site before we build the site, focusing on information architecture rather than any other visual design issues, in an environment that enables a user experience as true to life as possible. Of course, if we're doing responsive design, we also prototype how the site's pages and functionality will adapt to smaller viewports. Below is a recent example of a real estate website's prototype showing how the homepage's search functionality would work on phone-sized screens.

        ↑ We prototype our responsive projects, just like we would any other project.


Google Docs Wireframe Template:
Even though prototyping is a non-negotiable for us, I'm a big fan of pre-prototyping by whatever means you find helpful, especially if there's a way that you can quickly get your ideas visualized. Google Docs has some wireframing templates for this that are really pretty decent. Below is an example of one for the iPhone:

        ↑ Mobile wireframing image source: Google Docs Blog.


Good Old Fashioned Paper:
Of course there's nothing wrong with using good, old-fashioned paper. Again, this is a pre-prototyping step, because I'm a big believer in the idea that you can't really communicate an interactive experience with a non-interactive media. But, if sketch templates (like the one below) help you brainstorm and quickly iterate layout ideas, then please use them. Plenty of people — myself included — don't think as creatively when they're using screen-based tools with lots of rules. If that's you, I recommend sketching out your interfaces before prototyping them.

        ↑ This sketch template created by Oliver Waters.

I did see this video recently that is trying — really, really trying — to make paper work as an interactive prototyping tool. I can't say I'm not impressed, but I do think there's a limit to how useful this sort of thing could be. It's kind of cool, though, in a Science of Sleep sort of way…


Navigation requires a little extra attention.

If you think about it, navigation menus are really just interactive visualizations of a website's information architecture. The way we design them tends to correspond with the hierarchy of pages, as well as what information is most relevant to a user's sense of place. We're used to having lots of horizontal and vertical space to handle them, as well as desktop-specific interactions — like hover states — to make them intuitively usable. But on smaller screens, space is obviously limited and there's no such thing as a hover state. So, it makes sense navigation would be one of the bigger challenges of responsive design. Here are three perspectives on handling that challenge:

1. Consolidating Menu Items:
If it's possible to do so, the simplest solution would be to reduce the number of items your main navigation contains so that you either don't need to use any media queries to adjust it for smaller viewports, or that the adjustments you do make are so minor that they don't change the UI at all. This is, of course, a whole lot easier said than done. It just may not be feasible to get everything your website contains consolidated under just a handful of headings.

Below is an example of a consolidated main navigation. Our client, DesignPlan, wanted to make sure their website was optimized for visitors using mobile devices, but they just didn't have the budget to do a full rebuild — something we'd generally recommend over trying to retrofit an older website with an up-to-date skin. Since their design was pretty spare to begin with, we figured we could rebuild the page templates and write new CSS that used responsive techniques fairly easily. But their navigation menu was too long to be squeezed into narrower viewports without doing a bit more with the CSS to create an entirely new way of displaying it. Instead of doing that, we opted to consolidate the navigation menu so that it would fit horizontally on all sizes. The only CSS trick we used for the navigation was to remove the word "catalog" from two top-level items when the page displayed on phone-size screens, so that the four items would fit nicely across the screen and have enough room for tapping.

        ↑ Consolidating your nav is one proactive way of dealing with less horizontal space.


2. Using Browser Defaults:
Another "lighter" option is to let the browser handle your navigation structure with a default pulldown menu on the smaller viewports. In this scenario, you might be willing to sacrifice a more customized design at smaller sizes for the simplicity of a form select element, which has no styling of its own. In most cases, it's minimal enough to not seem out of place.

The way this works is that the navigation elements would always be contained within a select element — which is typically used for options in a form, like "country," "state," etc. — that is hidden by the CSS at larger viewport sizes and replaced by more detailed display specifications. For example, our friends over at handle their navigation exactly this way (shown below). At larger viewports, the main navigation is displayed in two columns to the left of the main content column. As the viewport reduces in size, they alter that navigation at a few different breakpoints, until the final one, which provides no styling specifications and "unhides" the select element. That is why users accessing their site on a phone will see the navigation as a simple select pulldown instead of something more uniquely designed. I've also included a short sample of the CSS for below to show how at the 1220px breakpoint, the select element is being hidden. It may not be the prettiest option, but it's probably one of the most user-friendly.

        ↑ Smashing Magazine lets the browser display the main nav at the smallest display sizes.


We chose to use the same technique for our client, Inhance Digital (shown below). On wider viewports, the site uses a pretty typical horizontal navigation with hover states and drop-down menus. On smaller viewports, we default to a form select element.

        ↑ Inhance Digital also uses browser form elements to handle its nav at the smallest sizes.


3. Creating Unique Menu CSS:
Before the Boston Globe launched its responsive site, there really weren't many successful, large-scale responsive websites created outside of designer/developer enthusiast circles. So, it set a pretty significant precedent. We began using it to demonstrate what responsive meant to our clients, as well as to help them understand why a more minimal design was necessary in order to make for a more responsive site. The less image-dependent the site's design, the more flexible it can be to the context in which it is displayed. Our clients needed to understand this, and you couldn't pick a more solid and visible example than a major publication like the Boston Globe.

But after having used it for more than a few demonstrations, I've realized that there are some shortcomings. I had been particularly enthusiastic about how the Globe was handling such a deep navigation. At larger viewports, it's distributed horizontally, in a pretty standard main navigation bar. As you hover over the nav items, you get pretty elegant drop-down "supermenus." But at smaller sizes, you get a vertical stack of sections. It's pretty intuitive to use.

What isn't intuitive is that once you have tapped down to a sub-section of the site — say, the Arts section, for example (shown left) — the navigation is no longer displayed beneath the masthead as it was on the homepage. In order to see the pages that exist within a subsection, you have to tap the small arrow icon that is next to the section title. It took me a while to discover this.

So, while I'm still enthusiastic about many of the ways that the Boston Globe handles its responsive design, its navigation isn't one of them. For there to be such a strong break in the consistency of the navigation is confusing and likely to be overlooked by plenty of users. I certainly wouldn't advocate for any of my clients to use the same approach.

We recently launched a fairly large-scale site for Okuma Corporation (shown above), and in order to preserve as much consistency as possible in the main navigation, we opted to use an expandable, vertical navigation display. You can tap "Menu" and see a list of the top sections, and then tap any one of the sections to see a list of the pages within. This approach can handle many levels of hierarchy — Okuma's goes down 4 levels — without disorienting the user. The only cost for users on phones is the need to scroll up or down more as the list is expanded. Additionally, this type of menu pushes down the page content as it expands, rather than displaying as an overlay above the page content.


A slight variation on this approach would be to display your expandable navigation menu over top of page content, especially if it is short enough to still reveal some page content beneath on the smallest viewports. Microsoft's Surface website, which recently launched, does just this.

We also used a similar technique on a recent site redesign for Ideas to Go (shown below). It's a vertical-stacked navigation, sort of a hybrid of The Boston Globe's, Okuma's and Microsoft's. It allows the user to expand each section and see its subpages, but it also overlays on top of the page itself.


One does not simply… shrink a slideshow!

I am less and less a fan of slideshows. I've covered this before, so I won't bore you with my gripes. But if slideshows are tricky on "desktops," you can bet they're even trickier to handle on smaller viewports.

Tap or Swipe?
When we first started doing mobile sites, we felt a lot of pressure to make slideshows work just like swiping through image galleries in iOS. Because we didn't have a solid answer as to why it wasn't a great idea, we tended to go ahead and try to make it work. But, performance was lousy. We were taking a javascript slideshow that was typically auto-rotating as well as had clickable controls, shrinking it and its contents, repositioning it, disabling the controls, and trying to enable the user to touch and swipe through each slide. But the swipe animation struggles under those conditions, and frankly, it would be better to just create an entirely new piece of content to make that work. Since then, we've tended toward tap-to-swap control, which is much more stable and just as intuitive to the user.

However, tap is problematic if the slide needs to link somewhere — like to a subpage — rather than just advance to the next slide. If a slide does need to direct a user elsewhere, but the advance action is on tap, then the link needs to be placed in a caption for slide. Camera is a customizable slideshow plugin that we've used quite a bit, but it still requires that links be placed in the caption, even if a swipe action is being used.

Mixed Content
This is another tricky issue. Slideshows aren't always just a collection of images that a user can cycle through. Often, they'll include a mixture of content, cycling between images and videos, for example. While it's pretty straightforward to reconfigure a slideshow of images for smaller screens (barring any tap vs. swipe issues), videos aren't as simple. You've got to consider what player is being used, the dimensions of the video, etc. If you're embedding YouTube videos among slide content, you can have a consistent user experience on a "desktop" size because the player can sit within the image area. But on a mobile device, that player will open the mobile OS's YouTube app instead, which is a break in interface continuity.

Full-Page Images
These are popular. But man, they are a pain in the neck. Here's the thing: the bigger the image, the bigger the file, and when the image has to respond to the size of the browser, the site has to be processing that image, which slows things down. The benefit, of course, is a very big visual impact. And it does look very cool. Check out the site we launched recently for Cone Communications, which features a full-screen slideshow that rotates behind all the other page elements.

Now guess how we made it work on smaller screens: We shrunk it! Simply! It was like walking straight into Mordor. It's not ideal, but it works. I wouldn't recommend it very often, but that's because I generally don't like slideshows. But if you need a slideshow, and if you need it to be muy grande and whatnot, then yes, it can be done.


Testing and device support is not easy.

They're great for a cursory spot-check, but they're not the most accurate representation of how things look on mobile devices. This is because each phone or tablet has its own hardware specifications, which interact with the software in different ways. The differences are often pretty subtle, but even a minor difference can matter to the user, and especially to your client. So while emulators are helpful at a certain stage of the project, they're no substitute for using actual devices for your official QA. There are plenty to choose from, though. Here are a couple I've used:

     ↑ Matt Kersley has a pretty simple responsive testing tool you can use on the web.

Matt Kersley has created a straightforward testing tool at his site that lets you drop in a URL and see it right away in different sizes — from tiny phone width to standard "desktop" width. It's pretty handy, too, for demonstrating how responsive works for someone who may not understand it yet.


     ↑ You can't always trust that an emulator is showing you the most accurate display.

There are two other emulators I've used pretty frequently: and, which let you drop in a URL and spot check its display on different sized viewports. Notice, though, in the comparison above, that isn't displaying the main image when you test for the iPad width, while shows it just fine at the same size. As it turns out, the site displays just fine on an actual iPad, so something isn't quite right with Just be careful.


Device Support
Devices. There are so many of them. New ones are coming out all the time. Few of them have the exact same screen dimensions and pixel density. What to do? We certainly can't support them all.

I think the best solution here is to look at the analytics for any site you're working on and prioritize the devices that account for the majority of your mobile traffic. After looking at the overall market share and then the device share across our clients, we've determined that we'll support iOS devices (iPhone, iPod Touch, and iPad) as well as Android devices running unaltered installs of Google's OS (the current version is 4.1, called "Jelly Bean"), as well as any other device that accounts for 5% or more of visitors to a client's site. So far, we haven't found one instance where another device — other than iOS or canonical Android — is within that 5% or more. Below is a snapshot of the mobile devices our audience has used over the past month to access our site, and only those that are unidentified ("not set") fit within that 5% or more (they're roughly 6%). But clearly, iOS devices are the ones we should prioritize. If you're grappling with this question for your or your clients' sites, save yourself some grief and let the data determine your support policy.

     ↑ Let visitor data determine your support policy!


The browser is a lousy salesman.

Since responsive design adapts page layouts based upon the size of the viewport, you can actually see it happen in real time by dragging the edge of your browser and reducing the size of the window. See below:

Neato! Except not really. See, doing this may demonstrate a distinction between how responsive works versus an alternate mobile site or alternate mobile-optimized templates, which would only show for visitors using a mobile device, but it also creates a use scenario that is totally unnatural. The whole point of adjusting the layout is to address the concerns of people on mobile devices, not people who want to reduce the size of their browser to be about the width of a necktie. Who uses their browser that way? Also, I often do want to reduce the width of my browser — if I'm referring to information on a webpage while writing in another document, for example — but don't want the layout shifting around.

Additionally, this sort of demonstration behavior creates bug-like phenomena that are confusing. For example, in the video above, I started by showing how the navigation works on Then I reduced the width of the browser until it was at its narrowest setting. Once there, I engaged the navigation menu again. This time it was designed differently — optimized for the smaller width. But when I opened the window back up again to the width it had been originally, the navigation menu disappeared and the "desktop" version didn't come back! BUG! BUG! Well, is it a bug? Not really, because what's happening here is this: When the page first loads, it looks at the viewport size and defers to the CSS to show the appropriate version of the menu. In this case, we've got plenty of room so it shows the standard "desktop" version. But then, when you reduce the width of the browser, it engages the CSS again and spits out the alternate menu. Now, it "thinks" it's done. When you expand the window again, it's not going to engage the CSS until you refresh the page. It's a bit wonky, yes, but that's because when you're on a mobile device, you don't have the ability to choose the size of your browser window. On a desktop machine, you do, so it creates this strange behavior. But it's not a bug. It's just how this stuff works.

With all that in mind, I think it's time we stopped doing the window dragging thing. It teaches us to evaluate the success of responsive design within parameters that are not true use cases. In fact, I think that in addition to responsive, we should also use device detection so that if you're on a desktop, you can't engage the media queries written for responsive design. If you're on a touch device, you can. I'm sure that's controversial, but from a client services standpoint, I think it's the right thing to do.


"Desktop" is not a size!

For most of this article, I've been putting "desktop" in quotes for a reason. Mostly, this is because referring to "desktop" as a size is about as clear as referring to "phone" as a size. They're all different. In fact, there's a wider array of resolutions on desktop displays than any other. We tend to design maximum widths for websites based upon small laptop displays, so they often cap at around 1000 pixels wide. Makes sense. But if we're interested in the best solution for smaller viewing contexts, why aren't we also interested in the best layout for larger ones?

I've got a huge Apple cinema display. Here's what happens when I open Microsoft's Surface site and expand it to fill my entire screen:

     ↑ Most websites are not designed for very large screens.

The page's elements spread to fill the screen, so there's some fluidity to the layout. But at this size, that means I'm physically turning my head back and forth to scan the page, and there's this wide, awkward gap between the headline ("Click in and do more.") and the main image.

Below is an even more common example:

The Boston Globe, which was designed with a ton of attention to smaller viewports, has a maximum width beyond which it simply centers to the window. The benefit of this is that it makes it much easier to scan and read. But there's still 50% of the page completely unused.

I don't have a clear solution ready here, but I was excited to see how Second Story handled their new homepage. Rather than stacking information vertically, as most websites do, they decided to organize the page's information in columns that cascade horizontally. No matter how wide your viewport, a handy arrow button hugs the right edge which you can click to scroll right (you can also use touch gestures or your mouse to do this). I like how this uses the entire space available without putting the user in a literal pain-in-the-neck position. It's a beautiful design.


     ↑ makes full use of your screen, no matter how wide it is.

So, the parting question for me is this: What about upward responsiveness? If we're heading toward bigger displays with much higher pixel density, how will our designs adapt to make use of them? We're all excited and sold on the concept of responsive design, but so far that has been limited to responding to smaller conditions. If we're up for that challenge, than I know we can do better on the "desktop," too.


Our responsive site is coming...

I realize there's a bit of a "cobbler's children" thing going on here, what with us not having a responsive site of our own and all. But we will soon! We've been working on a new version of for months now, and we're getting really close. Want a sneak preview? Here's what we've got planned…

     ↑ Our new homepage will sport tons of images, lots of color, and even a new logo!

     ↑ Here's a peek at what a page like this one will look like with the new design...


Let's Open This Up...

Well, that's all I've got for now. But I'd love to hear what you think. What have you struggled with? What successes have you had? What haven't I covered here that you want to know more about?

Thanks for reading!

P.S. I intentionally left out the whole responsive images thing because we're still grappling with it and haven't settled on an approach that I thought was good enough for newsletter material. So, I'd love to hear your thoughts on that, too. In the meantime, here's a brand new Responsive Images Community Group that I just heard about via some folks on Twitter.


Anselmo | June 12, 2013 6:26 PM
Great/Long article.
I tend to see responsive web design as part of a larger discipline called "Responsive Experience". In this discipline, content, form and function play together to give the user best possible user experience. The experience is definitively driven by the user medium, capacity, user context and connection (speed).
Thanks for your sharing.
Ted | January 3, 2013 9:39 AM
have you checked out
they make some interesting claims that seem to infer that they acquired 5500+ devices to do their testing and the result is...
(just have a look at their site) and do share your thoughts with us all here!

GREAT, insightful article Chris...
Jatin Singhroha | December 1, 2012 3:45 AM
Probably we should have responsive design for our blog. It should well optimized for mobile devices. If we use wordpress then we should use plugins to optimize our blog for mobile devices.
Pamela Voss-Page | November 16, 2012 5:12 PM
Thank you, Chris. I am sending your interesting article to our Student Advisory Board who are convincing me that we need to create an ap for our organization because youth use phones first. They all have phones, not computers. This is all beyond me, but I trust their insight. I will let you know their thoughts.
Fredrik Christensson | November 14, 2012 3:36 AM
THX for the mockup vid with the paper phone. So cleaver but so easy to do!The best thing with it, is so simple to show the client, web developer and the testing crew, what i mean.
Ian Westbrook | November 13, 2012 11:05 AM
Great article, thank you! However, the links to and appear to be broken?
Nathan | November 11, 2012 4:50 PM
Great article. Nothing is a silver bullet and there are tools for every job. Every project requires analysis to determine the best approach.

Honestly, I sort of felt this problem was solved in the 1980's with the MVC design pattern. I have often seen little difficulty creating separate views and reusing the business/data/service layers of a system. Especially for non-trivial designs and mobile/tablet/touch sites that that advantage of unique device resources. Regression testing becomes easier too as edits to one view do not affect others.

And other times I've found responsive design to be a nice technique, especially for certain types of sites.
Christopher Butler | November 9, 2012 3:00 PM
Jenna: Agreed. I'm going to respond to David's comment (below) and touch on this a bit more, so check that out, too.

Tyrone: In general, I'm not for adapting any site simply because a screen exists somewhere that might call for something different. I think it's better to consider who the audience is and what their needs are relative to what the site is offering. So, in some cases, a website might serve its audience quite well by designing for phone-size viewports and desktop-size viewports and then assuming the larger size will accommodate visitors using tablets. But, this depends upon the kinds of users the website is expected to get, and their unique behaviors. More on this later?

Mat, MJH, Wolverhampton, John, and David Hughes, thanks for your comments!

David, You raise a good point. The data-driven idea probably could use an article of its own, because there's some important nuance that I probably didn't communicate fully here. I certainly agree that good design is progressive, and that a simple data-driven approach to this kind of decision making could prove reactionary fairly often. What I had in mind is looking at a few sources of data and making a decision based upon what that yields. Hypothetically, that might look like this:
  1. looking at device market share
  2. looking at a website's users' device profile
  3. looking at a website's intended audience (personas) and their access behaviors
These sources go from general to very specific, and that's important. If you only looked at #1, you'd design for an endpoint that is always in flux. If you looked at #1 and #2, you'd get closer to what your audience needs, but probably be even further from what's current since you certainly wouldn't expect your audience to have the most current devices available. But, #3 is a really important differentiator. B2C personas can certainly be expected to have access behaviors that correspond with device availability — so a website like Amazon would be well served by #1. But B2B personas are much more likely to take steps along the buying cycle that depend upon website content within a much narrower spectrum of device usage. In general, we're seeing that most of them are still often at their desks (or at least on laptops) for this sort of engagement. So, prioritizing mobile as a response to the market may not always be the best choice for the audience.

All of that said, the other reason I mentioned data-driven thinking for this was to make device support more reasonable. If you're only informed by #1, which we agree is a moving target, no developer or designer could guarantee great performance across the board. But looking at a specific site's user profile can help narrow your target and make your job doable.
David (Adam's Friend, blame him) | November 9, 2012 2:40 PM
Great read!
I agree with the majority of the article, but not sure of the data driven approach you advocate. I'm not a "responsive" ideologue, but I appreciate the progressive enhancement approach. The concern I have with data driven design is it's reactionary, and can fall into the "catch-up" conundrum.

Responsive/adaptive/Mobile First approach is data informed, based on the growth of the mobile market and foresees device proliferation.

So, by telling a client they don't need something now because the analytics doesn't reflect the traffic means they may need to redesign the site next year when the analytics do.

again, great read.

David Hughes | November 8, 2012 11:09 AM
Awesome article! We've also been dealing with many of the same issues described here, especially in navigation realm.

What we're also coming to terms with is load times on smaller devices, since you're essentially loading the full desktop experience as the "desktop" version, but just not displaying all of it.

Finally, we LOVE Protoshare and use it for all our prototyping needs:
John Faulds | November 8, 2012 7:07 AM
I was in a similar position to you when it came to redesigning our site: mobile usage wasn't significant but it was kind of imperative that our own site displayed the sort of functionality that more and more people were asking for, even though I'd always ask clients to look at their analytics data before deciding to go ahead with a RWD redesign. Plus, it gave us the chance to try out some new things that we wouldn't normally get to do on client sites.

But as Jenna says, I think the point of mobile-first is not really about design, but development. During development of our site, the basics of the wide screen layout were done first (a lot of the work was actually done in the browser as we went along) but development started with the small screen layout first, with styles and effects added as the screen got wider.

If you start with small first you require less CSS rules that overwrite previous ones than if you do it the other way around (in my experience anyway).
Web design Wolverhampton | November 7, 2012 4:55 PM
Very very interesting and informative, thank you. I was pleased that you initially addressed the "do you actually need it?" question. Many assume that the proliferation of smartphones automatically mean that they *need* a responsive design, when their target audience may not. And, conversely, businesses stick QR codes on adverts without bothering with a responsive design. Duh!

We've found that the best solution (but the most time-consuming one) is to have two designs- a "desktop" design and a "mobile" design, with the appropriate one loading depending upon device type. The mobile design then has the Viewport-based responsive CSS applied to ensure that the visitor receives the best experience no matter whether they're using a tiny-screened iPhone or a monstrous Samsung Galaxy.
Tyrone | November 7, 2012 4:00 PM
Interesting article. I am curious to know how you feel about keeping mobile and desktop/tablet separate? So let's say you have a site with a max width of 1280 and degrades gracefully (responsive) to 768. Therefore theoritically your site should display perfectly across most tablets and all desktop screen resolutions. Anything below 768 will be a separate site all together. The reason I am suggesting this approach is because anything you do to your desktop site will directly effect your mobile site and vice versa. For example lets say my site is quite JavaScript intensive. If I need to add a module, I can't simply hide it in mobile, so what choices do I have. Mobile's first priority should be speed, where you could argue that with desktop you can sacrifice speed for functionality. I am bringing this up, because I have just inherited a markup that is responsive accross all resolutions. Looks great, but the same script files, and CSS files are loaded for all versions. So the site may look great at 320, but could be a whole lot faster. In my opinion, the only way around this is to completely separate your mobile site from your desktop/tablet site? What are your opinions on this?
MJH | November 7, 2012 3:37 PM
I think you're comment that you need to check your analytics before throwing money at mobile is really important. We work with people whose regular pages convert at a much higher rate than their mobile pages. Some people prefer that. It's all in the data. :)
Mat | November 7, 2012 6:33 AM
@Jenna: Makes sense to start small with the limited view of mobile devices and than get into the bigger league of widescreen displays...
Jenna | November 2, 2012 5:21 PM
Regarding "mobile first" - in my experience with RWD, I think of this more in terms of development than design. If you approach front-end development mobile first, then you progressively enhance your site using a combination of media queries and feature detection. This is an awesome solution in terms of improving performance and not loading a bunch of extemporaneous code. And it's easier just to keep adding styles, than it would be to strip them away.

Conversely, as far as design goes, I still design for larger resolutions, aka "desktop" first, as I find I don't limit myself creatively right off the bat, as I might if I were to start designing for smaller screens. Of course, if you do this, you need to keep responsive in mind and plan in advance how things need to shrink down and rearrange, but I find it's easier to go big and simplify, than it is to go the other direction.

Oh, and I hear ya on the cobbler's kids thing -- my portfolio site's not responsive (yet) either. :)
Christopher Butler | November 2, 2012 9:59 AM
Justin: Thanks, man. And thanks for sharing that link. Good stuff!

Karl, Seth, Hendrik-Jan: Thanks, guys!

Eric: You're not alone — I've heard a few people say that they prefer getting the "desktop" site on their mobile devices, and being given the freedom to zoom in on whatever interests them. It certainly doesn't bother me, and in some cases, I'm definitely with you in preferring the large site on a small screen over the small-screen-optimized version. It's just a bummer that saying so publicly makes one sound like a luddite these days...

Kayla: Me too. Hopefully some of those folks share their stories here in the comments.

Andrew: Thanks for the link, I'll check that out.

As for our disagreement, it actually sounds like we're on the same page. What I'm saying is that while good design is possible on a small screen, the design process for smaller screens doesn't always equal good design across the board. That's what frustrates me about the "mobile first" crowd. So, yes, perhaps Luke would disagree with my comment, but I'm sticking by it. Just because the constraints are greater on smaller screens doesn't mean that they'll produce better design. That's essentially what I was saying in the quote you pulled about which you said you agreed 100%. Anyway, I figured this would be a point of contention ;-)

I hear you on Protoshare. I know people who are happy with it. We don't use it, though — we use a system that is derivative of our proprietary CMS.

Thanks for taking the time to comment and get a discussion going!
Andrew | November 2, 2012 9:27 AM
Good article. It was fun to read another agency's take on responsive (I work at a web agency in Raleigh). A lot of good points in here. I especially like the section on device support. Building on that, there is an article (out today) in UXMatters that describes some of the design considerations when it comes to mobile input support:

"Thing #2 is that starting with mobile forces a certain economy of design thinking that should make for good design no matter what - whether tiny phone screen or enormous cinema display. This is just false."

I disagree, and so would Luke Wroblewski. Tackling the mobile design first will force you to think about (and hopefully research) fundamental user needs and goals. However, user needs and goals will usually differ based on the screen size, which means I agree 100% with this:
"Designing something that is a perfect fit for a phone, no matter how good the design is in terms of classical, formal considerations, will never also be a perfect fit for something vastly bigger."

One somewhat unrelated point: I have found Protoshare to be among the worst prototyping tools available. If you need interactivity, try something like Axure, iRise, or Justinmind (I primarily use Axure). None are perfect, but they can get the job done a little easier. If you don't need interactivity, I have found good success with pencil/paper (as described) and Balsamiq Mockups.
Kayla | November 1, 2012 4:02 PM
Excellent article. I think that navigation has been the most tedious part of the planning process. Responsive web is requiring that we really think "outside the box" in regards to the traditional approach of website navigation.

"Responsive design is more work. And more expensive. Maybe you don't need it as much as you think you do."--->I would love to hear from more people about what convinced them to make the leap to responsive.
Eric | November 1, 2012 2:36 PM
Another great article, Chris. Of course, newsletters can be responsive too! I've been working with a responsive template, and I like how the layout adjusts based on the width of a browser window, but hadn't thought of it feeling like a bug. Turns out the CSS on that site doesn't require a refresh to re-adjust after resizing the browser window back to full width. However, I tend to agree that it's best practice to detect the device.

Personally, I use a smartphone/tablet browser that works well with desktop-style sites (Dolphin browser). I like to be able to zoom in and out with taps and pinches. I'm surprised this isn't the general public's preference too. I actually hate most size-optimized content. It makes me wonder if others will feel the same way at some point, making mobile and tablet layouts less important.
Hendrik-Jan Francke | November 1, 2012 2:14 PM
Well done. I feel a kindred spirit in the way your wrestle with the issues.
Seth | November 1, 2012 12:38 PM
Excellent writeup. Allow me to highlight my favorite bits.

"With all that in mind, I think it's time we stopped doing the window dragging thing." - Yes, yes! A thousand-times yes!

""Desktop" is not a size!" - Exactly.

"What about upward responsiveness?" - Linus Torvalds just recently wrote a post on Google+ (oh my, the level of "nerd" I revealed in that sentence is biblical) about how laptop displays are awful with regard to resolution and pixel-density when compared to smartphones. He makes the case that higher-resolution will not "shrink" fonts as people assume, but rather allow for more attractive displays as all this "retina" business has shown. With that in mind, I think more devices are gravitating to higher resolutions which would (perhaps) allow for more scenarios where upward responsiveness would be amazing.

Great article, thanks!
Karl Mariner | November 1, 2012 11:16 AM
Thanks for writing!
Justin | October 26, 2012 4:30 PM

Great (long read) newsletter. I just watched an insightful interview with Eric Reiss in which he discusses responsive design and usability in general. Eric writes extensively on usability and is the CEO of FatDUX in Copenhagen.

↑ top