Overview
How might we design live transcript so people can trust and act on AI output?
When this pattern fits
- Perfect for meeting tools, accessibility applications, and voice-enabled platforms where real-time transcription makes audio content accessible and searchable.
When to skip or lighten it
- Silent text-only products.
- Ultra-low-latency voice UIs where transcript lag would confuse more than help.
- Highly confidential calls where storing transcript text is forbidden.
States
State model coming soon
Key UX elements
Key UX elements coming soon
Anti-patterns to avoid
Final-only transcripts with no live feedback while speaking.
Transcripts that cannot be edited after recognition errors.
No speaker labels in multi-person calls.
Auto-saving transcripts without consent.
How products use it
| Product | Implementation |
|---|---|
| Otter.ai | Live meeting transcripts with speakers. |
| Zoom | Live transcription during calls. |
| Microsoft Teams | Real-time captions and transcripts. |
| Google Meet | Captions and transcript affordances. |
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 "Live Transcript" AI interface design pattern.
Pattern Definition:Frequently asked questions
Why show a live transcript in voice AI?
So users can catch mishears early, interrupt, or edit before the system acts on wrong words.
Partial vs final transcripts?
Show partials for responsiveness, then stabilize finals. Style partials differently so users know they may change.
How does this relate to voice input?
Voice input is the capture mode. Live transcript is the readable feedback channel for that capture.
Multi-speaker necessities?
Speaker labels and diarization when more than one person talks; otherwise attribution breaks.