Must a VUI sound like a person?

No. Clear prompts and reliable interaction matter more than creating a human-like persona.

Is confirmation required after every utterance?

Not necessarily. Excessive confirmation can make simple tasks cumbersome. The design should consider ambiguity, consequence and the user's ability to correct an error.

Can a VUI include a screen?

Yes. Voice and visual interaction can complement one another, such as speaking a search request and selecting among displayed results.

AI Glossary / Natural language and speech / Beginner

Voice user interface

Definition

A voice user interface, or VUI, is the part of a system through which a person interacts using speech. It includes the spoken prompts, supported requests, responses and recovery paths that shape the user's experience.

What it means

A VUI can be as constrained as a few spoken commands or as conversational as a service that asks follow-up questions. It may operate without a screen or combine voice with visual controls.

The interface is broader than the speech recognizer. Recognition estimates what was said; interface design determines how people discover capabilities, know when the system is listening, correct misunderstandings and reach an outcome.

A natural-sounding voice can make interaction pleasant, but it does not establish that the system understands unrestricted requests. The design should communicate what the service can actually do. Users also need to distinguish a suggestion, a question and confirmation that an action has already occurred.

How it works

A voice interaction moves through states such as available, listening, processing and responding. The interface gives cues that make these states understandable. Dialogue logic determines what information is missing and whether to ask a focused question or proceed.

Recognition failures need different responses. Silence can mean the user did not hear the prompt, while an unrecognized utterance may mean the vocabulary was unsupported. Repeating the same prompt indefinitely is unlikely to resolve every cause.

Microsoft's speech-interaction guidance addresses discoverability, recognition feedback, correction and alternative input. These concerns apply even when the underlying technology changes. The goal is to make the task recoverable, not merely make the first prompt sound conversational.

Three practical examples

A cooking timer accepts a spoken duration and repeats the interpreted setting before the user relies on it.
A document application lets someone dictate text, see the result and correct a word with either speech or typing.
A service kiosk asks which branch a visitor means when two locations have similar names, then displays the selected branch.

Think of it this way

Think of the conversation rules at a service counter: how the staff member invites a request, signals that they are listening, checks missing details and explains the result.

The analogy is limited because a computer interface cannot assume the shared understanding of two people. A well-designed VUI makes important state changes explicit instead of relying on tone alone to convey what happened.

Worked example

Designing a correction path

An invented room-booking VUI receives “Book Cedar tomorrow at three.” Assume the user is authorized to book rooms, but both a three o'clock morning slot and a three o'clock afternoon slot are represented in the system.

The interface asks, “Do you mean 3 p.m.?” The user replies, “Yes, for thirty minutes.” The system now has a room, date, start time and duration. It checks availability and presents the proposed booking with the calendar date, avoiding an ambiguous repetition of “tomorrow”.

If the user says “Change it to four”, the system updates the start time while retaining the other confirmed details. It checks availability again because the earlier result no longer applies.

Only after the booking service succeeds should it say that the room is booked. A recognized confirmation, a prepared request and a completed booking are three different states. This example describes an interaction design, not an executed reservation.

Illustrative case study

A fictional university introduces a spoken interface for finding rooms. In early testing, users are unsure whether the system is still listening after it asks a question. They speak over the response or remain silent when input is expected.

The design team adds clear listening cues and short prompts. It also makes “repeat”, “go back” and a visual alternative available where appropriate. For ambiguous room names, the system offers a small set of candidates instead of asking users to repeat the same phrase without guidance.

Testing focuses on whether visitors can recover from mistakes and reach the intended room information. The team does not treat a polished synthetic voice as a substitute for usable navigation. This is a fictional case, not a measured university result.

Common misconceptions and mistakes

Treating the VUI as only speech recognition or only text-to-speech.
Hiding the listening state and expecting users to guess when to speak.
Asking a very broad question when the service supports only a few functions.
Repeating identical failure prompts without offering another route.
Announcing success before the underlying action has actually completed.
Assuming speech is accessible or comfortable for every person in every environment.

Business use

A useful VUI starts with a task that fits spoken interaction. Short requests can be convenient; comparing many detailed alternatives or editing exact codes may benefit from a visual channel.

Test with representative users and realistic surroundings. Include interruptions, long pauses, corrections, unfamiliar terms and unsuccessful service calls. Measure completion and recovery effort, not just the proportion of utterances recognized on the first attempt.

Decide what users need to know before an action and what evidence confirms completion. Let them stop speech output and change direction when the design permits it. Preserve an alternative for people who cannot or do not want to speak. Treat microphone state, data handling and the boundary of supported actions as part of the experience rather than hidden implementation details.

Check your understanding

A booking interface says “Done” immediately after recognizing “Yes”, before the server replies. What is the design problem?

Answer: It presents an accepted instruction as a completed action. The service may still fail or find the slot unavailable. The interface should report the actual operation state.

Related terms

Voice computing
Speech synthesis
speech recognition
dialogue management
turn-taking
multimodal interface
error recovery
conversational design

Learn next

Read dialogue management and multimodal interaction. Sketch a short voice task with a misunderstanding, a correction and a service failure. Write a distinct response for each state so the user knows what has and has not happened.

Sources

Microsoft, Speech Interactions: https://learn.microsoft.com/en-us/windows/uwp/ui-input/speech-interactions. This primary developer guidance covers speech interaction design, feedback and recovery. Platform-specific API limits are not treated as universal VUI properties. The room-booking walkthrough and university case are original illustrations.

Previous: Voice search Next: Voiced sound