|
The VUI Post
|
| Blog by Dr. Ahmed Bouzid and Dr. Weiye Ma on Voice User Interface (VUI) Design in the context of Interactive Voice Response (IVR) Telephony |
|
|
|
|
 |
Voice User Interface and Text Linguistics Blog
|
This Blog mainly deals with topics related to Voice User Interface Design, Discourse Analysis and Text Linguistics. Please send me a quick note, if you would like to see specific topics put up for discussion.
|
|
A Python bed time reading for linguists |
 |
 |
 |
|
Monday, 12 July 2010 08:07 |
|
Doing things with words - revisited
For the daily dosis of natural language processing, those familiar with the command line use text tools like grep, sed and awk, which are unix tools that are also available for windows based systems. For a bit more sopisticated tasks, we normally batch-process those tasks through the usage of pipes or quick (and sometimes) dirty shell or Perl scripts. Personally, I have used to be a big perl fan and I stil aml.
However, for one of my current tasks I had to do some rather complex text processing jobs involving the creation, management and analysis of big text corpora. After having played around with using the standard text modules of perl, by accident, I came across a language processing toolset of another scripting language, Python.
This toolset is called "Natural Language Toolkit" (one might have guessed) and it comes with a free electronic version of the O'Reilly book "Natural Language Processing with Python --- Analyzing Text with the Natural Language Toolkit". The book aims to be a (short track) general introduction to Pyhton as well as a training resource for those trying to come up to speed with language processing. It is fair to say, it succeeds in doing both! It comes with several example corporas, so you can start playing around with the analysis methods provided by the various objects almost straight away.
The book was a quick and excellent read, it took me three days (without the lunchbreaks) to go through the sections and to do the bulk of the offered excersises. After having done so, I started applying the knowledge working with my own data. My estimate is that having used the toolkit saved me approximately half the time of the scoped project work!
|
|
|
Thursday, 08 April 2010 12:58 |
|
VUI Design Principles - Article 5
A lot of sales pitches for voice enabled self service systems emphasize on the high "containment rate" of a proposed speech solution. There are a couple of other terms in the market for one and the same thing, hower, keeping callers within the automated system to fullfill their tasks is what it is all about. Generally, that is not a bad thing, as it is what self service automation is all about, right? A well designed self service can be more efficient than a lengthy interaction with a human agent.
However, sometimes service providers tend to forget about the difference there is between a liberately conducted self service interaction and one a caller is forced into - without an easy way out! A self service application has to be self explanatory, deliver on the service-promise it has made and conduct the interactions with as few headaches for the customer as possible. Saying that, this will not always succeed! In that case you have to make the right trade off between your contact centers getting hammered and frustrated customers getting stuck in automation. Cost driven decision quite often lead to solutions forcing customers into ongoing automation even when - looking at the actual caller journeys! - it should be obvious that the caller will definitely not succesfully finish the interaction with the automated system. The "Ten Guidelines for Designing a Successful Voice User Interface" point out the huge negative impact of blocking the exit for callers trying to get through to an agent after a failed self service interaction.
- Callers who only want to speak to a CSR can be very determined and will do whatever it takes to reach a live CSR, including saying nothing (playing possum) in hope of an eventual transfer, coughing repeatedly, calling multiple times, or pressing zero repeatedly. These actions mean extra call minutes for both the system and the caller.
- When they finally do reach a CSR, callers will spend extra time complaining about their automated experience. This is expensive time for both caller and CSR and callers will be less likely to want to use the automated system in the future.
(Larson et al 2005)
Ideally, the call center agents would work in an enviroment in which they can transfer callers back into automation for specific tasks - after having given some instructions on how to do actually do it! (And yes, ideally the service would be selfexplanatory.)
It is also a good idea to provide the caller with some context dependent information while playing the actual transfer prompt:
Okay, I'll put you through to someone straight away. By the way, you can always get your account information online at ...
Another design suggestion could be to include a plain yes-no-style question in the transfer sequence in order to get at least the most basic information about the caller's intend:
OK, you want to speak with someone at our call center. Just so I can direct your call, are you calling about X?
This X as the most probable option could be based on intelligent caller preselection logic or something similar.
|
|
|
Tuesday, 02 March 2010 09:32 |
|
VUI Design Principles - Article 4
The exact wording of the headline’s principle is taken from the well known book "Voice User Interface Design" by Michael Cohen and others (book website). Cohen discusses three general design strategies to minimize the caller's cognitive load during an interaction with a speech system (or within any other communication situations!):
- Minimize conceptual complexity
- Keep the memory load low
- Be aware of the caller's limited attention span
The first aspect deals with establishing call-flow-constancy, for example, through consistent naming of the global commands. Furthermore, setting the context and the caller's expectations right is crucial to minimize conceptual complexity. One example for setting the context was given in the last posting on this Blog when discussing how to avoid "broken promises" during a call flow:
Setting up your microwave is done in three easy steps.
Another means of setting the context is to work with a global metaphor throughout the whole or parts of the application. For example, a shopping application could be designed by using a virtual shopping cart. The prompts then have to mimic the typical things people do with a real life shopping cart: putting things in and out of the cart, reading the information printed on the products package, going to the checkout etc. Using appropriate sounds (earcons) can also support the caller's perception of the VUI as being a virtual shopping cart. The effect will be callers only saying (doing) things the normally do within a shopping cart context – hence, the amount of “out of grammar utterances” can be minimised.
Second thing to be aware of when trying to minimize the cognitive load is the human memory load itself. This is particularly important when designing menus for directed dialogue interactions. Ideally, menus should not hold more than three items. Four items can already be too much for a caller’s comprehension, especially when using longer item descriptions.
Another important strategy in order to keeping the memory load low is to provide so called "just in time instructions" as Michael Cohen puts it. Rather than routing the caller through lengthy tutorials at the start of an interaction it is mostly more efficient to give him only the most obvious commands for the given dialogue step “just in time” he might needs them.
Applying the above described strategies then almost automatically leads towards an application design that appreciates the caller's limited attention span.
In general, the first step in facilitating attention is to understand the caller's goals and priorities. Then you can design strategies to make only the pertinent information available. At the same time, the system can accommodate the caller's needs to attend to information and events outside the purview of the application.
(Cohen, M. et al.: Voice User Interface Design - Chapter 9.3)
|
|
|
|
|
|
|
Page 1 of 3 |
|
|
|
|
|
