Elliott Drucker
President,
Drucker Associates
COPYRIGHT © 2005-2009 Drucker-Associates
ALL RIGHTS RESERVED
The copyright in this document belongs to
Drucker Associates. (‘the Owner’). No copyrighted material may be used, sold,
transferred, or reproduced in whole or in part in any manner or form or in or
on any media to any person, except as authorized by the Owner’s Agreement, the
United States Copyright Act, or the prior written consent of the Owner.
All brand names and product names mentioned or
referred to throughout this publication are fully recognized as the Trademarks
or Registered Trademarks of their respective holders.
A great deal of time and money is being invested these days in
development of mobile data applications, and even more is being spent on
deployment of the high speed wireless data networks on which they will
operate. At the same time, there is a
lot of talk in the industry and financial press about “mobile data user
experience” (MUE), a term intended to encompass the general satisfaction – or
perhaps lack of frustration – that a typical user will experience in the
operation of a given data application or feature.
Until the much more recent introduction of data services, the idea of
mobile user experience for wireless voice telephony has largely been predicated
on quality of service and completeness of coverage, two factors which might not
be particularly simple to measure but at least are easy to define. For a variety of reasons the user experience
situation is very different – and far more complex – in the delivery of
wireless data applications and features.
Yet MUE will be critical to the ultimate success of commercial wireless
data services for both individual applications and data transport
networks. It therefore seems useful to
identify characteristics for mobile data applications that will predictably
result in a “good” MUE or at the very least avoid a bad one. Most critically,
these characteristics need to take into account the limitations of data
bandwidth and user interface that are inherent in the mobile data environment. I’m not suggesting a quantitative scoring
system by which applications could be ranked against one another on some “MUE
index” but rather a set of subjective benchmarks that can serve as general
guidelines for developers of mobile data products. To that end I have developed what I call “The Seven Rules of
Mobile Data User Experience”. Here they
are.
Rule 1: Consistent User Interface
There is currently no shortage of mobile
data applications available to consumers, and more are being added every
day. Users are most likely to embrace
those applications which collectively meet there needs and interests. This suggests that one means to success in
the development of a new data application is to identify and exploit some
as-yet unmet need. That’s true, but
hardly useful. It’s kind of like saying
that one means to wealth is going about picking up hundred dollar bills that
people have dropped. Novelty of content
is pretty rare; a more reliable route to success is making the content as easy
as possible for the user to access. And
since most users will rely on a number of different data applications, ease of
use is largely dependent upon commonality of user interface. That means that
navigation, menu access and formats, image layout, data entry, command
selection and execution, and data display should all work pretty much the same
from one data application to the next.
Consistency of user interface is a critical
component of user comfort and familiarity, which in turn strongly impact the
user learning curve and user acceptance.
Of course, making the user interface natural and intuitive is also very
helpful, but I believe that consistency is even more important.
Rule 2: Simplified Data Entry
Many in the industry would like to pretend
that a wireless handset with Web access can deliver the same data services, in
the same way, as a personal computer connected to the Internet. This is patent nonsense. Even top-of-the-line smartphones like
Apple’s iPhone and Motorola’s Droid have far more rudimentary user interfaces
than those of even the most basic computers.
With simpler handset devices data entry can be agonizing. As I write this I am sitting at my desk
plunking away on a full-sized QWERTY keyboard and watching words I type appear
on a 21 inch flat panel display. Could
I do the same chore using the keyboard and display of my basic cellphone? I might start, but long before I finished
the first page I would probably get so frustrated that I would do something to
render the cellphone permanently out of service.
It is one thing for the wireless industry
to tell consumers that they can
access Internet data services from their cellphones just like they do from
their PCs, but it is quite another to design mobile data applications as if
this were actually true. In fact, mobile
data applications should be designed to limit and simplify user data entry as
much as possible. This is important
even for smartphone users, and absolutely critical for users of more common
basic handsets.
Optimally, a wireless data application
should accommodate single-hand operation and should require a minimum of manual
“typing” for data entry. There are a
number of means by which this can be accomplished, including pick lists, scroll
lists, and radio button sequencing. And
of course the application should be able to “remember” commonly needed data
such as the user’s name and address.
Rule 3: Efficient Network Utilization
Another myth being perpetrated in the
wireless industry is that 3G data networks have abundant bandwidth for all
users. In fact, a radio channel which
can indeed provide impressive total data throughput is a resource which is
shared by all users using that channel at a given time. The more users, and the more throughput each
user demands, the lower the data rate available to each user. This trend can be offset to a point by
deploying additional 3G data channels in each base station and/or by deploying
more 3G base stations, but such “solutions” are costly. Furthermore, actual user data rates will be
negatively impacted by degraded radio channel quality. Emerging 4G networks will provide greater
bandwidths and correspondingly higher peak throughput rates, but the increased
capacity will likely be more than offset by growth in user demand.
Because of these and other factors, at any
given time and place a wireless data network may reliably provide to a given user only a fraction of the throughput
that it can deliver under pristine conditions.
Of course, providing a good overall MUE means doing so reliably, which
suggests that a mobile data application should use the data transport network
efficiently. Perceived delays in data
transfer, which will very quickly frustrate a user, can be minimized by
reducing to the extent possible the amount and frequency of data that needs to
be transmitted to and from the mobile device.
Rule 4: Off-line Functionality
One thing about mobile data users: they
tend to move around. And sometimes they
find themselves in locations (airplanes, subway systems, etc.) that even the
most ubiquitous wireless data networks cannot cover. However, lack of wireless data access does not mean that a data
application cannot provide useful functionality. In some cases a user may be able to anticipate the loss of
coverage and pre-load data for later use by an application program resident in
his or her mobile device.
Alternatively, a user temporarily outside of network coverage could set
up the application, including required data entry, so that required information
transfer can be executed immediately upon reacquiring service. In appropriate applications an optimal MUE
would require such “off-line” functionality, and in addition would require that
its operation, particularly in transitioning in and out of coverage, be as
intuitive as possible.
There is one additional requirement for
off-line functionality in order to make it usable aboard commercial
airliners. In order to comply with FAA
regulations, the user must be able to disable the transceiver of the host
mobile device while using the resident data application program.
Rule 5: Automated Data Sharing
Rule 1 suggests that wireless data
applications should have a consistent “look and feel”. Now Rule 5 suggests that they should also be
eager to share data among themselves. As
discussed in Rule 2, data entry on typical mobile devices can be a disagreeable
chore and should be minimized as much as possible. One way to do this is to automatically transfer data from one
application to another. This is pretty
obvious for “boilerplate” information such as user name and address, but there
are other instances where automated data sharing can be usefully employed. Example:
an application that provides diving directions from point A to point B
could port data to an application that shows locations of gas stations along
specified routes.
Rule 6: Dynamic Personalization
With the possible exception of identical
twins, no two people are alike.
Differences in tastes, needs, and technical sophistication extend to
selection and use of wireless data applications, of course, and successful
applications will allow for appropriate levels of user customization. But in order to deliver an optimal MUE
mobile data applications need to take personalization a step or two further. At the very least, the application should
automatically store such things as personal data, favorite websites, locations
of interest for weather reports, and stock ticker symbols on the basis of what
the user has done with the application in the past. Ideally, user interests and preferences could be predicted by
extrapolation from such stored information so that the information or option
most likely desired by the user could be the first one offered.
Such “dynamic personalization” of a mobile
data application can be very seductive when it seems to “magically” anticipate
what the user wants to do. However,
that seduction will quickly turn to frustration if anticipated preferences
cannot be not easily and intuitively overridden by the user when the program
guesses wrong.
Rule 7: Mobile Device Independence
Unlike the realm of personal computers, the
world of wireless data user devices encompasses a myriad of different
capabilities, user interfaces, and operating systems. To gain the broadest possible market opportunity, a mobile data
application must therefore operate over a wide range of environments. That alone is a difficult enough task for a
developer, but unfortunately it’s not sufficient to assure a good MUE. Because users change their mobile devices
with some regularity, a successful application will also need to operate in
those different devices in much the same manner.
Obviously, it will usually be impractical
if not impossible to design a given application so that it works identically in
mobile devices with vastly different user interfaces. I suspect that most users understand and accept this
reality. But a designer can seek to
minimize operational differences, and even more importantly can try to make
such differences as intuitive as possible.
One final note, as long as we are talking
about how users frequently change their mobile devices. It should be obvious that an optimal MUE
requires the ability to easily transfer personalized data applications from one
device to another.
Well, there you have it, my “7 Rules of Mobile Data User Experience”. Completely arbitrary and subjective, of
course, but I believe that they collectively define the important
characteristics of successful mobile data applications.
Of course, it’s easy for me to come up with these rules. The real challenge is to develop mobile
data application that obey them.
Fortunately, some very robust mobile application platforms are now
available that should go a long way toward helping developers in their quest
for a better MUE.
For more information on getting help
in understanding the realities of the mobile data services environment and how
they impact MUE, contact
Drucker Associates.