It’s far too easy to find enterprise applications with profoundly bad user experiences. And it’s spreading. It’s almost like the marketing folks aren’t involved in the user experience of applications, or perhaps the executives of these companies are not aware of the implications of bad usability. Or perhaps the usabilty ROI (return on investment) message hasn’t been heard.
From a strategic perspective, an easier to use product fosters use, reduces training time, increases compliance, reduces support costs, and improves ability to serve customers. If you can’t increase your enterprise system sales by increasing price or volume with these benefits, then you can only compete on price. Have fun.
From a tactical perspective, the types of bad design in these systems arise from a combination of “database think,” “historical behavior think,” and “forms think.” And more, of course.
Database think: User screens (web pages, for example) are arranged largely by table correlation. Each table is on a different screen, with reduced ability to move between screens. Typical experience: a customer service representative answers a call, and takes some information from the customer. At some point the customer asks for some information, and the representative says, “Hold on, I can’t get that data from this screen.” Representatives are trained to go in a certain order, regardless of what is best for the end customer. Frustrations rise. Relationships are damaged.
Historical behavior think: It’s done this way because that’s how it is done. While most North American mobile phones allow 10-digit dialing, most landline phones require the 1 to be dialed. If you dial 10 digits, you get “Dial a 1 before the ten-digit number.”
So the system knows what I did wrong, but can’t fix it. I can see switchboards of 40+ years ago having such limitations, but not now. So why still have these errors? Because that’s how it’s been done.
Forms think: The digital design looks like a paper form design. Think IRS here. Each form item is individually labeled, even if the labels are unnecessary. Labels are typically obscure. My favorite little item? Date: January 18, 2008. As a display. You know, I did deduce that the date was indeed a date. Without thinking hard.
These problems are manifold, existing everywhere.
Have you ever had to fill out an expense report online at a large company? What was your experience? Do you know what each of those fields means? Have you had to double-enter information? In my talk next week at Mobile Web USA, I’ll be looking at a mobile version of this problem, and different design options. I’ll post slides later.
What about your company’s internal PBX (phone system)? What do all those buttons do? Or how about the doctor’s office? Yesterday I had a form onto the back of which the receptionist had copied my driver’s license and insurance card. I was then required to fill out the front. There was not a single piece of information that I had to write that was not found on the reverse of the form, and more legible than my writing.
It’s ironic that small companies, in many ways, have better systems. Open source software such as ActiveCollab typically has the problems outlined above, but Basecamp is a great system. Similarly SugarCRM versus Salesforce.com: Salesforce is noticeably better on a wide array of measures. Except price. What’s the difference? Well, as I write this, Steven is accumulating work hours for a client using Stickies on his desktop. He’ll add the data to ActiveCollab later, when he has to. He may dodge the task entirely. It’s too much hassle. And if a high level conscientious employee does this, what sort of shortcuts will other employees do?
The bad design gets embedded into your process as well. Well meaning employees insist that the way the software forces you to do things is the only proper way to do them. I made such decisions as a teenager working at a tourist trap.
I had a friend once who was working at Kansas Department of Revenue, in the exceptions department. She was to look at each return that the computer said had generated an exception, apply a human eye to it, and use the system to generate a letter to the taxpayer about the problem (or do a small number of other things). There were maybe 15 people in the department doing this, and certain codes were much hated. My friend refined the process. Rather than processing each exception individually, she noticed that the form letters for a given code were 95% the same. So she used the system to generate a template letter for a specific exception, and copied it into a word processor. She then took all of the day’s exceptions with that specific code, and made modifications within the word processor to avoid the delays in using the main system.
She was disciplined for breaking the process. The required process took literally 40% more time.
As more and more intranet applications go mobile, we’re seeing more and more of this bad design in just the places where it is the most difficult to deal with. And the most costly.