Menu Search
Jump to the content X X
Smashing Conf San Francisco

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

Why We Shouldn’t Make Separate Mobile Websites

There has been a long-running war going on over the mobile Web: it can be summarized with the following question: “Is there a mobile Web?” That is, is the mobile device so fundamentally different that you should make different websites for it, or is there only one Web that we access using a variety of different devices? Acclaimed usability pundit Jakob Nielsen thinks that you should make separate mobile websites. I disagree.

Jakob Nielsen, the usability expert, recently published his latest mobile usability guidelines1. He summarizes:

“Good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.”

I disagree (mostly) with the idea that people need different content because they’re using different types of devices.

Firstly, because we’ve been here before, in the early years of this century. Around 2002, the huge UK supermarket chain Tesco launched Tesco Access—a website that was designed so that disabled people could browse the Tesco website and buy groceries that would be delivered to their homes.

It was a great success—heavily stripped down, all server-generated (as in, those days screen readers couldn’t handle much JavaScript) and it was highly usable. One design goal was “to allow customers to purchase an average of 30 items in just 15 minutes from login to checkout.” In fact, from a contemporary report2, (cited by Mike Davis), “many non-disabled customers are switching from the main Tesco site to the Tesco Access site, because they find it easier and faster to use!” It also made Tesco a lot of money3: “Work undertaken by to make their home grocery service more accessible to blind customers has resulted in revenue in excess of £13m per annum, revenue that simply wasn’t available to the company when the website was inaccessible to blind customers.”

However, some blind users weren’t happy. There were special offers on the “normal” Tesco website that weren’t available on the access website. There were advertisements that were similarly unavailable—which was a surprise; whereas most people hate advertisements, here was a community complaining that it wasn’t getting them.

The vital point is that you never know better than your users what content they want. When Nielsen writes that mobile websites should “cut features, to eliminate things that are not core to the mobile use case; [and] cut content, to reduce word count and defer secondary information to secondary pages,” he forgets this fact.

Tesco learned this:4

“We have completely redesigned Access so that it is no longer separate from our main website but is now right at the center of it, enabling our Access customers to enjoy the same features and functionality available on the standard grocery website. As part of this work we have had to retire the old Access website.”

Nielsen writes:

“Build a separate mobile-optimized site (or mobile site) if you can afford it … Good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two websites, and cross-linking to make it all work.”

From talking to people in the industry, and from my own experience of leading a dev team, I’ve found that building a separate mobile website is considered to be a cheaper option in some circumstances—there may be time or budgetary constraints. Sometimes teams don’t have another option but creating a separate website due to factors beyond their control.

I believe that this is not ideal, but for many it’s a reality. Re-factoring a whole website with responsive design requires auditing content. And changing a production website with all the attendant risks, then testing the whole website to ensure it works on mobile devices (while introducing no regressions in the desktop website)—all this is a huge task. If the website is powered by a CMS, it’s often cheaper and easier to leave the “desktop website” alone, and implement a parallel URL structure so that is mirrored by, and is mirrored by (with the CMS simply outputting the information into a highly simplified template for the mobile website).

The problem with this approach is Nielsen’s suggestion: “If mobile users arrive at your full website’s URL, auto-redirect them to your mobile website.” The question here is how can you reliably detect mobile browsers in order to redirect them? The fact is: you can’t. Most people attempt to do this with browser sniffing—checking the User Agent string that the browser sends to the server with every request. However, these are easily spoofed in browsers, so they can’t be relied upon, and they don’t tell the truth, anyways5. “Browser sniffing” has a justifiably bad reputation, so is often renamed “device detection” these days, but it’s the same flawed concept.

On mobile, automatically forwards users to a separate mobile website.

More troublesome is that there are literally hundreds of UA strings6 that your detection script needs to be aware of in order to send the visitor to the “right” page. The list is ever-growing, so you need to constantly check and update your detection scripts. And of course, you only know about a new User Agent string after it turns up in your analytics—so there will be a period between the first visitor arriving with an unknown UA and your adding it to your detection scripts (in which visitors will be sent to the wrong website).

Despite all this work to set up a second parallel website, you will still find that some visitors are sent to the wrong place, so here I agree with Nielsen:

“Offer a clear link from your full site to your mobile site for users who end up at the full site despite the redirect … Offer a clear link from your mobile site to your full site for those (few) users who need special features that are found only on the full site.”

Missing out features and content on mobile devices perpetuates the digital divide. As Josh Clark points out7 in his rebuttal:

“First, a growing number of people are using mobile as the only way they access the Web. A pair of studies late last year from Pew and from On Device Research showed that over 25% of people in the US who browse the Web on smartphones almost never use any other platform. That’s north of 11% of adults in the US, or about 25 million people, who only see the Web on small screens. There’s a digital-divide issue here. People who can afford only one screen or internet connection are choosing the phone. If you want to reach them at all, you have to reach them on mobile. We can’t settle for serving such a huge audience a stripped-down experience or force them to swim through a desktop layout in a small screen.”

The number of people only using mobile devices to access the Web is even higher in emerging economies. Why exclude them?

Mobile Usability Link

I also agree with Nielsen when he writes:

“When people access sites using mobile devices, their measured usability is much higher for mobile sites than for full sites.”

But from this he draws the wrong conclusion, that we should continue making special mobile websites. I believe that special mobile websites is like sticking plaster over the problem; we generally shouldn’t have separate mobile websites, anymore than we should have separate screen reader websites. The reason many “full websites” are unusable on mobile phones is because many full websites are unusable on any device. It’s often said that your expenditure rises as your income does, and that the amount of clutter you own expands to fill your house however many times you move to a bigger one. In the same way, website owners have long proved incontinent in keeping desktop websites focussed, simply because they have so much room. This is perfectly illustrated by the xkcd comic:

A Venn diagram showing 'Things on the front page of a university website' and 'Things people go to the site looking for.' Only one item is in the intersection: 'Full name of school.'
A Venn diagram showing “Things on the front page of a university website” and “Things people go to the site looking for.” Only one item is in the intersection: “Full name of school.” Image source: xkcd8.

As I wrote on the website The Pastry Box9 on April 13th:

“The mobile pundits got it right: sites should be minimal, functional, with everything designed to help the user complete a task, and then go. But that doesn’t mean that you need to make a separate mobile site from your normal site. If your normal site isn’t minimal, functional, with everything designed to help the user complete a task, it’s time to rethink your whole site.

“And once you’ve done that, serve it to everyone, whatever the device.”

In a previous article, Nielsen wrote in September 2011 that he dropped testing usability with featurephones:

“Our first research found that feature phone usability is so miserable when accessing the Web that we recommend that most companies don’t bother supporting feature phones.

“Empirically, websites see very little traffic from feature phones, partly because people rarely go on the Web when their experience is so bad, and partly because the higher classes of phones have seen a dramatic uplift in market share since our earlier research.”

This is a highly westernized view. Many people can’t afford smartphones, so they use feature phones running proxy browsers (such as Opera Mini), which move the heavy lifting to servers. This is often the only way that underpowered featurephones can browse the Web. Statistics from Opera’s monthly State of the Mobile Web report10 (disclosure: Opera is my employer) shows that lower-end feature phones still dominate the market in Eastern Europe, Africa11 and other emerging economies—see the top 20 handsets worldwide for 201112 that accessed Opera Mini. Since February 2011, the number of unique users of Opera Mini has increased 78.17% and data traffic is up 142.79%13.

A caveat about those statistics: not every user of Opera Mini is a featurephone user in developing countries. They’re widely used on high-end smartphones in the West, too, as we know that they are much faster than built-in browsers, and users really want speed14.

Nielsen’s dismissal of feature phones reminds me of some attitudes to Web accessibility in the early 2000’s. His assertion that companies shouldn’t support feature phones because they see little traffic from feature phones is the classic accessibility chicken and egg situation: we don’t need to bother with making our website accessible, as no-one who visits us needs it. This is analogous to the owner of a restaurant that is up a flight of stairs saying he doesn’t need to add a wheelchair ramp as no-one with a wheelchair ever comes to his restaurant. It’s flawed logic.

Developing Usable Websites For All Devices Link

The W3C Mobile Web best practices15 say:

“One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation. Furthermore, some services and information are more suitable for and targeted at particular user contexts.”

There will always be edge cases when separate, mobile-specific websites will be a better user experience, but this shouldn’t be your default when approaching the mobile Web. For a maintainable, future-friendly development methodology, I recommend that your default approach to mobile be to design one website that can adapt to different devices with viewport, Media Queries and other technologies that are often buzzworded “Responsive Design.”

Combining these techniques in a smart way with progressive enhancement allows your content to be viewed on any device (and with richer experiences available on more sophisticated devices), with the possibility of accessing device APIs such as geolocation, or the shiny new getUserMedia for camera access16.

Although many other resources are available, I’ve written “Mobile-friendly: The mobile web optimization guide17” which you’ll hopefully find a useful starting point.

Further Reading Link

(jvb) (il)

In your experience, what kind of “mobile websites” do you create most often?22

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22

↑ Back to top Tweet itShare on Facebook


Bruce Lawson evangelises open web technologies for Opera. He co-authored Introducing HTML5, the best-selling book on HTML5 that has just been published in its second edition. He blogs at

  1. 1

    Why not just detect it via screen size? That’s all I do, redirect based off of a screen size of 320px.

    The only issue I am dealing with now is how to properly set a cookie to allow the user to view the Desktop if they like to.

    • 2

      David Bushell

      April 19, 2012 6:50 pm

      This is a fundamentally flawed idea. My Galaxy Nexus is a mobile phone but larger than 320px. What about the Galaxy Note? that’s even bigger! The reality is “mobile” in any context is almost meaningless to us and implies nothing of the users context or intent.

      • 3

        @david: I totally agree with this! I’d rather know if the device is a touch screen (fat tap targets, swiping and draging come naturally), a desktop/laptop (precise pointing and clicking), or something else like a tv (most controls are unwieldy and need fat targets or expect arrow movements, user is sitting 10+ feet away) or if the interaction experience is way different than anything else.

        also, many people use their phones while just sitting around and might actually just want to read your long form articles and not get directions or anything related to being on the go.

    • 4

      By no means am I saying that 320 is the solution. I was just shooting an example of changing the site based on the users screen size. Of course mobile screen are not created equally.

      I personally like the idea of creating 2 sites. A mobile user is going to most likely have a different reason to use the website. More often than not mobile users are looking for important information fast. They do not want to be overloaded with useless information which can slow down their ability to find what they want. I haven’t seen this easily accomplished with only a stylesheet and js without causing more headaches then needed. IMO.

      But if they do want to enjoy the entire experience, just give them the option to go to the full version.

      • 5

        So what you’re saying is that its ok to overload desktop users with useless information and slow them down? How about turning things around and actually keep the website simple and to-the-point, so that everyone, no matter the device can find what they’re looking for, quickly?

        • 6

          Most of that “useless information” is stuff that I use on websites. Mobile sites often are missing things I need, so I have to turn off the mobile view in my phone’s settings.

      • 7

        “They do not want to be overloaded with useless information which can slow down their ability to find what they want”, Desktop users don’t want to be slowed down by useless information either.

      • 8


        I can’t believe i need to break this down… What I am saying is the desktop version of a website has much more real estate to work with when it comes to providing a user with information. When it comes to a mobile website, you need to understand the “WHY” for a users visit in a micro sense since you only have a small area to work with.

        Someone that wants to visit an airport website on their phone are most likely doing this to check flight delays, book flights, or modify existing flights. So providing the most useful and commonly tested on-the-go areas the easiest is important. So for some websites this is can be a hassle because their website has tons of extra areas that can be important for some, but will just get in the way for most on the go users. So I am simply saying that its important to look at your audience again in a mobile sense and see whats important and what isn’t. And for some sites having 1 website and modifying the css/js may not be as easy or needed in comparison to creating another version of the website.

        • 9

          You’re making the wrong assumption that desktop users run their browsers in full screen mode. Not sure about others, but I never do that – in fact I rarely have it at more than a third of the screen size, unless some thoughtless web designer forces me to blow it up.

          When I have more screen real estate available that in no way means I want the browser to use that. I have plenty more actually important applications that I want to put there!

          • 10

            I guess I am just not being clear in what I am trying to say. Do a Google Search on “Understanding Mobile Context” and read up about what I am saying about there not being a 1:1 web experience between Desktop and Mobile users. And perhaps I am reading these responses wrong but it sounds like people think that they should have the same exact experience no matter what the device is because apparently the people viewing the website fall under the exact same audience as a desktop user. This I do not agree with, so instead of further trying to put words together to explain why I do not agree with this, please just Google “Understanding Mobile Context” and read up. If you have a account, look into their Mobile Fundamentals course and they have a great chapter video that talks about Mobile Context.

          • 11

            I do notice that we may be talking about 2 separate things though, in a way. The future is with Responsive Design, so yes 1 web works and you can just modify it properly for mobile if you have set up your site to be responsive. Mobile Context still applies here but its all one website.

            I was speaking more in the beginning about website that are older and are not responsive. These types of websites will be much more difficult to convert to mobile which is why I was leaning towards the importance of selecting what to have and what not and how best to approach it. I have recently been converting some of my old website to mobile and I have had the easiest time and most success with making a separate trimmed down website that the full site redirects to. I would love to make these sites responsive but budget is the issue with those clients.

            So I’ll agree to disagree, I agree if the site is responsive and I don’t really agree 100% if the site is not. Fair lol.

        • 12

          *edit, was replying to you Travis but you posted 2 more responses while I typed this, which I think you make yourself clearer. :)

  2. 13

    While I admire the one site different device experience that I get on Smashing magazine’s site from a usability and technical standpoint I don’t think it works for every site out there. Your article pits these two options as fighters in a cage math where only one should be left standing and become the standard across the web. Having worked in a large company that is currently working through its ecommerce and social web mobile solution I can definitely see the benefits of both for different types of sites. Removing content for a mobile version is not always a bad thing and isn’t always done in excess. The point in removing content is to provide a better user experience for the device and most companies really seem to only strip out things that make sense. I also think you’ve given browser detection a bad worse wrap than it deserves. If you have good metrics on the major types of devices requesting your site you can make educated browser detection decisions about when to show mobile that allow the lions share of users to experience the correct view. In general I feel like your article argues that we should build to every possible user instead of playing to 90% of our users and giving them the best experience we can. I can see the benefits of both and it seems like these should be tools we use when making these decisions not standards for everyone. Overall I enjoyed it. Thanks

    • 14

      I kind of agree with you, but if you are cutting “excess” for the mobile site, is the content actually needed at all then. I know clients want to try to explain every single aspect of their company and products, but many are long winded instead of browsable by the human brain.
      If you are cutting excess maybe it is not needed in the first place and maybe then the two sites can be one site just using responsive layout or mobile redirect. If a phone can view 1028px wide then the phone maker has probably pushed too many pixels into a 4.5″ screen.

      Either way. If something needs cut, then maybe it should be cut from the main site as well as the mobile site.

      • 15

        “…if you are cutting “excess” for the mobile site, is the content actually needed at all then?”


        • 16

          …is stupid.
          It’s like saying “Do you really need all the stuff in your big house ? Look, some people have small flats, just a bed a table and two chairs.”

          Why isn’t the iPad just a big iPhone ? Why aren’t the app stores the same ?

          Oh by the way, you have to build two separate websites : one for desktop and one for mobile devices. Unless you love losing your time hiding content, maintening complex javascript, steal the advertisers, send several dozen or hundreds of useless kb to the user, etc.

          iPad example again : apps on the iPad are different from iPhone apps, and they are great. The iPad is a hit.
          Android tablets have “responsive” meh apps and don’t sell well, even if they are cheaper, more powerful, play flash, have usb/sd ports…
          This is the price of responsive design vs finely tailored software.

      • 17

        I never said they were cutting excess content. I said hiding content that isn’t mobile friendly isn’t always done in excess. In general you just can’t fit all of the functionality of a full-site webpage inside a smaller screen, no matter how you design it. It doesn’t mean that content isn’t desired, just lower in the list of priorities.

        It seems like much of this debate boils down to a purist vs practicality debate. Yes, there are costs to whichever approach responsive or not. That doesn’t mean that one approach can’t be done in an elegant way with understanding regarding the limitations of that approach. Not every website is created the same way. You can’t use the same approach in every real world case. Maybe one day far off in the future we can agree on some standard, but my guess is that by the time that is possible the game will have changed again.

        I stick to my argument that both ways can be done well and that both are tools for us to use in this amazing career.

    • 18

      Craig Sullivan

      April 21, 2012 11:43 am

      I can’t agree more – it’s about how you do this ultimately and the intent and outcome from a user perspective.

      It’s perfectly possible to use a mixture of techniques and yes – most people should be worrying more about how many % of people can use the device that arrive at their site, rather than whether their UA string detection misses 0.2%.

  3. 19

    Thanks for this article, Bruce

  4. 20

    Great piece! Global usability is often not the priority it should be. A different angle on the subject that should be considered.

  5. 21

    Jakob Nielsen

    April 19, 2012 6:50 pm

    Thank you for taking the time to consider the usability research and responding to my article.

    There only seems to be one factual error in your article; the rest is a matter of interpretation.

    You write that the reason full sites have low measured usability on mobile devices is that “many full websites are unusable on any device.” While I agree that many websites have lower usability than I would like that’s not the explanation for the research findings. Remember that the statistics show lower task completion rates for full sites on mobile phones than for those sites on desktop computers. So the full sites can actually be used. (Even if they could surely be better.)

    You are right that it’s a Western perspective to stop running usability studies with feature phones. However, the standard rule for all usability research (not just mobile) is to test the environments that paying customers use. We conduct the research to help our clients maximize their conversion rates. If we had a client in Africa, then for sure we would test with different set of devices than what we use to help American, European, and Australian clients maximize their online profits.

    Several thousand people have been to the training courses in mobile usability, and this audience peppers us with questions but they never ask about designing for feature phones (not even when we presented the seminars in China). In fact, in past years when we did cover feature phones in the courses, a lot of people wrote on the feedback forms that we should remove this material to make more time to discuss touchscreen phones. I do listen to audience feedback, so we did what our paying customers requested.

    Returning to the main question as to whether to let the user research determine design guidelines. I continue to believe that this is the best idea. I have been through many cases before, where entrenched billion-dollar interests protested against my usability findings. Just a shortlist: the entire telephony industry protesting that WAP is the Wrong Approach to Portability, the many advertising agencies that conned their clients into using splash screens or other glamour-design during the dot-com bubble, the Flash designers who didn’t like my “99% bad” conclusions, or the PDF lobby disagreeing that “PDF is bad for human consumption.”

    In all of these cases, most people eventually came around to accept the usability findings. In the long term, it’s more profitable to design for users than against them.

  6. 22

    Mike Petrovich at Pixel Chefs

    April 19, 2012 6:52 pm

    I agree with your conclusion, but not quite with the reasons.

    I wholeheartedly agree that a site’s URL should be device agnostic. With the ever-increasing variety of devices today that span the entire continuum from high-powered desktops to midrange tablets to feeble phones, it doesn’t make sense to segregate devices into discrete “desktop” and “mobile” camps.

    However, it’s all about CONTEXT: what you show to a user on a 27″ desktop can be very different from the needs of a mobile user using a 3.5″ touchscreen. The desktop user is typically sitting at home or work and spending relatively long stretches of time interacting with your site in more complex ways. The mobile user typically has additional bandwidth and time constraints but more importantly different objectives in their use.

    Take an airline website, for example. Booking usually occurs closer to the desktop end of the continuum, whereas users near the mobile end are typically more concerned with checking in and verifying the status of their flight. These are potentially inaccurate assumptions, and your analytics data may indicate a different trend. But the point is the same:

    People use different devices in different contexts, and thus their needs in each may be different. Analytics and behavioral tracking data can reveal patterns of use that will identify what content and functionality is important to users in each device context.

    • 23

      Amen. Mobile design needs to consider context first. The airline site is a great example. I’d add that desktop users are quite often multi-tasking, and mobile users are quite often “tapping and going.”

      Of course, good designers don’t assume any of this (as was implied earlier in the comments). They get real users to show them how they need to use the site they are designing.

      Here’s my question though: is there any reason why good, restrained mobile design (and content strategy) can’t be built with proper responsive techniques? From the tone of the articles coming out these days you’d think it’s one or the other.

      • 24

        Scott Reeves

        April 22, 2012 1:36 am

        Context *can* be very important, but how many of you are actually making airline websites? I think the airline site is an overused example and an edge case.

        Studies have shown (check Luke W’s site) that many times people are browsing from their couches. I know I am right now, on a 3.5″ screen. For me right now, the fact that I’m on an iPhone does not translate to me being a hurried businessperson rushing to their destination. It’s just the device I happen to be using.

        We are still figuring this stuff out, but I believe responsive techniques will only improve, and I’m amazed at what is possible even in these early days.

  7. 25

    Bruce: can you please provide concrete examples of sites that:

    * Are mobile optimized. That is; on a 3g connection they are fast to download, and do not waste my bandwidth cap.

    * Looks good on desktop. That is; they are not more than 50% “white space”, or use overly large buttons for no apparent reason than to fill space at the very least. The verge is a good example of a content rich site that looks good. no basic wordpress default look-a-likes.

    * Has all the content you expect on desktop. For example, (large) Thumbnail images, metadata (author time posted, etc), article excerpts, etc. without sacrificing SEO

    * Does not have anything unnecessary on mobile.

    * Functions well in other devices, like the google tv browser for instance. or opera on the wii even! after all, one web also means things other than shouting ‘mobile first’.

    * Supports feature phones. (with stock browsers, which may or may not be opera mini)

    The only site anyone has ever put forth when I ask for specific examples (i note you don’t show any in your article) is the boston globe page. But it’s really simple and plain ( intentionally, it looks like the physical copies of the globe ) so it’s not really a good example.

    Also, how does one target a phone vs a monitor vs a tv, when phone screen densities are increasing so rapidly. after all, you don’t want to display a set of touch optimized css to a netbook, would you? or to a tv.

    • 26

      “Has all the content you expect on desktop. For example, (large) Thumbnail images, metadata (author time posted, etc), article excerpts, etc.”

      ^^ THIS ^^

      Sometimes I really think people are arguing just for the sake of being contrary. OF COURSE we expect a richer experience on a desktop than on mobile. If you expect otherwise, you are in the minority. Some people may want the same on their mobile device as on the desktop, but VERY FEW people want less on the desktop version just to accommodate mobile functionality. The fact that sites may relegate the most useful information to secondary pages does not mean good desktop design is nonexistent.

      I’m working with a website right now that was designed for desktop (but works fine on smartphones) and gives all kinds of information in blocks and columns and fading graphics and embedded YouTube/Map/Calendar and whatnot. But a lot of our users just need access to literature, and they will often be accessing that from mobile devices. So I’m looking to create a version that is only a menu page with over-sized buttons to lead to the literature. Very easy to use on a mobile device, but it will look terrible on a desktop screen. Does anyone want a desktop screen with nothing but 5 big buttons on it? OF COURSE there is a difference.

      On the desktop version there is more information about the products. But for people only wanting the basic information and corresponding literature, this will only serve to clutter up the page. If a customer wants to review the technical guide before a job, is he really interested in complementary products? Unlikely. It doesn’t make the information less important, just less relevant. If he’s perusing the site in his off time, he may very well be interested. So THEN he can view the full site. But in the heat of the moment, if the page takes longer to load or is harder to navigate, is he going to be thankful I was thorough or ticked off because I’m wasting his time?

      So I won’t prevent mobile users from accessing the main site. But to force them to wade through an extra page of thumbnails and block layout seems very anti-mobile-friendly in my book. Whereas, I don’t think anyone with a desktop browser wants to view a page designed for an iPhone browser in portrait mode. Maybe 15 years ago, but not today.

  8. 27

    Pre Priyadarshane

    April 19, 2012 6:02 pm

    Well written argument, but I cordially disagree. There is no right answer to “if a separate mobile site should be created or if the design should be responsive.” The answer to this question is dependent upon the website user’s expectation.

    In most cases, responsive designs make up for a poor user experience since content is not optimized for mobile. Mobile users expect results faster, and want access to content quicker. Content that is written for a desktop user does not accommodate a mobile user at all times.

    For instances where users will take time to go through content and are looking for detailed information, responsive designs are better.

    Though it would be great for businesses and designers to work on one site for all, the unfortunate truth is consumers access content from multiple devices, and the use case generally differs from one device type to another. Content that is optimized for each use case and a solution that addresses your user needs is your best bet.

    As mentioned in the article, it’s always a best to ensure that mobile users do have the capability to switch to full site.

    • 28

      Dylan Valade

      April 19, 2012 9:18 pm

      +1 agreed, the tiny mobile version should not load all the graphics and assets of the desktop version. It should load a fraction of the files and file size but make it easy to choose switching to desktop mode to load everything.

      Responsive design is really tough to do well and it especially frustrates me on sites like this. I’m using a smaller external monitor and the ENTIRE screen is taken up by the header and main menu because I’m a few pixels shy of the next media query width. I can only see half of the H1 without scrolling down. I’d rather see the ads in the right column and be able to scan half the article when the page loads or just jump right to the text and photos.

      • 29


        April 23, 2012 5:55 am

        “Mobile users want to see our menu, hours, and delivery number. Desktop users definitely want this 1mb png of someone smiling at a salad.”!/wilto/statuses/63284673723375616

      • 30

        There is a take away here. The top of smashing at a particular width is just stupid, especially on the content pages, the categories could be after the article.

      • 31

        So I work for an IT company, and was assigned to read this article, and I just wanted to say I wholeheartedly agree! I’m not a techie, but I do have a tablet, and I often find myself switching to the regular webpage instead of viewing the mobile website. I am used to seeing the regular websites, and I can’t find the stuff I want on these new websites. It is very frustrating. Plus I don’t really feel they are that much easier to use, so why move everything around and confuse me?

        • 32

          If you cannot find what you want on a website, regardless of whether it is a desktop or mobile version, that is purely down to the way in which that particular site has been structured. I would say that it is far easier to ‘drill-down’ into the required content of mobile sites that I have seen (done).

        • 33

          I think you kinda missing the the point here, yes I too prefer to see a desktop site on a tablet because of the screen size! But sites for mobile users is a must,,, if only for load time! A link to the desktop for further info is a good idea! x

    • 34

      Craig Sullivan

      April 20, 2012 1:03 am


      I think everyone involved in the ‘is a separate site bad/good’ argument is kinda missing the point.

      A bloated site like some I see with hundreds of Kb payload on the pages, will just suck, regardless of whether it is a separate site, a responsive design or some new hybrid yet to be invented. It doesn’t matter.

      If you look at a British Airways or other airline App – the best of them don’t remove the soul or content from the web desktop version – they provide a fast, easy way to do tasks in the likely context. I’m not browsing a responsive design and tilting the screen whilst I’m legging it for departures. I think the debate about the transmogrification or not of desktop content focuses on an issue that is NOT THERE for users.

      It’s about how well the site is put together, from a total service and user experience point of view. If you’ve done handset testing, performance testing, tuning, tweaking and design work for a worldwide mobile audience, you’ll know how hard it is to get this right, regardless of which particular approach you take. Hands on practitioners for building this stuff will show you great designs that express the service, content, experience in a way that works well on the device that turns up at your doorstep. It isn’t a factor of separate vs. content integrated sites at all. A lousy experience does not discriminate.

      There – I said it. It’s not about us arguing about it. It’s about them – yes, the people who get slow, cruddy, poorly tested, bloated or irrelevant mobile sites. It’s not enough to single out a particular method and say you like or dislike it so strongly, when there is a bigger issue at stake.

      I also have scant evidence that people care about this. They care about the experience, regardless of how you deliver it. They care that it works on their handsets. They care that it allows them to achieve their tasks or goals. They care whether the contact options suit their budget. They care what your page load time is like. They don’t care if it’s a separate mobile website, as long as it is built for their needs.

      I sometimes look on at this stuff and feel sadness that we devote so much time to debate and little to action. I met a huge group of small businesses in Northern Ireland (SMEs) and their main problem was not knowing how much mobile traffic they had and (b) Not knowing where to start with building something easy to start with and not expensive, for their customers. That to me seems to be a bigger problem than our feelings an opinions on separate mobile sites.

      User agent string detection is a lousy way to do this stuff Bruce – kinda clunky for the reasons you describe. There are plenty of plugins or indeed page level code, which will get you access to Deviceatlas, WURFL or indeed a combination of several techniques. There are PHP, .NET and other server side integrations that take the hassle away from device detection. Bango, our analytics provider, for example – does very detailed featurephone analysis for us worldwide because they use a number of detection and carrier level identification. That’s why they can tell us the phone model, and it’s local marketing brand name. My point here is there are ways to do this better than what you describe.

      Don’t get me wrong here. When I can haul the CMS into shape, I’ll deliver a great experience through a complete re-architecture of content that’s planned. That will give me the ability to do even more than we achieve now with our mobile website & app coverage. The problem for a lot of website owners is that sometimes their IT resource is either busy, slow to change, reluctant to invest or just expensive. The changes that are required to build or design this capability will take some time – in a tough market, you’ve got your work cut out already to price up CMS architecture work.

      So – to sum up. I think the debate has a point – a crux – which is not shared by customers. People care about the experience on their device, not a design methodology. It’s merely a debate about the colour of a bridge, not the underlying architectural merit.

      Secondly, we all need to something to help people design stuff, not patronise or browbeat them. I sometimes feel that an often inward looking debate fails to include the real people here. Those millions of users who get a duff experience.

      I’m a trained UX guy but still fall into the trap of letting ego and opinion bias my decision making. I use listening to customers to keep me grounded. In this debate, I think they’re simply missing.

      • 35

        Stephen Martin

        October 2, 2012 6:29 pm

        So enjoyed your response. Especially this part.

        “I also have scant evidence that people care about this. They care about the experience, regardless of how you deliver it. They care that it works on their handsets. They care that it allows them to achieve their tasks or goals. They care whether the contact options suit their budget. They care what your page load time is like. They don’t care if it’s a separate mobile website, as long as it is built for their needs.”

        Thank you for your wisdom and insight regarding this matter.

    • 36

      Angelos Chaidas

      April 20, 2012 10:45 am

      +1 on Pre’s comment. In my humble opinion, it’s the actual structural markup of your page that will be the ultimate deciding factor on whether you should go responsive or separate.

      Case in point:

      You have a {admin system / stats system}, something with long forms (most of them split into multiple columns), image + file upload functionality, several 100% width flexible tables with several sortable (via js) columns of statistics. You have a dashboard with javascript charts and gauges. Think Google Analytics and subtract some of the complexity.

      Imagine trying to shoehorn this into a mobile version using UA detection / viewport sizes etc. Even if you go modernizr.js crazy, have separate assets (images, CSS, JS) for each device, you still have to deal with the fact that structural markup such as long tables of stats data cannot be viewed on a mobile device in a helpful manner.

      On the other hand, a separate uber-lean version of your HTML with tables abstracted to long lists (sortable / filterable) with it’s own JS / CSS and image assets would be quick to set up, code and manage.

      And of course, let us not forget the fact that many mobile users have data plans: is 6.43kb in size, one order of magnitude less than, which is 76.66kb in size.

    • 37

      Diana Magers

      May 7, 2012 4:24 pm

      I totally agree. Users don’t want to limit their access to just desktops and/or laptops. In todays world people are on the go more and more and they want to be connected at their finger tips.

  9. 38

    Matthew Lapidus

    April 19, 2012 6:03 pm

    Absolutely wonderful article! Summed up and explained things in a way I have been trying to get across to some high level business owners for a while. And the XKCD Ven Diagram, is a perfectly simple way to illustrate what you do and don’t need! Great Read!

  10. 39

    Whilst I agree with you Bruce, I would say that browser sniffing is perhaps easier than checking your analytics’ logs for new user agents:

  11. 40

    To say “we shouldn’t make seperate mobile websites” is founded if you think websites themselves are being created correctly in the first place. This sadly isn’t true.

    HTML5 doesn’t help either, in that it is trying to do what XHTML also couldn’t do with the pros of XML … have one content and have multiple sources style it.

    The information highway is a phrase that isn’t used much any more, but I like to think that a one web approach is only going to work properly, if you can really think of web design as something outside of content. Web design can itself be content if you create web designs of course, but most of the internet (Facebook, Hotmail, Youtube, eBay, Google Docs) is about accessing content … how people get to that varies, through devices and platforms. This is where I think the problem lies … mixing web design (the means in which to access and navigate content) and actual content (that which people want to access and maintain in a central place).

    All platforms are merging and cloud is taking pace for a good reason … we should want and should have one version of content and allow that to be copied/manipulated/shared be others. The appearance and functionality of how we access that content is where there is and perhaps will always be room for differing layouts and designs, but the content itself always has and likely always will need to be presented differently … afterall, we recycle content all the time and people don’t have a problem with that. So why should content look the same on each device!?

    Web designers should either make multiple versions of content to put as much bread on their family’s table as possible, or wait for the day that web design has little to do with content we finally understand that web design itself has been getting in the way of one web.

    I agree with others sentiments that there is alot of interest in getting our work done right, so that people can benefit and that we can make a living at the same time. But as has already been said by others, technology has continued to demonstrate it’s ability to handle and cope with more and more content. If 3D mobile projectors appeared on the market in 2 years time, do you think 1080 video on 2D websites is still overkill for mobile devices!? Those 480px websites are going to adapt pretty badly then, and the whole while desktop resolution websites like Apples have already been accepted on mobile devices, so people have spoken I guess. The only question really, is which is going to make you more money in this industry and my feeling is chasing the multiple versions (that is at least how I approach the issue) even if I feel technology will prove it to be a temporary fix like WAP was.

  12. 41

    I completely agree that mobile sites are a waste of space. I have not visited a mobile website yet where I have not had to switch (or more annoyingly spoof my user agent) to gain access to some content.

    You might be able to argue in theory mobile sites have an accessibility advantage, but real world testing to my mind proves that they are always poorly implemented and maintained. Perhaps it is all down to poor resource management, but this appears unlikely especially as the massive companies cannot do a half decent job.

    I believe the current state of mobile sites is strong evidence for using your resources to make “desktop” sites more mobile friendly and bandwidth conscious than splitting the systems.

  13. 42

    Next time Jakob Nielsen says something, here’s what you do:

    1) Go to his website and look at it.
    2) Ask yourself, “Would I call this person a ‘usability expert’?”
    3) Say the word “no” out loud.
    4) Move along.

    • 43

      The next time “Matthew” says something, here’s what you do:

      1) Does he have anything constructive to add?
      2) Does he understand the difference between pretty and usable?
      3) Does he understand that a person’s website not neccessarily reflects the latest in web design? Similar to how only recently got an overhaul? How one can talk about football without actually being a pro player?
      4) Does he have anything better to offer than Nielssen’s DATA-driven usability research amongst thousands of users and businesses over 2 decades?
      5) Say the words “hell no” out loud.
      6) Move along.

      • 44

        I’m sorry, but nowadays, and probably always, “pretty” does play into usable. You can bother yourself with employing the base necessities of “usability” all day long, like Mr. Nielsen, and end up with a “usable” website that no one actually cares to use. This is, for the most part, a visual medium, and the visual nature of design, print or web, is an inherent part of it’s usability. If you’re creating a website for all, or mostly, disabled users, then by all means, Mr. Nielsen is probably a fantastic resource to base your decisions off of, but for the rest of the real world, employing his concepts in whole, or purely, may make your site “usable” but not a lot of people are going to bother using it.

        • 45

          I absolutely love web design, however you can have the most amazingly designed page on the internet but if it’s unusable and the content sucks, nobody will use your site. However, Google has proven that if your content is top priority and it’s easy to use, it can excel. Look at the most popular websites today… how many of those are what you’d call “pretty”. Not many, if any.

    • 46

      Matthew and his “thumbs up” supporters have an obvious flaw in their “what makes a website usable” knowledge. “Pretty design” can make a website more usable, but it’s not a requirement. There’s a little company called Google that would agree with this.

      • 47

        Google is pretty, unless you’re talking about the most basic of services. Even allows you to insert your own background image, and don’t forget the doodle. Add to that something like Analytics which looks good and was just redesigned by them. I doubt Google would agree that stark usability trumps style. If it did, 90% of the readers here would have careers. We’d all be using Lynx and liking it.

  14. 48

    Just a niggling little complaint: you don’t provide a link to the xkcd website, which is part of his license terms.

  15. 50

    Niels Matthijs

    April 19, 2012 7:18 pm

    One of the biggest problems we are facing today is the pragmatic approach most people are taking when facing web design. Rather than figure out what the best practice should be, people are using temporary arguments as motivators to develop best practices.

    Of course one site is better than two separate sites. It’s the only way the industry as a whole can move forward. You debate for hours about speed and loading times, but those arguments are tied to current technologies. While definitely important, they should not be considered when developing your original best practices. They can only be used to deviate from those best practices.

    Why is this important? Because now is the time to develop and fine-tune patterns that will be used in the future. There really is no good reason to emit content for mobile users. Sure you may guess that when I need speed when browsing on my phone, but for all you know I’m sitting on a train and I have all the time in the world to find certain content or to complete a certain action. Stats may indicate this isn’t the case for the majority of users (yet), but what about two or three years from now.

    If we keep looking at today and tomorrow, our industry will remain fickle and juvenile. Best practices should be developed with correctness and future opportunities in mind, only then can you deviate from them because the current standards don’t allow it yet.

    When I find a site doesn’t have the content on mobile (which I know it is there and which I need right now), you just pissed me off royally. That’s what you get for second-guessing people’s “context”.

  16. 51

    Couldn’t. Agree. More.

    Especially with: “you never know better than your users what content they want.”

    Though, I would add “or how they want to view it.” What bothers me about much of the mobile web and responsive web discussion is the idea that we can automatically anticipate how people want to view a website, so can remove that control from them. No, no, and no. The most important part of any mobile website is that link over to the full website, just like the most important part of any “responsive” website is a link to suppress the responsive features.

    Users want and need the two “cons” — content and control. Remove content by offering only the content you arrogantly assume mobile users want, or remove control by arrogantly assuming you know how users want to view that content, and you are delivering frustration to your users.

    • 52

      Douglas Bonneville

      April 20, 2012 5:13 am

      Quote of the Day:

      “The most important part of any mobile website is that link over to the full website…”

      Never was a truer truism spoken :)

  17. 53

    Thank you for bringing up the fact that though RWD may be ideal for many (most?) situations, it is often not the pragmatic choice when you’re dealing with a website that can’t be scrapped and re-architected to be mobile-first RWD at this time.

    As a UX person, I mainly work on websites with thousands of pages, multiple audiences and tasks, and plenty of 3rd party and legacy systems. For one of my clients to “do mobile right” with mobile first and RWD, it’s a massive investment of money and people. From planning to implementation, it can easily take a year or longer to launch if they can even afford it this year.

    So if you can’t redo your web property entirely, what can you do for mobile? I find myself recommending structured content/COPE mobile versions or entirely separate mobile experiences because any thoughtful mobile solution is better than no mobile solution at all if we can’t afford or can’t re-IA, re-design and recode for RWD.

    Plus, it’s funny that no one is mentioning that Nielsen’s article is based off user research conducted somewhere between 2009-2011. How do you do research that includes a technique that doesn’t exist? Or did I miss something?

    And lastly, from these posts here and on .net, I’m hopeful we can take this discussion past coding technique and talk more about what the users of the end product need. Lots of comments and blog posts seem to come back to some tired debates…a few tropes I’ve pointed out here:

    • 54

      Jakob Nielsen

      April 19, 2012 10:36 pm

      It’s actually not completely true that the usability studies were conducted during 2009-2011. We started doing mobile usability studies in 2000. In fact that first report is now available for free download: Even though it’s technically obsolete, there are many interesting observations about user behavior that still hold. That first study is when we concluded that killing time is a killer app for mobile.

      Plus, of course, we continue to run new studies – whether for clients or to update the seminars. I don’t always write about them if they’re confidential or if they simply confirm prior findings with new examples. The new video clips look good in the seminars, but I can’t show them on the website.

  18. 55

    Thomas Yuill

    April 19, 2012 9:20 pm

    May I post an example where a 2 template approach proves to be advantageous.

    A brochure type site where the full screen is leveraged to showcase the products. The layout is beautiful on desktops and tablets but not functional for a smart phone sized display. The solution was to create a CMS with one content repository and serve it in 2 separate templates. Both templates serve the same content but utilize a layout optimized for the intended audience.

    template 1 ( )
    for desktop and tablets utilizing “responsive” full-screen HD media.

    template 2 ( )
    for touchscreen/smartphone devices utilizing a less resource intensive template.

    You can effortlessly switch between the mobile and desktop experience of every page by replacing “www” with “m” and visa versa.

  19. 56

    Whatever avenue you decide to take, I agree that giving the user an easy wasy to switch to the full version is a must if you’re going to go with a mobile site.

  20. 57

    Eduardo Santos

    April 19, 2012 9:53 pm

    It really depends on the kind of website we’re designing. And to be honest I disagree with the author of this article, since I personally believe that in a usability point of view, we should always strike for what is better for the user.

    Making a large website responsive will create many usability issues. Making 2 distinct versions with the same “feeling” but with improved usability for each device will most likely win over the responsive option.

    I personally believe that responsive design is good, but mainly for small/medium websites. But take an example of a large marketplace, and you’ll need a mobile version most likely.


↑ Back to top