Creating the user interface of a speech IVR can be thought of as designing a conversation, where you have total control over one interlocutor (the application) and are trying to influence the other (the human). As such, the terminology used must be relevant to the topic at hand and comprehensible to users of all levels of expertise, all the while reflecting the system persona and company brand. While this may sound like a difficult balance to maintain, good results will follow if the conversational nature of the interaction is kept in mind at all times. Strive for clarity and consistency, avoid industry-specific jargon, use terminology which is familiar to users, and, most importantly, set the users up for a successful interaction by directing them in familiar, comfortable terms.

Use clear terminology
Clarity is subjective and depends on the user's frame of reference, level of expertise, and even emotional affect. Think about clarity of terminology both when providing instructions or explanations to users and when directing them how they should respond to the system (directed dialogue).

Terminology should be relevant to the subject at hand, and it must be intelligible and accessible to the user. As such, terminology used may need to be tailored to a particular audience. It is sometimes necessary to design one-size-fits-all applications, where the user population represents a wide variety of demographics and levels of familiarity or expertise with the subject at hand. Usability testing is crucial to ensure that what is clear to the designers and subject matter experts will also be clear to someone using the application for the first time, as well as not seeming ponderous to someone who is very familiar with the application and/or subject matter at hand. To those close to the design, including designers and business analysts/subject matter experts, a lack of objectivity can make it a challenge to keep terminology clear. Usability testing early and often can help. (See section on Usability Testing).

As an example, a banking application had a menu option to “check balances.” Usability uncovered a lack of clarity in this phrase as it sounded like it applied only to checking accounts, not other types. It was confusing for somebody who wanted to get the balance on their savings account.

Consistency in terminology is also important. If a function occurs in more than one place in an application, use the same terminology to avoid confusing users. For example, “When you’re ready, say ‘go on’” and “when you’re ready, say ‘continue’” are both clear and easy to understand. However if “go on” is used at one point in the application, it is a good idea to use it elsewhere.

Be careful with the idea of consistency, however, as consistency for its own sake can give an application a monotonous feel, and in some extreme circumstances, even confuse the user. If the same terminology and sentence structure are used in consecutive dialogue states, users may feel like they’re “stuck in a loop”, even if they are progressing through the application. Think about why you’re being consistent. If it is to maintain a familiar and reassuring experience for users so they are confident that they know what to say, you’re on the right track. If the idea is to be consistent for consistency’s sake, you may be creating an application that sounds repetitive and may even be confusing to users. As the designer, you may occasionally have to defend your choice not to be consistent, as variety in word choice and sentence structure can benefit users, giving them the sense that they are progressing through the application.

At all times, strive to convey topics - which may be quite obscure - in terms that all users can understand. One obvious way to do this is to use terminology that is familiar to users. Sometimes the official terms and names for things that are completely obvious and understandable to those in the business mean nothing to users.

An example is in a child support payment system that needs to include information on emancipation. Civil War history and the Emancipation Proclamation aside, lots of people are not familiar with the term even though everyone involved in the project knew exactly what it meant. The decision was made to use “stopping support” as the menu option.

Occasionally, you must choose between a precise, industry-specific term and a commonly used term. When the right choice seems to be that specific term, consider offering more detail in the reprompts. Strive for balance between terminology which is familiar and understandable to a novice but not frustrating for an expert. See the next section on jargon.

Consider the proper use of esoteric terminology (jargon). In order to make the application accessible to everyone, jargon should be kept to a minimum. However, it can occasionally make good sense to use jargon or industry-specific terminology. If an esoteric term is more precise and/or is the term that an expert would expect, consider using the term in conjunction with its commonly used counterpart. Pair the jargon with an explanation or description the first time it’s used in a flow, e.g., “529, or education savings account.” In addition to dealing with jargon, it is important to consider where and when acronyms are used. Even common acronyms may need to be defined, at least the first time they're used in a dialogue flow.

An example can be found with a company that had a new program to set up automatic payments. They called it “Paymatics” and insisted that the term be used in the menu. Luckily after usability testing proved the jargon was completely foreign and confusing to customers, the term was changed. For branding purposes, it is perfectly acceptable to use the term later, as in the confirmation, something like, “Thanks for signing up for our new Paymatics program,” but it does not belong on a menu.

Consider the register (level of formality) expected in the industry. This may be very different depending on the industry and target demographic. Consider, for example, the way you would expect to be addressed by a representative of your bank versus a pay-as-you-go mobile phone company. Think about the level of expertise expected of the user in a given industry.

This is tied to the above in that the persona should reflect the formality or casualness of the type of industry (finance, travel, tech support) that the application supports. Keep in mind the mood of the persona (helpful, knowledgeable, trustworthy, etc). The persona also reflects the brand of the business, and often branded terminology must be used because of marketing directives, alignment with the website, etc. Sometimes the branded term is difficult to recognize over the phone, or may mean something else. In extreme cases, the English-branded term is required even in a non-English segment of an IVR. In these instances, be sure to accompany the term with a native-language explanation. For more information on word choice and personas in multilingual applications, see Multilingual Applications.

It is critical to set users up for success. Ambiguous or unclear prompts that violate the above principles leave the user unsure of what to do next, and their response may be to hang up or zero out.