Mobile is just the beginning

Mobile users don’t do that

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. (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.

25 Responses to “Mobile users don’t do that”

  1. Brad Frost

    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:

    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.

    • steph

      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.

  2. Simon Blackley

    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.

    • steph

      Thanks Simon, i’d appreciate some thoughts from me about this as well :-P 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.

  3. Brett Jankord

    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.

  4. Chris Cullmann

    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!

  5. 在当前移动飞速发展的过渡且不稳定状态下,如何做好Mobile Web工作? | Web App Trend

    [...] 由于现在可以通过便携设备随时随地上网,用户在上网的时候,不必坐在一个有着宽带连接的电脑前了。相反,研究显示,一种新的模式正在出现,每天在web上,会出现间歇性的、短期的突然爆发的网络流量。这样网络流量突然增加的时期是变化的,并且和时间、用户的意愿、用户使用的屏幕设备相关(在更长时间的浏览中,平板电脑用户居多)。这些行为和传统的 “mobile user”  是不一样的——传统的“mobile user”不会试图在他们的设备上完成复杂的任务。 [...]

  6. 在当前移动飞速发展的过渡且不稳定状态下,如何做好Mobile Web工作? | 手机网站开发

    [...] 由于现在可以通过便携设备随时随地上网,用户在上网的时候,不必坐在一个有着宽带连接的电脑前了。相反,研究显示,一种新的模式正在出现,每天在web上,会出现间歇性的、短期的突然爆发的网络流量。这样网络流量突然增加的时期是变化的,并且和时间、用户的意愿、用户使用的屏幕设备相关(在更长时间的浏览中,平板电脑用户居多)。这些行为和传统的 “mobile user”  是不一样的——传统的“mobile user”不会试图在他们的设备上完成复杂的任务。 [...]


Leave a Reply

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS