Prompt Design

It’s a case of stating the obvious - but prompts are important. Very important even. Not so much because people appreciate a VUI with good prompts, it’s just they hate the ones with bad prompts. You can tell this by the way they mimic what idiosyncrasies a particular application’s prompts may have.

Prompt design goes hand in hand with grammar design (at least if you’re building an ASR application!).

Choose your words carefully!

Remember you're choosing your words not just for the caller, but also for the recogniser. So you need a compromise between words that allow the caller to understand what's being offered and words that the recogniser can easily distinguish between. Sometimes, the words that the recogniser gets mixed up may not be words that a human might have problems with - so always check the recognition after an application has been deployed and make sure that there aren't too many false accepts.

We once thought we'd be smart and write some curses into our global grammar. If we thought the caller was being rude then we admonished them and chucked them out. Unfortunately asking for assistance regularly got recognised as cursing, and the callers got thrown out :-( That was the end of that idea!

A general rule of thumb is that short words cause more recogniser errors than longer words.

Be consistent

Don't talk about help in one prompt and then assistance in the next. Decide early on, what your key phrases are going to be and stick to them. It may happen that you have to change everything if the initial usability trials indicate that the callers associate different words with the command that you have in mind. So it could be that you want the caller to say "Main Menu" to get back to the top level of the application. However, in the usability tests it turns out that the callers prefer to say "Start Over" or something similar. It could also be that callers associate your phrase with something else - sometimes even as the designer it can be hard to get into the average caller's mental model of the application. So, it's best to try and get these tests out of the way as soon as possible. That way you can fix your vocabulary early on - and you don't end up having to re-record half your prompts.

DTMF Prompts

This is kind of obvious, but you'll be amazed how many applications don't do it - put the 'press one', etc. at the END of the prompt!

So don't write the following:

Press one, if you would like to deposit some money in your current account.

Press two, if you would like to deposit some money in your deposit account.

Press three, if you would like to withdraw some money from your current account.

Press four, if you would like to withdraw some money from your deposit account.

Press five, if you have a query about your accounts.

Tell the caller what the option is first - give them a split second to decide if it's what they want - and then tell them what key to press in order to select it. Otherwise they have a memory problem - they have to remember what the current active key is and then they have to decide if the option is what they want. So it's better to write:

If you would like to deposit some money in your current account, please press one.

To deposit some money in your deposit account, please press two.

If you would like to withdraw some money from your current account, please press three.

If you would like to withdraw some money from your deposit account, please press four.

If you have a query about your accounts, please press five.

If you have any comments, ideas, issues, etc. about this topic why not try the voice-push forums