Two lessons for mobile designers

If I had only two lessons to impart to people building mobile user experiences, it would be these:

1. A smartphone is not a small desktop (or laptop).

   You’d think that’d be fairly obvious, and yet a lot of mobile applications with desktop equivalents seem to be designed just as stripped down versions of the desktop experiences.

   Take email as an ubiquitous example. Most mobile email clients are designed as smaller versions of desktop email clients: inboxes, folders, read/unread flags, etc. But if you look at how people actually handle mobile email, the usage patterns are different. Mobile email users focus on triaging mail by (a) identifying what’s new (which isn’t necessarily the same as what’s unread), (b) figuring out what they can delete right away, (c) determining what they have to handle immediately because it’s time critical, and (d) deferring everything else until they reach a desktop or laptop. And despite that different mobile focus, mobile email clients are designed assuming you’re reading and responding to messages just like on the desktop.

   This point ties back to my previous point about feature selection: don’t assume your mobile users will interact in the same ways as your desktop users. Figure out what they’re really going to do and support that, even if the feature set and UI need to be different.

2. Users’ activities will span devices.

   Continuing that email example. When users defer handling messages on their mobile devices, they want to resume handling them on their desktops and laptops. Why is re-marking messages as unread the way most users end up handling that functionality?

   Another example: users who employ their mobile phones to do price comparisons will nearly always defer making a purchase from an online supplier until they reach a desktop or laptop (why is an interesting question; I suspect it relates both to the perceived time of completing the transaction on a smartphone and to a concern about missing an important detail on the smaller screen). Despite that common pattern, the closest I’ve seen to a mobile application that helps make that transition to the desktop is Amazon’s iPhone app that lets you save items to your wishlist. And even then it’s up to the user to remember that they added the item and to complete the purchase.

So there you have it, my two lessons everyone should know. Don’t design your mobile apps assuming they should be smaller versions of your desktop apps, and don’t assume the mobile app will work in isolation. Go forth and build great stuff.