Friday, May 16, 2008

Design anti-patterns: Extraordinary rendition

Some years ago I was asked to review and suggest improvements to a touchtone call routing IVR for a financial institution. One of the submenus had seven options, and it wasn't clear to me how callers would be able to select the correct product option. One of the business analysts told me, "Don't worry about redesigning that part. All of those calls go to the same unit. The options are just for reporting purposes." The management was just using the menu to gather statistics on what customers were calling about. Since that time I've seen a number of applications that require callers to select a number of options for the sole purpose of generating automated reports on usage.

Instrumenting your applications is usually a pretty good idea. It allows you to identify and fine tune hotspots and learn all sorts of things about how the application is being used. Requiring customers to wade through several menus of inscrutable options before they reach a representative causes several problems, however. One, it generates bad data, because callers can't be counted on to successfully navigate a poorly designed application. Or even a well designed one, for that matter. There are better ways to collect the data businesses are looking for. Two, it annoys the hell out of people to answer a bunch of questions before being allowed to talk to someone and receive service.

If fact, if the IVR is too disagreeable then people will simply answer prompts randomly or press zero (if it's available). It's like torture: if the experience is painful enough people will say anything in order to make the pain stop. Businesses shouldn't torture their customers (or allow its IVRs to torture customers by proxy). And they shouldn't build multi-layered IVRs full of inscrutable prompts in the misguided idea that reports are more important than happy customers.

No comments: