We'd been increasingly unhappy with our old bank -- it's the one with the stage-coach logo -- for a number of reasons and, after we moved here, its nearest branch office was a desk in a grocery store, some 28 miles away. That left us to choose between a local bank and an Internet-based one.

We chose Bank of Internet, USA, because -- as Eureka Club members -- it offered us free checking, free online bill-pay services, no ATM charges, reimbursement of up to ten bucks a month in foreign ATM fees and money-market-rate interest on our checking account, all with no minimum balance. And B of I also supplied us with postage-paid deposit envelopes, which was important, since my wife's employer doesn't offer direct deposit and I'm a freelancer.

The other day, I noticed we were low on deposit envelopes, so I called B of I to order more. That turned out to be an exercise in frustration and, by the time I got a customer service rep on the line, I was downright exasperated.

Since my last call, the bank had radically changed its voice menu tree -- and not in a good way. It took several tries to discover that the option to speak to a human was now buried three levels deep. And even there it was the last choice, offered only after a three-second pause following the instructions on how to repeat the menu.

It's clear to me that hiding that option was a deliberate choice on the bank's part. With the exceedingly generous perks it offers us customers, it has to cut costs somewhere -- and forcing its patrons to use automated services, rather than those provided by actual human beings appears to be B of I's current solution.

The thing is, cell-phone application designers make similarly user-unfriendly interface decisions all the time. And the central problem is that, unlike B of I, they often don't do so on purpose.

In fact, more often than not, they're trying to be helpful.

Nor is the issue exclusive to WAP -- although that sorry excuse for a standard has plenty of problems of its own. Instead, I think it's more a product of ivory tower planning and a general inattention to real-world user acceptance testing.

And the problem is ubiquitous.

She Said, She Said

The first day of DEMOmobile 2001 included a fifteen-minute panel discussion on "The Future of Handsets and UI Design". The participants -- Jakob Nielsen of the Nielsen-Norman Group, Richard Ling, President and CEO of AlterEgo, David Friend, CEO of Sonexis Corporation, Doug Brackbill, Chairman of Visto and Helen Dwight, Marketing Director of Informatica Corp. -- touched only lightly on the handset question. They all seemed to agree that the conflict between providing a decent-sized display with a usable input mechanism and keeping the finished product's bulk down to pocket size presents an ongoing challenge that manufacturers have not yet successfully addressed.

They also dismissed the trend towards feature bloat in handset design and generally concurred that users don't seem to value bells and whistles nearly as much as solid basic functionality, quality workmanship, small size, light weight and extended battery life.

What interested me was that they had nothing good to say about handset user interfaces, regardless of whether they were based on WAP-style nested menus or on interactive voice applications. Their consensus seemed to be that, as user-unfriendly as current handsets' physical input often is, their applications' UIs are infinitely worse, almost without exception.

David Friend played a recording of a particularly horrible example of bad interactive voice application design. Apparently, the program was intended to help a caller locate a suitable restaurant in Manhattan, based on considerations of price, type of cuisine and general location. In a businesslike, telephone-operator's voice, it started out something like this:

"State the type of cuisine served by the restaurant which you are attempting to locate. Some examples would be Thai, Italian, Indian or Chinese."

"Mexican."

"You chose Mexican. If this choice is correct, say 'yes' or press the pound key now. If you did not intend to choose Mexican cuisine, say 'no' or press the star key now."

And it went on and on and ON like that.

I sat there cringing as the awful thing relentlessly marched its hapless caller through a seemingly-endless list of questions and mandatory confirmations. By my count, it took fifteen individual steps from the initial query to get at last to the application's ultimate recommendation -- a moderately-priced Mexican place on the Upper West Side -- and the whole process was so excruciating that I just wanted to bite somebody by the time it was over.

As Friend quickly pointed out, the single saddest thing about the whole disaster was that the application actually conformed quite closely to what are generally accepted to be best UI design practices. After all, it provided examples, required confirmation at each decision point and provided detailed explanations of each option.

But, as Larry Harris, Chairman of EasyAsk, would demonstrate the following afternoon, there're much more user-friendly ways of providing the exact same kind of service.

Things We Said Today

Truth to tell, when Harris attempted to give me a one-on-one demonstration of the application on the showroom floor, Thursday afternoon, his Windows server headed off to The Land of the Neverending Hourglass. (I put that down to Lerner & Hauspie's Dragon NaturallySpeaking -- which EasyAsk uses as speech-to-text translation middleware -- because my personal experience has been that NaturallySpeaking has a resource stack leak which eventually crashes Windows machines, and Harris told me his server had been up for over two hours.)

The following afternoon, however, using a freshly-booted computer, his demo before the assembled congregation went flawlessly.

"Computer," he commanded, "find me a moderately-priced Southwestern-style restaurant in Phoenix, Arizona."

In no more than a couple of seconds, EasyAsk responded with the name and address of its recommendation, asking only, "Would you like driving directions from the airport?"

Still mindful of Friend's excruciating example of the previous day, those of us in the audience responded with a wave of applause. I think we all understood just what a feat of programming legerdemain we'd been privileged to witness.

EasyAsk's key feature is natural language input. Whether that input takes the form of speech-to-text translation or direct text input -- such as via a browser form -- the important thing is that it permits users to conduct free-form queries of the specialized databases which it then searches, rather than imposing on them a rigidly-controlled and unnatural query form.

That's a non-trivial piece of technological prestidigitation. The rest of EasyAsk's magic comes down to ordinary database schema and data population chores -- although concocting appropriate synonym lists for the language parser admittedly requires something approaching art.

And the schema lay out and data population tasks are basically identical in both applications -- it's really only the user interface that makes the difference between EasyAsk's "Gee whiz!" and the "Aw geez!" of Friend's atrocious exemplar.

Bring it on Home

As the UI mavens pointed out in their Thursday discussion, a big part of the problem is that a lot of the industry's programmers are industriously churning out code the purpose of which is to impress the engineer at the next bench. So the back end of their product is often pretty nifty, while the front end -- the part that users interact with -- winds up as an afterthought.

And folks, that's just plain wrong.

Too often, coders view end users with undisguised disdain. It's regarded as acceptable to sneer "users are lusers" -- especially amongst Linux geeks -- as if they were a plague, without which we'd all be better off.

They're not. They are, in point of fact, the only reason most of you folks have jobs. Your friends and associates may all be hackers or engineers, but the vast majority of the people who buy the products you develop are not. And, without those folks, there'd be no venture capital to fund your company and you might well wind up wearing a paper hat and asking people whether they'd like fries with that.

They're barely less important than the air you breathe. Just like that air, they're absolutely vital to your survival -- as you'll swiftly discover, should they ever disappear on you.

And you owe the interface which you present them the same degree of effort and artistry that you put into the plumbing behind it. It's not something that you can afford to slap together two days before your product ships -- because, regardless of how snazzy and feature-rich your brainchild is on the back end, if it's difficult or frustrating for them to use, your customers will abandon it in favor of some other solution that better accomodates them.

B of I got that message, loud and clear. And its officers -- understanding full well that, without their customers, their business is S.O.L. -- have hastened to correct the mistakes they permitted in their voice menu's user interface.

But you can go them one better -- by doing it right the first time.
 

Resources:

Bank of Internet, USA's Web site

DEMOmobile's Web site

About Jakob Neilsen

About Richard Ling

About David Friend

About Doug Brackbill

Lerner & Hauspie's NaturallySpeaking product line

EasyAsk's Web site

Paul Smith's excellent dW article on UI design myths

Larry Loeb's dW condensation of Apple guru Bruce Tognazzi's principles for UI design