Voice User Interface Design: A Working Guide

In 2018 Nielsen Norman Group put Alexa, Google Assistant and Siri in front of 17 participants and gave them ordinary tasks. Short factual questions went fine. Almost everything else broke. Multi-clause requests got misparsed, a pause mid-sentence was taken as the end of the request, answers ran long, and nobody could go back and re-hear the part they missed.

Recognition has improved a great deal since then, and language models have made interpretation far more forgiving. The list is still worth reading, because only one item on it was a recognition problem. The others came from speech itself, and good voice user interface design starts from those.

Why speech is hard to design for

A screen holds information still while you look at it. You can read a list twice or compare two prices side by side. Speech arrives one word at a time, at the speaker's pace, and a finished sentence exists only in the listener's working memory.

Graphical interfaces lean on recognition: the options are visible, so the user picks one (NN/g on recognition vs recall). A voice interface forces recall. The user has to keep track of what the options were and what the system is waiting for, while the system keeps talking.

There is also no idle state that teaches anything. A new app with a toolbar shows its capabilities before you touch it. A smart speaker on a counter shows a light. Discoverability, which a screen gets partly for free, has to be built into the conversation.

Choosing which tasks go to voice

Speech is a good channel when the user's hands or eyes are occupied, as in cooking or driving. It also suits short requests where the user already knows the target ("set a timer for twelve minutes", "call Mum"), questions whose answer is a single fact, and people for whom typing is slow or impossible because of motor or vision impairments, or because the device has no keyboard.

It works badly for comparison and browsing. Reading out eight flight options is slow to produce and exhausting to hear, since the listener has lost the first by the fourth. For tasks built around choosing between things, plan for a screen to carry the choice.

Write the dialogue before you design the flow

Teams coming from graphical products usually start with a flowchart. For voice, start with a script: several sample dialogues between user and system, written the way people speak, covering the common path and a few likely deviations.

Then read them aloud with a colleague playing the user. A prompt that looks tidy on the page turns out to take eleven seconds to say. A question asked twice in different words sounds mechanical when heard back to back. The colleague will also answer in ways the script didn't anticipate, and those answers are the most useful output of the exercise.

The scripts give you the structure most voice platforms expect. Intents are what the user is trying to do, such as booking a table. Sample utterances are the many ways people phrase each intent; collect them from support logs and interviews, because the team's own phrasing is the least representative sample available. Slots are the variables inside a request, like date or party size, and each one needs a plan for when it's missing.

Writing prompts people can hold in their heads

A prompt is everything the system says before handing the turn back. The user has to remember it, so the rules are about load.

Keep turns short. Amazon's Alexa design guide lists brevity among its core principles, and the reason is mechanical: each extra clause pushes something else out of working memory.

Put the question last. The final words before the turn passes are the ones the user acts on. "Which size do you want: small, medium or large?" works. "Small, medium and large are available, which do you want, and you can also say 'more options'" buries the question and invites the user to start talking halfway through.

Past three options, offer the likeliest few and say that others exist. And accept varied phrasing: the NN/g study found third-party skills especially hard to use because each needed an exact invocation phrase. If a phrase really must be learned, teach it at the moment it becomes useful.

Match tone to the situation. A cooking assistant can be chatty; a banking one reading out a balance should be plain. Voice products carry personality more audibly than screens do, so decide the tone before writing prompts. Our guide to defining your product's tone of voice covers how to set one that holds up across contexts.

Confirmation and error recovery

Recognition will mishear. How much the system checks before acting should depend on what a mistake costs.

For cheap, reversible actions like playing a song, act at once and make the result audible: "Timer set for twelve minutes" confirms the value without asking permission. For moderate actions, such as adding to a list or messaging a known contact, repeat the key detail as part of the action and leave a short window to cancel. For payments, deletions, bookings and new recipients, ask outright and wait for a yes, reading back the amount and the recipient rather than the whole record. Explicit confirmation on every trivial request makes a product tedious. Implicit confirmation on a payment is how people end up with two taxis.

Two other events happen constantly. In a no-match, the system heard speech but couldn't map it to anything. In a no-input, it heard nothing, because the user hesitated or was interrupted.

The second attempt should never use the words of the first. Make it more specific, for instance by giving an example of what to say or asking for one slot at a time. After two failures, stop and offer another route, such as sending the request to the user's phone or handing over to a person. If the system caught the date but not the time, ask only for the time. And let people interrupt: barge-in, where the system stops talking when the user starts, matters most for returning users who already know the prompt.

The user should also be able to tell whether the system is listening. Smart speakers use a light, phones an animated indicator, and voice-only channels short sounds called earcons at the start and end of listening.

Voice and screen together

Many voice interfaces run on devices with displays: phones, cars, smart displays, TVs. In the NN/g study, phone assistants frequently answered with a page of search results, dropping users into a different interface mid-task.

A better split lets speech capture intent and the screen hold results. "Find Italian places open now near me" is quicker to say than to assemble from filters. The display then keeps the results in view for comparison, and the user can pick by voice ("the second one") or by touch. Spoken output can stay to the count and the top match.

Accessibility, accents and privacy

Voice is often the accessible option, but recognition accuracy still varies across accents, dialects and speech differences, and the non-native speakers in the NN/g study had noticeably more trouble. Someone with a stammer who needs longer pauses will run into timeouts tuned for a fluent speaker in a quiet room.

Give listening timeouts room for pauses inside a request, and keep a non-voice path for every task. Voice user interface design that only works for fluent speakers fails a large share of real users. Recruit research participants for accent and speech variety on purpose, since a convenience sample drawn from the office won't supply it.

Trust depends on privacy signals too. Users need a visible sign the device is listening and a way to review or delete recent requests by voice, not only in a settings page.

Testing before and after launch

Voice has a cheap prototyping method that predates most of the tooling: Wizard of Oz testing. A participant speaks to what they believe is a working system while a hidden researcher picks responses from a script and plays them back. You find out how people phrase requests and which prompts run too long, before any engineering starts.

Once the product is live, measure per intent and per prompt rather than per session:

• Task completion rate for each intent.
• No-match and no-input rates for each prompt; one prompt with a high no-match rate points to its wording.
• Turns to completion, compared against the number the script assumed.
• Fallback and handoff rate.
• Barge-in frequency on a given prompt.

The AI interaction hub collects our wider work on conversational and model-driven interfaces.

Frequently asked questions

What is a voice user interface?

A voice user interface (VUI) takes speech as its main input and responds with speech, sound, or speech plus a screen. Smart speakers, in-car assistants, phone assistants and automated phone lines are all VUIs. Voice user interface design covers both what the system can understand and what it says back.

How is a VUI different from a chatbot?

They share intents, slots, turn-taking and error handling. A chatbot's replies stay on screen, so the user can reread them. A voice interface's replies are gone once spoken, which is why VUIs need shorter turns and fewer options per prompt.

Do large language models change how voice interfaces should be designed?

They make interpretation more forgiving: people can phrase requests naturally, and follow-up questions work better. The listener's side is unchanged, so a long generated answer is as hard to follow as a long scripted one. Models also add decisions a scripted system never needed, such as which actions the assistant may take without confirming and how it should signal uncertainty.

How do you prototype a voice interface?

Write sample dialogues and read them aloud with a second person, then run Wizard of Oz sessions with real participants. Neither needs working software.

When should a product not use voice?

When the task centres on comparing options, reviewing detail, or saying sensitive information aloud in a shared space.

Related reading

The voice interfaces index collects teardowns and patterns specific to speech.

Sources: NN/g — Intelligent Assistants Have Poor Usability · Amazon — Alexa Design Guide · NN/g — Recognition vs Recall.

Building a voice or conversational feature and want it reviewed against real usage? Apply for a Full UX Audit →