On the desktop and the web, people like to talk about how many clicks it takes to get a given task accomplished. More clicks is usually considered less desirable, so high-frequency actions are pushed more front-and-center, hierarchies are flattened when possible, and task flows are simplified. All of that can make sense, but I’ve heard some try to transfer that idea directly to mobile, talking about an interface in terms of the number of taps required to accomplish an action. On well-designed smartphones, that’s not the most useful way to see things.
If you actually watch someone play with an iPhone app, they just kind of tap around everything. There’s less friction at play in a single tap - your fingers are more natural to manipulate than a mouse [no matter how good we are at mousing these days], there’s less screen area to concern yourself with, and as long as the app isn’t horribly implemented, the transitions between states are relatively painless, even enjoyable in the way they bounce and fade. The cost to see what happens if you tap on that table cell or that blue text is very low, and the back button’s pretty easily available. If you take five taps and 30 seconds to input something but it flows seamlessly and makes intuitive sense, that may be far better than taking say three taps and 25 seconds to accomplish a task in a less intuitive, less beautiful way.
This compared to the traditional web where users have to navigate the mouse to a certain area and then click, wait while whatever it is loads, move up to the back arrow and click, wait for reloading, etc. But even on the web, services like Google+ manage to make potentially weighty, click-heavy actions [sorting your friends] painless through playful animations, rapid response times, and a fairly clear UI [for more on how the number of clicks rule never really applied, even on the web, check out: http://www.uie.com/articles/three_click_rule/].
The idea of number of clicks is really just a quick proxy for how cumbersome, how weighty, how “slow” an interface comes across as to the user. But in a mobile touchscreen context, where taps carry less cost, we need to think less about simple metrics and more holistically about why we wanted to reduce those clicks in the first place. How we might make an app really feel fast, regardless of what actual speed its tasks clock in at. How we can make interfaces that are truly lightweight, that carry as little mental burden as possible.
A few possibilities come to mind, though there are obviously more:
1) Make sure your interactions are intuitable, applying a few extra menu layers if necessary to better organize options. If you’ve flattened your hierarchies to the point that every option is on one page the user can’t figure out where to make that single tap for a given task, the weight of the frustration will outweigh any minor speed gains.
2) Make sure individual actions are as smooth as possible - don’t make people wait as much as possible, and when people have to wait, let them know why they have to wait, how long they have to wait, and even better let them do something else in the mean time.
3) Reduce start-stop, if people have to wait try to batch it into one clearly marked longer chunk rather than many shorter stalls [unless they can be short enough to be genuinely ignored].
4) Good visual design. If an interface is unattractive, it feels clunky instantly. People have to fight a slight negative reaction just to use it. Beyond that, a good designer can communicate both the right mood to support using the app as well as provide subtle visual cues of how to get things done without weighty tutorials or instructional sentences.
5) Reduce feature bloat. The more features an app has, the more an app can do, the more your brain has to sort through complexity to figure out exactly what you want to do, where to go to do it, and inhibit distractions from the other options. Excess features can create a mental pressure to use them. People like to know clearly what problem an app solves, and they want that app to have only as many features as necessary to support accomplishing that.
Now of course, you still want to make sure that the important tasks aren’t buried, and that there aren’t twelve layers of hierarchy to navigate back and forth to get anything done. But when it comes down to it, the ultimate goal is not to worry about number of clicks, not to reduce task time by five seconds, but to make interfaces that feel responsive, keep users in control, and, whether they’re explicitly faster or not, are ultimately more gratifying.