A recent Wall Street
article highlighted one of the risks of large-scale mobile
deployment, one that I’ve been guilty of underestimating myself. The article’s
author attempted to buy a treadmill at mass-market US retailer Sears. The sales
rep was sporting an iPad, and in what seemed to be a comedy of errors, it took
several requests for customer information, and failed tethering and payment
attempts, before the author was finally able to purchase the treadmill. In a
“can this get any worse” twist, the sales rep ran out to apologize, mentioning
his age and lack of training and familiarity with the tablet.

The unfamiliar tablet

Despite witnessing everyone from my 20-month-old son to
octogenarians on the airplane seemingly able to understand the rudiments of
operating a tablet, even familiarity with the devices does not necessarily
equate to familiarity with your applications or process. A mobile interface
ripe with cute controls and snappy colors doesn’t excuse you from good
interface and process design and equally good training.

Start with the

One mistake that’s often made in designing user interfaces—one
that’s particularly deadly in a customer-facing environment such as retail—is
letting requirements and functionality dictate how an application or process is
designed. In a conference room that’s literally and figuratively hundreds of
miles from the front lines where your application will actually be used, it
might seem like a great idea to build multi-page forms that demand reams of
customer information, or spend hours discussing that cool feature that’s more
hindrance than help in the field.

In these situations, it’s often better to consider a
“journey,” whereby you take into account what your customer will do and how to
best serve them at each point in the interaction. In more complex cases, you
might even come up with representative “pretend” customers, complete with
demographic information, personality quirks (i.e. “demanding and not willing to
take no for an answer”), and even a picture. The exercise comes alive when you
debate whether “Bob” will really give you his phone number for a third time, or
“Mary” will want to know about discounts and availability before she tells you
her postal code.

Spend the time to consider how some predictable
environmental changes might impact your customer and their journey. What
happens if that fancy new tablet runs out of batteries in the middle of the
transaction, or internet connectivity at the store drops, and your marvelous
cloud application is completely inaccessible?

Journeys take you to
functionality and training

Your journeys should identify everything from technical
features and interface tweaks to high-level service level requirements. Your
journeys will also force you to consider remedial action or customer quirks
that you might not have considered. It may seem contrived initially, but after
a day or two don’t be surprised when you hear yourself passionately state that
“‘Bob’ would never wait 20 seconds for us to walk to pick up a receipt!”

With this knowledge in hand, you can create training
programs that are centered around a typical customer experience, rather than
the usual IT training that focuses on which buttons to press and which data to
enter. When systems are built in the context of a complete customer
“experience” it’s easier to train users, since you can identify how each screen
and process fits into that overall experience.

Put on your lab coat

With a well-considered journey, a carefully developed
application, and a scenario-based training program, it’s worth taking your
application into the lab, especially if it will drive a critical component of
your product or its ancillary services. With retail, the tablet represents a
fundamental change in a critical, core process: the checkout experience. In
this case, it’s worth creating a mockup of a store or using a real retail
location and putting a handful of people fresh from training into the lab,
testing the process and technology with mystery shoppers. If you’re an
enterprise rolling out a new tablet application, this may sound extreme, but a
limited field trial can accomplish the same thing. Testing is certainly nothing
new, but is usually performed by people on the team who have spent hundreds of
hours conceptualizing or building the system. Throwing a few freshly-trained
greenhorns “into the fire” in a controlled environment serves as both a final
checkpoint and a test of the
effectiveness of your training program.

Putting an existing process or application on a mobile
device might seem like an easy and riskless process, but when it fundamentally
alters a critical process in your business, far more than a new technology is
involved. Considering the process from the perspective of a customer’s journey,
creating scenario-based training and testing the whole thing in the lab will
help ensure your success.