Macadamian Blog

Creating a Usable Mobile App

The best place to start a discussion on creating a usable mobile app is to make sure we’re all on the same page on the definition of ‘usable’.

What’s the difference between usable and useful?
Useful – A useful app makes your life, or a task in your life, easier. For example, most mobile banking apps are useful – they let you check your bank balance on the go, or transfer money from account to account. Very useful when you’re on your way to the airport and realize you may not have the funds to cover a big check you just wrote.

Usable – A usable app is one that doesn’t make you want to smash your smartphone into bite-sized pieces after using it. You can be both useful, and not usable or usable and not useful, but ultimately, an app that is both useful and usable will be a hit.

Expectations in Mobile Apps
A study by eMarketer showed 73% of users expect a mobile app developed by a familiar brand will be easier to use than the original product. 69% say their vision of the brand would be negatively affected if the app is not useful or easy to use.

Designing for mobile already has its challenges – smaller form factors, understanding multi-touch-UI, and knowing the user’s context of use. Now add the fact your customer is even less tolerant of bad usability on mobile than the desktop or web!

Feature bloat is your enemy
The worst thing you can do when creating your mobile app is to try to stuff all the features and functions of your desktop or web app into it. Creating a usable app is not just about design but also about matching the needs of your users in the context of being mobile. Unlike when they’re at their desktop, mobile users are, well, mobile. They’re walking down the street, sitting in a restaurant, or riding the bus. They’re distractible, available, and highly contextual. They may need to complete the task with one thumb, and with only intermittent glances. If your mobile app is an extension to your current desktop or web app, think very carefully about the subset of functions to include on the mobile version. It's not enough just to think about their goals or tasks. It's critical you understand the context in which they are going to be using it. Where will they be, and what else will they be doing at the same time?

Test with real users, or else.
The only way to consistently create a usable app is to test it with real-live users.

Let’s blow a myth out of the water– hire a good user experience designer, and they’ll create a usable app, right? The answer is a resounding maybe. The odd time, I have seen good designers nail a design on the first shot. More often than not, I’ve seen great designers make an incorrect assumption about how a user will behave. While the assumption seemed perfectly logical, it ended up having a critical impact on the usability of the design.

Here’s an example. Recently, we were asked to run some usability tests on a tablet application for making VoIP calls. It did a lot of cool things, and looked beautiful. It was designed by a very smart and talented group of designers and the product strategy was well thought-through. However, usability testing uncovered that users often mistook the hang-up button for the mute button, inadvertently ending their call. This is a critical, often used feature that would have created a lot of frustration and ill-will with the customer base in a highly-competitive segment. When we say test with users, we mean real users. While an argument can be made to test with internal “surrogate” users from time to time, this should never replace putting your app in the hands of representative users. The problem with relying on internal users to often (or the same users), is they quickly get used to a product’s quirks and find workarounds. No excuses Too many product groups skip usability testing thinking that it’s too time consuming or too expensive. Neither has to be true, especially if you test early in the lifecycle when it’s cheaper to fix issues.

Here’s an example. Recently, we were asked to run some usability tests on a tablet application for making VoIP calls. It did a lot of cool things, and looked beautiful. It was designed by a very smart and talented group of designers and the product strategy was well thought-through. However, usability testing uncovered that users often mistook the hang-up button for the mute button, inadvertently ending their call. This is a critical, often used feature that would have created a lot of frustration and ill-will with the customer base in a highly-competitive segment.

When we say test with users, we mean real users. While an argument can be made to test with internal “surrogate” users from time to time, this should never replace putting your app in the hands of representative users. The problem with relying on internal users to often (or the same users), is they quickly get used to a product’s quirks and find workarounds.

No excuses
Too many product groups skip usability testing thinking that it’s too time consuming or too expensive. Neither has to be true, especially if you test early in the lifecycle when it’s cheaper to fix issues.