Mobile UX and the need for speed

We’ve been smartphone use for over a year now, and one of the lessons that I think anyone building a mobile application needs to keep in mind is speed. Yes, one of the great things about smartphones is that people carry them almost everywhere, providing pervasive access to information. But as a consequence, people employ their smartphones in situations where the real world constrains their use: you can’t hold up the line at the grocery store when it’s your turn to checkout, the airline will not delay closing the boarding door while you finish that email, etc. In addition, the limited input and output capabilities of smartphones mean that users are likely to defer anything too I/O intensive until they reach a desktop or laptop.

In studying smartphone users, we’ve discovered that most interactions are less than a minute (60 seconds) long. Checking the weather, checking out new email, looking at Facebook status updates, reading recent tweets, snapping a quick pictures: all short (and typically intermittent, but that’s different post). If you break that time down, it includes physically accessing the device (typically a few seconds if the device is a pocket or purse), initializing the application (a few seconds for a native app, more in the 8-15 second range for a web app), and then completing the particular task (doing the actual “work”).

Thinking about speed for your mobile applications has (least) two consequences. One, you want to focus on the core functionality provided by your application, because people are unlikely to spend the time to navigate to the more esoteric information or functionality provided by your application. Remember, if it takes too long to do on the smartphone users are likely to just wait and do it on their laptop or desktop.

Two, you want to think about the initialization and work times typical for your application (there’s not much you can do for access time without providing wrist mounts for your users). On the initialization side, native apps tend to be significantly faster to initialize (and use) than web apps. HTML5’s support for offline application and data caching is making headway on reducing the time overhead, but native apps are still faster. On the work side, structure the user experience so that users can quickly get to information or functionality they’re likely to want without making them wade through intermediate levels. If completing a task is likely to take longer than 60 seconds, provide users with a way to easily suspend their work and resume it later on (even on other devices; that’s also another post).

Unfortunately, the need for speed sometimes has consequences you can’t directly control. We’ve seen that roughly 80-85% of the smartphone population we’re studying would rather not use their smartphones for IBM work if it requires installing the IBM security policy. To these users, suffering the 10 second hit to type in a password just isn’t worth it: that’s 15% of their 60 second interaction time right there. And since most things our users do with their phones aren’t business related, they’re taking that time hit on actions (checking the weather, taking a picture) that aren’t even work related. So until smartphones get smarter (ahem) about separating personal and business information and functionality, the need for speed may be a general barrier to the use of smartphones for business. But in the meantime, make sure your application is part of the solution, not part of the problem. Support speed.