Dictum Voice UI Design

Workflow

1. Inspect the host product first: input shape, density, brand colors, interaction style, mobile constraints, and where speech should appear.
2. Treat Dictum as embedded product UI, not a generic recorder. The voice surface should look owned by the host app.
3. Design around explicit SDK states and events:
   • States: ready, requesting microphone, listening, paused, retrying, transcribing, error.
   • Events: state change, volume change, transcribing, insert, retry, permission, empty audio, no speech, network, quota, auth, format, and audio length outcomes.
4. Keep the control visible but compact. Use a microphone, waveform, spinner, check, stop, pause, retry, or warning icon only when the state requires it.
5. Show progress where users need confidence:
   • Listening: live audio signal or active capture affordance.
   • Transcribing: spinner plus concise status text.
   • Inserted: transcript appears in the target or preview, not in a detached debug surface.
   • Error: short recovery copy plus one clear next action.
6. Preserve keyboard, touch, and pointer ergonomics. The voice control must be tappable on mobile and must not steal normal typing behavior.
7. Match the host design tokens. Use Tailwind tokens or declared theme variables; keep provider-specific colors isolated inside provider-inspired mockups.

Design Rules

• Do not add SDK-owned overlays, floating panels, hidden debug cards, or generic audio-upload UI.
• Do not expose raw SDK internals, transport frames, provider names, or implementation details to end users.
• Do not make state labels look clickable unless they actually are controls.
• Do not rely on color alone for state. Pair color with icon, motion, text, or shape.
• Keep animations short and consistent with the host motion system. Animate transform and opacity when possible.
• For provider-inspired examples, reproduce the interaction pattern, not a misleading fake product integration.
• For marketing demos, show the transcript landing in the real target surface users understand.

Output Checklist

• The ready, listening, transcribing, inserted, paused, and error paths are all represented.
• The UI can recover from permission denied, no speech, empty audio, network error, auth error, quota exceeded, and audio too long.
• Mobile and desktop layouts keep the control aligned with the input, not floating elsewhere.
• The design avoids competitor claims and focuses on voice input integrated into sites or apps.
• The implementation can be driven by public SDK states/events without private worker assumptions.