The conversation often starts like this…
“Mobile users won’t want to do that, they’re ‘on the go’ and will be in a hurry or want a quick distraction.”
This is true, except when it’s not.
Study after study reveals people use their mobile at home, while watching TV. People also use mobile devices for hours while waiting on trains and at airports. For each user who is in a hurry there will be another who stares intently at their device for 20-30 minute stints. If that devices happens to be a tablet, they may use it for even longer periods. And while many users will simply be consuming content, others will be shopping, banking, or performing other very specific tasks.
“Ok, but some mobile users will still be in a hurry. Shouldn’t we cater to them? Make things extra simple for them?”
Agreed. Mobile users will curse up and down if they can’t do that really useful, common, important thing really quickly. Any chance you have to focus and trim copy, streamline interactions, or minimise data input should be considered.
But why exactly are we only fixing things for mobile users?
Desktop users may have a bit more time on their hands, but does it mean we should waste it with happy talk, redundant data entry, or poorly optimised interactions? If I had a penny for the number of times I’ve had to input Edinburgh, choose United Kingdom or specify today’s date in a menu I’d be rich by now. Modern browsers make it much simpler to implement intelligent defaults. Why should it only be a mobile thing?
“Ok. But we still can’t implement all features for small screens. Some things are just too complicated.”
Agreed. Completing a life insurance form on a mobile (or BTW on the desktop and on paper) is really complicated. That doesn’t mean people won’t try it, and even that is besides the point.
Let’s look at it a bit differently…
First off, what is the traffic for this feature on the desktop?
If traffic (and completion rates) are high, shouldn’t you seriously consider including it in the mobile roadmap, even if it will be hard to implement (or may involve additional testing and come in a later phase)?
And if the traffic is low, why is that? Maybe the feature isn’t actually needed, or maybe it’s too hard to use (or find) on the desktop as well.
Kayak recently tweaked their desktop site to bring it in line with the simplicity of their mobile offering. One of the steps they took was to remove rarely used features, to better focus on optimising higher traffic ones.
Also worth considering that people who suffer through impossibly complex (or broken) features on a tiny screen are either really desperate, or are power users who simply want to get stuff done…wherever they happen to be at the time. As acquisition typically costs much more than retention, are these really the people you want to disappoint?
And don’t forget, some of these devices are also phones 
Sometimes a well placed voice call or SMS can save the day. Yell.com (and several travel sites) recently implemented a “Call Us” feature for those times when despite their best efforts, what a user wants to do is just too complicated (or maybe not yet supported). If a user is about to bail, the ‘best UX’ is one that provides them with a handy one-click life raft.
PS – You will lose points however for displaying a “Call Us” button on a device that can’t actually place a call. If you provide a life raft, be sure it actually floats.
Pingback: More Mobile Context Mythbusting - ISITE Labs
Fantastic post!
Regarding your last P.S., I’m curious what you think about how to handle devices/browsers that don’t support phone calls: http://bradfrostweb.com/blog/mobile/a-tel-tale-sign/
My broad-sweeping assumption for users who are on non-phone devices is that they understand the fact that they can’t make a call from their particular device, and that it makes more sense to leave it in than to not include it (or have to include an entire device library just to swap out a link). “Call Us” as I see it is just as generic as “Click Here” so I definitely recommend exposing the number to call so that non-phone users can still have access.
I’d love to hear your thoughts on this little aside, but as for the rest of it it’s absolutely spot on.
Because we (or our clients) always use a device database anyhow, we’ve typically handled this with a combination of feature detection and good copy. The last time we implemented this type of thing, there was a call to action included on every page with a 1-2 line intro (why call?/how we can help) and an exposed phone number. If the device could make a call, the phone number was adapted server-side using the ‘tel’ URI scheme (and if I recall, a slightly different style applied).
If you don’t have access to device detection, I think what you suggested is likely best. Expose the phone number in the copy and (silently) beg forgiveness about the not so useful hyperlink.
What you definitely don’t want is an opaque “call me” button with no visible phone number available at all. That leaves no room at all for error.
Most of our clients use a CWCMS that outputs static HTML. No web application server, so no device or feature detection. Interesting discipline: and of course it doesn’t prevent them (or us) from making false assumptions about mobile use cases. Some time I’d appreciate your thoughts on detectionless mobile web.
Thanks Simon, i’d appreciate some thoughts from me about this as well
I must admit i’m having a hard time now thinking of the web without some sort of detection (not necessarily of device but at the very least of features). I guess the very simplest of these is the media query. It won’t solve all your problems but will at the very least enable you to tweak layout and legibility/design at different sizes….and works perfectly well on static sites.
Going beyond that (adapting/swapping images, adapting markup within layout components and eventually content itself) certainly require more heavy lifting. None of this functionality is currently built into CMSs but it can still work with static pages (and the fact that you have a CMS likely means you have a necessary server-side layer available…even if at the moment it’s only being used to manage CMS templating etc.)
But I completely agree, large institutional collections of content will the trickiest to deal with. By comparison, e-commerce, tech startups and such have it quite easy. They often have large amounts of distinct, highly structured content (e.g. tweets, book titles, photo metadata) and (most likely) a well designed API.
I completely agree. Mobile does not need to mean less content/features. It just means different constraints and capabilities than what we are used to on desktops, just like tablets and smart TVs offer different constraints/capabilities. To me, good design will allow you to appeal to your users “on the go” while still allowing you provide content/features for users on mobile/tablet devices who may not actually be “on the go”. Jason Rhodes has great article on this topic. http://jasonthings.com/2011/03/626/
Thanks for the link. That really is a nice article. Hadn’t run into it yet
Pingback: Mobile Users Don’t Do That | MarketNet Blog
Pingback: Serving the digital omnivores | Mobile in DC
Designers now need to look at their client’s work as platform agnostic until there is a complete understanding of the user behavior for a particular site or the content they are designing for. What a designer or web developer needs to do is think like a content strategist and put themselves in the user’s seat first. Great post!
Pingback: » Is There Ever A Justification For Responsive Text? Pablo Gallego Falcón
Pingback: Let’s Make Sure This Doesn’t Become A Thing: Responsive Text « adjustafresh – user experience design | digital marketing strategy
Pingback: Brett Jankord – HRWD – Hybrid Responsive Web Design
Pingback: Coming Soon to the Small Screen (revisited) « Word Power
Pingback: Usabilla UX Tweet Scoop – Week 12 of 2012 - The Usabilla Blog
Pingback: Coming Soon to the Small Screen (revisited) | How to Write Everything
Pingback: Responsive Web Design Is More Then A Mobile-Optimization Strategey « Cantina
Pingback: Responsive Web Design Is More Than A Mobile-Optimization Strategy « Cantina