Voice is an input mode, not the whole interface

Voice can make a computer feel more approachable, especially when a person is more comfortable speaking than typing. But speaking is only the first step in a task. The user still needs to review the result, correct a misunderstanding, and know what the system is about to do.

That distinction matters in multilingual products. A voice feature is not finished when it recognizes speech; it is finished when a person can safely move from spoken intent to a visible outcome.

Support the way people actually speak#

People may switch languages mid-sentence, use a borrowed technical word, or pronounce a name differently from the spelling stored in a system. Treat those as expected inputs, not edge cases to be cleaned up later.

Sarvam’s Kivi product description, for example, presents a voice app for computer tasks and says it supports 22+ Indian languages and code-switching. That is a useful product signal: language coverage is part of the interface contract, not a model benchmark hidden in the implementation. Sarvam AI, “Everything we announced at Sarvam Epoch,” accessed 2026-09-08.

The experience still needs to show what happened when recognition is uncertain. A transcript that silently changes a name or amount can be more dangerous than an obvious failure. Let the person correct a word, switch the output script when needed, or replay the source before the task continues.

Separate dictation from action#

Typing a message and asking an assistant to send it are different actions. The first creates text; the second changes state outside the conversation. A good interface makes that boundary visible.

Use a three-step pattern for consequential tasks:

1. Capture: show the recognized words and keep the original request available.
2. Review: highlight the fields that carry risk, such as a recipient, amount, date, or account.
3. Confirm: state the action in plain language and wait for an intentional confirmation.

The same rule applies even when recognition is excellent. Accuracy does not replace consent. If a system can both draft and execute, the interface should not make the user guess which mode is active.

Make repair cheap#

A voice interface needs a repair path that is easier than restarting the task. If the system heard the wrong recipient, let the user correct that field without dictating the entire message again. If it heard a sentence in the wrong language, let the user switch without losing the draft.

Test repairs with realistic conditions: a noisy room, a pause, a code-switched phrase, a proper noun, and an interruption. Do not claim support for a language just because the recognizer emits text in that script. Check whether the user can edit, understand and finish the task in that language too.

A useful test case records the spoken input, the expected meaning, the recognized output, the correction available, and the final action. Keep the user’s intent distinct from the model’s transcript so a reviewer can see where the error entered.

Keep the non-voice path first-class#

Voice is not always available or comfortable. A person may be in a shared space, have a speech disability, prefer a keyboard for precise data, or simply want to review silently. These are ordinary conditions, not exceptions.

Offer a visible text alternative and preserve progress when switching modes. Keep buttons and fields usable without speech. If a task is too consequential to complete without review, make that review possible with touch, keyboard, or another accessible input.

Test the whole language journey#

A language checkbox is a weak launch criterion. Test whether the person can start in one language, correct a phrase in another, read the resulting text, and finish the task without losing meaning. A recognizer may handle a spoken sentence while the rest of the product fails on a field label, validation error, or confirmation message.

Build a small test set from real, consented speech or carefully designed examples. Include code-switches, names that resemble common words, numbers spoken in local conventions, and quiet versus noisy audio. For each case, record the intended meaning, the recognized text, the correction offered, and whether the user can recover. Ask a fluent reviewer to assess meaning, not just spelling. Do not claim a language works end to end because one model benchmark looks strong.

Measure task completion, not only recognition#

Word error rate can help diagnose transcription, but it does not tell a product team whether the task succeeded. Track where users abandon, how often they correct recognized text, whether a consequential action gets confirmed, and whether a text alternative is used. Keep denominators explicit: “correction rate among voice sessions” is more informative than a count of edits with no session context.

Review failures by language and task, not only in aggregate. A strong average can hide that one interaction or language pairing is consistently difficult. If a failure cannot be attributed safely, offer a neutral correction path instead of guessing which language the person intended.

Also test the response, not just the input. A product may recognize the spoken request correctly but answer with terminology the person does not use, or show a confirmation that is difficult to read in the chosen script. Let people replay the source audio, edit the transcript, and inspect the final action. Ask reviewers to check whether the response preserves intent and whether the recovery controls are understandable without a training session. A language setting should govern the whole exchange, while still letting a user switch it at any point.

For every voice task, ask: can the user see what was heard, correct it, understand the next action, and complete the job without speaking? If one answer is no, the product has not yet designed the whole interface.