Overview
How might we design voice input so people can trust and act on AI output?
When this pattern fits
- Essential for mobile applications, accessibility tools, and hands-free interaction scenarios where voice input provides a more natural and convenient interaction method.
When to skip or lighten it
- Silent environments or contexts where speaking is socially impossible.
- Highly confidential spaces where audio capture is prohibited.
- Precision editing tasks better served by keyboard alone.
States
State model coming soon
Key UX elements
Key UX elements coming soon
Anti-patterns to avoid
Mic on with no visual or auditory indicator.
Finalizing transcript with no chance to edit before send.
Auto-sending voice messages without confirmation.
No fallback to typing when recognition fails.
How products use it
| Product | Implementation |
|---|---|
| ChatGPT | Voice mode with listening UI and transcript. |
| Siri | System voice input with waveform and confirmation. |
| Google Assistant | Speech-to-text with on-screen recognition feedback. |
| Claude | Voice input into the chat composer. |
Real-world examples
How shipped products implement voice input, from our teardown guides.
Implementation
Copy this prompt to generate a production-ready implementation in Cursor, Claude Code, Lovable, or any AI coding agent.
Generate a production-ready implementation of the "Voice Input" AI interface design pattern.
Pattern Definition:Frequently asked questions
What makes good voice input UX?
Clear listening state, live or near-live transcript, easy cancel, and edit-before-send for anything consequential.
How does voice input differ from voice-to-action?
Voice input primarily produces text or a prompt. Voice-to-action maps speech to a specific command or workflow.
Should partial transcripts stream?
Yes when latency allows. Streaming text reassures users they are being heard and lets them stop early.
What about noisy environments?
Show confidence, allow typed fallback, and avoid auto-send when recognition is weak.