A tale of two user experiences

The perception of software quality will be forged in the first 90 seconds. Don’t let your users experience what I had to go through.

Comments

Everybody knows that installation and setup are the neglected backwaters of software engineering. If you’re thinking to yourself, “but in the cloud, there’s nothing to install, no DLL hell, no traumatic transitions, so no big deal,” you’d be wrong.

Even in the cloud, there’s system configuration, data conversion and migration, security settings, compatibility issues, plug-ins, JavaScript incompatibilities, browser versions and add-ons. Consequently, “onboarding” applies to nearly any sophisticated cloud app, whether it comes from a vendor or from your own shop. If first impressions rule (and with users, they do), then the perception of software quality will be forged in the first 90 seconds of users’ first encounter with your installation and configuration mess. Whoops.

The best of times

Let’s look at the ne plus ultra of user experiences: upgrading to a new iPhone at an Apple store. I just went through this last week, for the first time in five years. Although the products and software are of undoubted quality, what’s remarkable is the fit and finish of the process the user goes through. The selection cycle (“which features and version do I want?”) and the actual purchase steps are streamlined, taking into account how busy I am (and how short my attention span really is).

Then there’s the initial product experience, which is the box. Apple’s process dictates that I feel it and appreciate it before I open it. Really. But the fact that they want me to go through this tactile experience is an indication of how seriously they take the first impressions of their product, and the implied quality of every part of the product experience. In subsequent steps, they want me to touch the product and use the UI in low-risk interactions that provide the most non-threatening training experience. Even though migrating the old phone’s data and configuration had built-in complexity and potential for blind alleys (due to OS compatibility issues), it didn’t feel like it.

The Apple Genius was there to provide just the right amount of guidance and reassurance. No documentation was necessary, so I didn’t notice that it wasn’t available. The actual onboarding and migration process took several hours (due to over-the-air refresh cycles), but most of it was after I’d left the store. As it all occurred in the background, I didn’t even notice some of the process steps were happening, and the end of the cycle didn’t even have to announce itself. I was up and running throughout.

The worst of times

I also went through an install and upgrade cycle last week with a cloud service that runs as an adjunct to Salesforce.com (SFDC) systems. I do this kind of install/upgrade cycle every couple of months. These two-vendor setup situations have an inherent disadvantage because the add-on product can’t control the overall environment, the starting point for an install or the user’s process steps. But as is too often the case, the add-on product decided that lack of control was their excuse for putting all their install uncertainties squarely into the user’s lap.

The sales person for the plug-in used marketing jargon, and the words didn’t match the install documentation. So I couldn’t even tell if I was installing the right thing. The install was more or less automated, but there were no videos or overall roadmaps to show me if I was on the right track. Instead, the vendor threw six separate documents at me, each fragmentary and just enough out of date to lead me into — and leave me in — blind alleys. This is quite a feat, considering I’m a ten-year veteran of SFDC and have even installed this particular plug-in before.

Four email exchanges later, it became obvious that “something we don’t understand” is getting in the way. I granted the vendor system admin privileges so they could inspect the system and try to resolve in a timely manner. For some reason, they decided to never actually look at my system. Eventually, they decided it was time to schedule a couple of video conferences, where they identify and rectify the problem — seven business days later. The culprit was three steps they forgot to put in the documentation because they’d never actually gone through the whole process with this version of their product.

There are two big problems here:

1. The vendor has spent too much time with half-baked documentation and actions, driving up the support cost of their product.

2. The user (me) already thinks the product stinks, and I haven’t even started using it yet.

Not a support kvetch

The lesson here isn’t about sloppy support. It’s about sketchy decisions that caused the need for support in the first place. It’s about the waste of time, money and reputation. Don’t let it happen with the next project in your shop.

You don’t have to be a political genius to figure out that first impressions and perceptions are critical to a project’s long-term success. Don’t forget the lessons of the classic book, “Quality is Free” — because in this case, a quality user experience would have cost the vendor less than nothing.

If you apply the right kind of user experience (UX) engineering to your project (particularly the onboarding and transition process), users may not be so picky about feature deficiencies that are hidden from view during the onboarding process. You won’t have to invest so much in customer support or bug “war rooms” if you intercepted the problems prior to deployment. It is simply not possible to make the onboarding experience too easy or seamless.