Going Mobile

Here is a piece of advice for both developers and designers that come from the words of Wilfred Hansen: Know Thy User. Many developers make the critical mistake of thinking they are developing for the user, when in fact they are developing for themselves. Does your target customer share your technical or cultural background? What about their demographics – Are they the same age and gender? Do they share your goals and motivations? If you cannot answer these basic questions, you may very well be creating the wrong product for your customer!

Now, with the understanding that our user is not us, let’s focus on one specific user: the Mobile User. This person isn't sitting at a desk with a big monitor, mouse and keyboard. Rather, they are on the move: trying to enter data and read results quickly so they make their flight, find the restaurant, or answer that email without (literally) missing a step. This means your app can't just be a miniature version of what is on the desktop. Instead, you have to design for, and test with, people in cars, in airports, or walking around downtown; innovation is the key here, not miniaturization.

We also need to recognize that we’re not just talking about smartphones. Mobile devices come in almost as many flavors as its users. A GPS device is certainly mobile, as is an MP3 player. E-book readers, like the Kindle or the Nook, qualify as well, since the user could be reading on the subway as easily as on the couch. Portable gaming systems, satellite radio receivers and even in-vehicle infotainment systems could all be considered devices for mobile users.

So, what does that mean in practice? For starters, the mobile user won’t be spending a lot of time focusing on the devices, or even the task they are trying to accomplish. They will be highly interruptible, focusing on things like not walking into walls or out into traffic. So with this in mind, we have to let them get in, get what they need and get back out again quickly.

For example, in most pieces of software, you need to provide some information (like what you want to search for) before you get what you want. That's easy on the desktop when you have a keyboard, but it can be tricky when you’re on the move, even with the best virtual key entry. Whenever you can, provide selectable entry options to your user. For instance, don't make them type in a date when they could, instead, select from a calendar or date “spinner” widget. It may sometimes be more work for the developer, however, the person using your app will thank you for it!

I’m speaking from experience on that last one. A while ago, I was on a flight into Chicago that was delayed and it was obvious that I’d be missing my connection. When we landed, I went on to Delta’s web site to check when the next fight might be. They required me to enter a date. Ok, you clever developer, you could just default to today and entering a date isn't too bad, right? It is when you are only presented with a text box. Are we looking for “May 24”, or “5/24”, or “5/24/2012”, or…..?? I recall going through at least 3 attempts, a few cryptic error messages and much profanity before I got the info I needed, all while dragging my luggage up the jet way and trying not to get trampled by the other stressed out passengers.

I’m pleased to say that, when I had reason to check the same site six months later, Delta had upgraded to a nice combo box with the current date as the default. So, thanks for that, Delta. Now, about my baggage on that last flight I was on….