Saturday, September 6, 2008

Design anti-patterns: context-free design

I recently presented some training to a group of IT folks who were trying to improve the performance of an existing IVR. Completion rate was only 40%, not high enough to justify the expense of the system. The task seemed easy enough. The caller enters some identifying information, then data about amount of miles driven, fuel used, perhaps a vehicle number, all numeric.

I had started by preaching the importance of writing good scenarios - descriptions of customer behavior in the context of their environment and their tasks. Then I presented some general guidelines for designing prompts. This is harder than it appears because there are often contextual factors that make a suggested prompt worthless in a given case, so every guideline must be wrapped with disclaimers.

Back to the problem with the existing IVR. After cautiously making a few suggestions about prompting I asked the participants to back up and describe the scenario in detail. Then it became clear. The caller was a cashier standing at a check out counter talking to a driver. The driver supplied the information, who sometimes had to pull out a notebook to get the information. Two obvious problems. One, if the system is converted to speech then you'll get a lot of sidetalk recognition errors, where the caller isn't speaking directly to the IVR, but to someone else. Two, speech timeout values are by default pretty short. If you don't have the information the IVR is asking for close at hand, the IVR goes into its Silence error routines.

These are nice design issues and potentially solvable, but not unless you understand the context and the likely outcomes of the caller's behavior. In this case, not having information at hand and needing to talk to someone during the call. An expert can look pretty silly and helpless if he's offering recommendations without understanding the scenario.


Fitech said...

Good work. This is a great example of the need to research the context of the actual use. It would be good to conduct contextual inquiry, and go to where the users are actually doing their work.

I'll be graduating soon with a degree in Human Factors in Information Design. My interests and previous work experience have led me to focus on IVR systems. Do you think that this is wise? or am I focusing on too narrow a niche, with limited job opportunities. I'm in the Boston area.

Thanks in advance for the advice. I enjoy reading your blog.

Carl Turner said...

The job opportunities for IVR designer are limited by the small number of available jobs. A lot of places won't consider hiring without seeing some experience. Since you're in Boston, Nuance is nearby but they look for experience.

You might think about taking a human factors job with a company that does significant IVR development, and then move internally if you get an opportunity. You'll be getting experience while trying to land the VUI designer or research position. Good luck.

Fitech said...

Thanks for the advice. I actually just completed a project with Nuance over the summer, which was a great experience. I designed and implemented a few relatively simple IVR systems in my days as a system administrator at my previous job. I'm going to continue to watch out for speech interface jobs, and more broadly, languange based interfaces, while keeping my options open. How is the North Carolina area for this type of work? My wife and I are considering moving.

Carl Turner said...

The Research Triangle area has a lot of technical companies and lots of opportunity, so it's a good place to live and work. I don't know about any that specialize in speech interfaces, though. Check Monster or Dice for the local positions.

Crimsonet Voice Recognition Experts said...

This post really shows how context changes the way an IVR system should be designed. Companies need to keep this in mind when developing IVR systems. IVR system usability is crucial to keeping clients satisfied, and the only way to do this is to design and test for things like context and patterns in the calls. It’s important to keep in mind that the client’s expectations and mental model of the system are part of the context as well. See for more on the importance of VUI testing.