Elliott Drucker
President,
Drucker Associates
COPYRIGHT © 2005-2006 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 applications and the platforms
they run on. 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 their 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. 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 19 inch flat panel display. Could I do the same chore using the keyboard
and display of my 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 users of devices
that have a more-or-less complete (but tiny) keyboard, and it is absolutely
critical for users of the much more common basic cellphone handset.
Optimally, a wireless data application should accommodate single-hand
operation and should require an absolute 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 will 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 and by
increasing popularity of bandwidth-hog applications like on-demand streaming
video.
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 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 mass market
acceptance, 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 (and some use multiple devices in
their daily lives), 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 applications 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 information on getting help in understanding the realities
of the mobile data services environment and how they impact MUE, contact Drucker Associates.