A recent Wall Street Journal 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 journey
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.
Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent over a decade providing strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at firstname.lastname@example.org, and you can follow his blog at www.itbswatch.com. All opinions are his and may not represent those of his employer.