On Nielsen and Mobile Design
There has been hype about how to design a mobile web site/application. Instead of promptly writing my opinion, which would have been pretty guts-driven, I preferred to wait for things to settle down a bit (in the media and in my mind) and then write down, calmly, what I think. First a bit of history:
- Nielsen writes a year ago: “I am a screen-size bigot: bigger screens deliver hugely higher user productivity. Anyone who’s experienced a 30-inch monitor cringes at the idea of doing a major project on anything smaller”
- Nielsen writes a month ago: “cut features, to eliminate things that are not core to the mobile use case; cut content, to reduce word count and defer secondary information to secondary pages;”
- Josh Clark replies: “Nielsen is confusing device context with user intent. All that we can really know about mobile users is that they’re on a small screen, and we can’t divine user intent from that. Just because I’m on a small screen doesn’t mean I’m interested in less content or want to do less.”
Nielsen also stated “Build a separate mobile-optimized site” and this hijacked the first batch of discussions on the technical side, with designers siding either with responsive or separated design. On this, my point is clear:
the user does not care whether you build a responsive web site or separate versions, optimized for mobile and desktop.
One of the few ways a user might notice the difference is when they resize the browser window on a desktop. In the case they will see the content to adapt. This might create a good impression right away, but how many will do that? And, of those who do, how many will care? A discussion about this is perfect for projects managers, focused on saving time/money/lines of code/stress. The final user will not see the difference. A bad UX can be experienced only when you are sharing a url. If a friends sends me a m.youtube.com url and I open that on a 30” monitor I’d like to see the desktop version of that. I guess this is only solvable by acting server-side.
On cutting content
This is something the user will notice depending on the context. Conceptually this can be framed also an “ethical issue”. If you cut some content on the mobile the risk is to divide in classes your user base. Exaggerated paraphrase: “you are on a mobile so you are not eligible to view this information”. Designers should ask themselves: is this a problem? Will the user ever find out the cut made by designers? If yes, you have the ethical issue above and be ready to read some post/tweet blaming the company. If not, you are a smart designer, who has correctly identified user’s needs on the mobile and has saved time/money/code/stress yet meeting user’s expectation. Unfortunately this is something that heavily depends on the nature of the service you are providing and the budget available.
For example, whenever I go to US I fill out my Travel Authorization form at the airport using my phone. Can you imagine what happens if they cut off some section or if their design prevents me to finish the task? (BTW I always carry a laptop so I can turn on personal hotspot and my ass is safe :) The ESTA website is not mobile optimized but you can manage to accomplish the task anyway. The only thing missing is just a mobile friendly version to make the task more pleasant. First conclusion: if you don’t optimize for mobile, people will probably complain just about the experience. Much worse is the case when you are blocking the experience on mobile by requiring the usage of a desktop. This is what I have experienced recently:
- I have switched to a new mobile carrier
- I have downloaded their iPhone app to browse data consumption
- I needed an account
- To create an account their redirected me to the website
- The website is not mobile optimized (not a problem in theory, as in ESTA)
- Their layout is scrambled and prevents me to tap and open the registration form!
This is a totally sucky experience that blocks me in my current task.
Obviously the safest solution is to build everything in a way that it is browsable from every platform. Unfortunately this is the most expensive solution to build, which also requires good care in separating content from presentation form. Most of the times, the 50% of users complaints can be addressed during the design phase by putting yourself in the user’s shoes.
In some cases is it likely that the user will browse your content almost always from one platform. So why bothering building the rest? Take Instagram as an extreme example. Their user base is (ehm … was?) totally mobile driven. They have a simple desktop version and I bet they didn’t invest much time on that.
Nielsen and Clark have kept the discussion at an abstract level. One claims you should have button to switch to the desktop version, the other considers that button as a defeat, a way for the designer to say: “I surrender, there is no way to show the same content of the desktop on a mobile device”.
In principle I support Clarks’ opinion and my gut feeling is: “Dear designer, you should work your ass off and make it possible”. All these disquisitions do not take into account two key aspects of a real-world scenario: time and money. Have you ever met a client that told you: “Do me this, you have no limit on money and time”? I don’t. My bet is that the switch-to-desktop button is the outcome of endless discussions between the management and the design team. It’s the compromise to keep both not unhappy. Achieving the best experience on all platforms requires lot of time, money, careful planning and a good syncretism between the designer and the client.
There are no golden rules, although some gurus like Nielsen tend to state them, maybe due to their attitude and the position they represent in a community. The following are the principle that I usually live by when I design a product.
- the technical way you implement solutions does not matter to the final user
- you need a way to find out the needs of mobile users on your service/product and address them. If you don’t wanna bother finding out, it is better to have all the functionalities on both desktop and mobile. If you can’t afford it you are forced to choose. Maybe be start with a platform, see how it goes, reiterate/add according to the feedback.
- for each platform that you can’t address have a nice fallback solution, like “hey we don’t have a mobile version of the site but you can download our native apps here” or “hey we don’t have an native Android version but the site is optimized for mobile browsing”
- the discussion about the switch-to-desktop button, and other decisions like which platform to address, are sterile if you don’t consider budget and time.
- never, ever, break the flow of UX by forcing the user to switch platform/device, you can’t assume they have one at hand
- if you are starting some service/product right now, plan to store content in an presentation-independent way; it will be easier to address new platforms in the future or pivots along the path.
If you are interested in this topics you should follow me on twitter.