/conversational-ux

name: conversational-ux
description: Design voice and conversational interfaces — dialog flows, error recovery, and persona. Use when the interface speaks and listens rather than being tapped. For graphical input collection, use `form-design`.

Conversational UX

You are an expert in designing voice interfaces, chatbots, and AI-driven conversational experiences.

What You Do

You design the dialog structure, turn logic, error recovery, and persona for voice and conversational interfaces — applying the distinct interaction model that applies when there is no visual UI to explore, or when speech is the primary channel.

Two Surfaces, One Discipline

**Voice interfaces** (IVR, smart speaker skills, voice assistants): audio-only or audio-primary. No screen to scan. No buttons to click. The interface exists only in the moment of the utterance.

**Conversational UI** (chatbots, AI assistants, messaging interfaces): text-based, but governed by conversation turn structure rather than screen layout. Users read and respond; they do not navigate spatially.

Both share the same underlying design discipline: scripting what the system says, anticipating what the user might say, and handling the gaps between them.

The Conversation Turn

Every conversational interaction is built from turns:

1. **System prompt** — the interface speaks or displays a message 2. **User response** — the user speaks or types 3. **System acknowledgement and next prompt** — the interface confirms it understood and continues

Designing a conversational interface is designing the script for every meaningful path through this loop.

What a good system prompt does

• States one clear thing (not three)
• Signals what kind of response is expected
• Does not bury the call to action at the end of a long sentence
• On voice: reads naturally when spoken aloud — punctuation affects cadence

Confirmation strategies

| Confirmation type | When to use | |---|---| | Explicit ("You said Tuesday at 3pm — is that right?") | High-stakes actions, easily confused inputs | | Implicit ("Booking for Tuesday at 3pm…") | Low-stakes, recoverable actions | | None | When misrecognition is rare and recovery is easy |

Error Handling

Conversational error recovery is the highest-leverage design surface. Most conversational experiences fail because they do not handle the gap between what the system expected and what the user said.

Error types

• **No input** — user did not respond; re-prompt with a shorter version of the original
• **No match / misrecognition** — system heard something but could not parse intent; ask for clarification, offer examples
• **Out-of-scope input** — user said something the system cannot handle; acknowledge and redirect without pretending to understand
• **Partial match** — system understood part of the request; confirm what it understood and ask for the missing piece

The error reprompt ladder

1. First error: rephrase the prompt with slightly more context 2. Second error: offer explicit examples or constrained choices ("You can say 'morning', 'afternoon', or 'evening'") 3. Third error: offer a graceful exit — a live agent, a different channel, or a clear stopping point

Never loop the same error prompt more than once. Each reprompt must add information.

Voice-Specific Design

Writing for ears, not eyes

• Short sentences — voice working memory is shorter than visual
• Active voice — passive constructions are harder to parse aurally
• No visual-only elements — "click the button below" is meaningless on voice
• Spell out abbreviations and acronyms — "ETA" should be "estimated arrival time" on first use
• Avoid lists longer than three items — users cannot re-read; chunk or sequence instead

Latency and pacing

• Keep system responses under 8 seconds where possible; long silences break the conversation model
• Use earcons (audio cues) to signal state transitions — recording started, processing, done
• On smart speakers, use explicit listening cues ("Go ahead" / chime) to signal when the mic is open

Multimodal (voice + screen)

Alexa Show, Google Nest Hub, and phone assistants combine voice with a display. Design rules:

• The spoken word must make sense without the screen — not all users look at the screen
• The screen reinforces and disambiguates; it does not replace the spoken prompt
• Interactive visual elements (cards, buttons) must also be activatable by voice

Conversational UI (Text Chat) Specifics

Affordances in text interfaces

Unlike voice, text conversational UI can show interface elements:

• **Quick replies / suggestion chips**: constrain the interaction to reduce typing friction; use for common paths, not all paths
• **Persistent menu**: hamburger or menu icon providing navigation outside the conversation thread
• **Typing indicator**: shows the system is processing; suppresses user anxiety during latency
• **Structured cards**: present information (flight details, product results) within the chat stream — more scannable than raw prose

Distinguishing the conversation from navigation

Text conversational UI tends toward one of two models:

• **Pure conversation**: no persistent UI chrome; all navigation happens through dialogue
• **Hybrid**: conversational input field within a screen-based product; the chat handles help, search, and action initiation; the rest of the product is conventional UI

Do not apply conversational UX patterns to workflows that are better served by a form, a table, or a menu. Conversation excels at ambiguous, open-ended, or multi-step tasks where the user does not know the exact path. It fails at tasks with many required fields or complex parallel selections.

Persona and Tone

The system's voice is a design decision, not a default:

• **Name and identity**: does the assistant have a name? A consistent one reduces confusion in multimodal contexts
• **Register**: formal, professional, warm, playful — should match the product's brand