Nielsen responds to mobile criticism

Jakob Nielsen's recent post outlining his recommendations for mobile sites based on large-scale usability testing has come under fire from others in the industry. Here he responds to some of the main criticisms.

.net: The strategy of forking content for separate sites has been described as "a content strategy nightmare" – it's too hard to maintain and will result in inferior experience for users.
JN: I would assume that most industrial-scale sites would be generated from a single back-end product database and content management system, with the different designs represented by templates and rules about what information goes into what version.

Yes, this will still be more work to maintain than a simpler situation with a single set of templates. But the multi-site strategy should only be pursued by those companies that do substantial business with both desktop and mobile users. Many companies and government agencies have products and information that don't speak much to the mobile use case, and they can usually get away with having a single website that's optimised for desktop use but with some adaptations to make it reasonably accessible on mobile devices. Conversely, there may also be services such as Instagram that only really cater to mobile users and which don't make much sense on a desktop computer: such sites could have a single site optimised for mobile users and offer a substandard user experience to their few desktop users.

All of this is really a matter of budgets relative to the expected profits from serving customers better by optimising the user interface to their specific circumstances. Small organisations can't do so. Companies that make lots of money from each user should do so. In the extreme case, a company might need six different designs: feature phone, touch phone, mid-sized tablet, full-sized tablet, desktop computer, interactive TV. (See my article on transmedia design) Very few companies would actually deliver six designs. This would only be done by services like the weather forecast, sports scores, and stock quotes that are extremely widely used. The vast majority of companies that come to our training courses on mobile usability don't bother with feature phones anymore, even though they still account for the largest share of the world's users.

.net: Cutting out content for the mobile use case is problematic because for about 25 per cent of those who use the mobile web, it's their only use case – they don't ever use a desktop browser. Aren't you treating those users as second class citizens if you cut mobile content?
JN: No, to treat users well, you should optimise their ability to do tasks with the device at hand. If somebody only has a mobile phone, they are ill served by a design that's awkward to use on mobiles. When you actually observe people attempting tasks on websites, you see a huge number of painful failures when the poor users are given full desktop sites.

Studies show that content is harder to comprehend when viewed through a small viewport with less context than what's visible on a bigger screen. Thus, we can enhance mobile users' understanding of the information by writing shorter content that's easier to understand. What matters is the amount of information in the user's brain, not the word count on the screen. And people understand more with content that's optimised for their device.

If users do want the longer and more complex information, they are always able to click through to the full site.

.net: When mobile users tap search engine results that refer to content on the full site, they're often redirected to the mobile URL. But if the content doesn't exist on mobile they get dumped on the homepage.
JN: This is a good point, and presumably the redirect should only happen for material that's actually available in a mobile format.

.net: Multiple URLs for a single piece of content is often thought of as a bad idea.
JN:There are at least three different ways of implementing different user interfaces for different devices:

1. Each version lives at a different URL.
2. The same URL serves up different versions, depending on the device used to request the page.
3. The same code is transmitted to all devices, and the client side transforms this into the different designs, using responsive design.

As long as each user sees the appropriate design, the choice between these implementation options should be an engineering decision and not a usability decision.

.net: Why have you made no mention of using Responsive Design?
JN: Because I was writing about user experience, not implementation. As mentioned above, responsive design is one of the ways to achieve different user interfaces for different devices. It should be up to the engineers to determine the most efficient way of achieving the user experience goals. All we usability people should decide is how the site should work for users, not how this is implemented.

However, I do see some potential downsides of responsive design, compared to the other two solutions I mentioned above:

• If all the code for all the different user interface designs are included in a single file, that becomes a lot of stuff to transmit to the user. This overhead wouldn't matter much to desktop users with broadband connections, but to mobile users on slow connections that are charged by the megabyte there are benefits to only having to download the exact code needed for their device.
• The ideal design for mobile users involves splitting off secondary content and placing it on a secondary page, thus making the primary page shorter. Because desktop users have a bigger screen, you can present more content in the primary view. For sure, responsive design could hide the secondary content if it senses that it's working with a mobile device, and it could also make sure that the link to the secondary page is only shown to mobile users. But this does seem somewhat convoluted.