Overview
How might we design voice visualizer so people can trust and act on AI output?
When this pattern fits
- Essential for voice assistants, voice-first applications, and hands-free interfaces where visual feedback enhances user understanding of voice interaction states.
When to skip or lighten it
- Pure text chat with no voice path.
- Accessibility settings request reduced motion.
- Background voice where visual feedback is irrelevant.
States
State model coming soon
Key UX elements
Key UX elements coming soon
Anti-patterns to avoid
Same animation for listening and speaking, so state is ambiguous.
Visualizer with no caption or icon for deaf or low-vision users.
Flashy motion that distracts from transcript content.
No idle state when mic is off but UI looks “live”.
How products use it
| Product | Implementation |
|---|---|
| Siri | Orb and waveform states on iPhone and HomePod screens. |
| Google Assistant | Animated dots and color shifts for listen vs respond. |
| Alexa | Light ring and screen pulse tied to audio activity. |
| ChatGPT | Voice mode orb with listening and speaking animations. |
Real-world examples
How shipped products implement voice visualizer, 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 Visualizer" AI interface design pattern.
Pattern Definition:Frequently asked questions
What states should a voice visualizer show?
At minimum: idle, listening, processing, and speaking. Optional: error, muted, and wake-word armed.
Is a visualizer required if you have a transcript?
Transcripts help content; visualizers help timing. Pair both for voice-first UX.
How do you respect reduced motion?
Offer static icons or subtle opacity changes instead of looping waveforms.
What about latency?
Show processing state within ~200ms of end-of-speech so users do not talk over the model.