Overview
How might we design voice-to-action so people can trust and act on AI output?
When this pattern fits
- Ideal for productivity tools, accessibility applications, and hands-free interaction scenarios where voice commands provide efficient, natural control.
When to skip or lighten it
- Ambiguous freeform chat better handled as voice input to text.
- Noisy rooms where recognition cannot be trusted for irreversible acts.
- Actions that still require rich visual picking the voice channel cannot provide.
States
State model coming soon
Key UX elements
Key UX elements coming soon
Anti-patterns to avoid
Executing irreversible actions with no confirmation.
No transcript of what was heard before acting.
Failing open when confidence is low.
Colliding with system assistants for the same wake phrases.
How products use it
| Product | Implementation |
|---|---|
| Siri Shortcuts | Spoken phrases that run defined automations. |
| Google Assistant | Voice commands that trigger app actions. |
| Alexa Skills | Utterances mapped to skill intents and actions. |
| ChatGPT Voice | Spoken requests that drive tools and follow-ups. |
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-to-Action" AI interface design pattern.
Pattern Definition:Frequently asked questions
How is voice-to-action different from voice input?
Voice input produces text. Voice-to-action binds an utterance to a specific operation (often with slots/parameters).
When is confirmation required?
For send, spend, delete, or external side effects—use voice confirmation or an on-screen approve.
What should the UI show after hearing a command?
The interpreted intent, key parameters, and Confirm/Cancel when needed. Then a receipt of what ran.
How does this relate to interruptibility?
Users must be able to stop mid-command. Interruptibility is the cancel gesture; voice-to-action is the execution mapping.