As consumers of mobile software and devices, we rarely think of how inherently useable these items are, how seamlessly and effortlessly they have become a part of our everyday lives. That is, until we encounter the dark side of usability, those times when we recall words we had forgotten and new trajectories for the devices we used to love. At these times it becomes apparent why more attention needs to be paid to mobile usability during design and development.

The goal of most mobile development is to produce an engaging, efficient, and usable solution to a previously cumbersome and labor-intensive process. One issue affecting usability in a mobile solution is that we create new challenges simply by trying to solve the problem. For example, when users are provided with a mobile interface, they are no longer constrained by a fixed environment. They can travel while interacting with the device, they can be more frequently interrupted, lose connectivity, or—while encountering bad usability—drop the device. This changes the way the original problem is approached and the tools needed to reach a resolution, creating a loop where our changes introduce new usability issues that change the workflow.

Our designs must continually change scope and purpose in order to retain the usability of a given solution, without losing sight of its original intent. The typical reason why most conversions to a mobile platform or transitions to mobile software solutions fail is inadequate attention to usability. The characteristics being tested are in constant flux, and usability tests—if they are done at all—are not dynamic enough to handle the rapidly evolving issues in a mobile solution. This presents the developers of mobile applications with a significant problem. If we are successful in developing a useful solution, we change the way the user approaches their task. We must therefore be able to design and implement usability tests for processes that change due to our efforts. To be successful, the development team must understand not only what makes current systems usable as a starting point, but they must be able to determine the requirements of a system that is no longer tied to a specific context.

A small step in the right direction would be to include usability tests throughout the development cycle; it would be a giant leap forward if such testing could provide continuous feedback throughout multiple iterations of the program.

How to make a mobile device useless

The user should always know where they are, what they’ve already done, what they can do next, and how to undo mistakes. These are common sense rules in usability, and are even more pronounced when dealing with an interface on a mobile device. While it is true that a user interface should encourage a user to explore by exposing him or her to previously unused features and potentially new uses for their device, the interface should not be a test of the user’s intelligence or puzzle solving abilities. It should be clear that requiring users to overcome a steep learning curve in order to use hardware or software layered with forgettable or confusing symbolism, and separate routes to similar functions, is a poor design for a mobile interface. Some design teams not only ignore these rules, but appear to use the physical limitations of the hardware as an excuse to test even more un-usable designs in the software.

Due to the limited screen sizes of mobile devices, the trend has been to associate symbols or numbers with menu items and navigation or configuration options. Interfaces making excessive use of these “pictograms” are relatively easy to design and typically look very clean and even stylish—fooling the user into thinking they must be very usable. Unfortunately, this is not always the case.

As an example, consider the user interface on the Samsung x495 (not a Windows Mobile smartphone, but indicative of the interface style). Selecting any of the available options causes one of the following confusing page titles to be displayed: