conversational-ux
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`.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/conversational-ux && cp -r /tmp/conversational-ux/interaction-design/skills/conversational-ux ~/.claude/skills/conversational-uxSKILL.md
# 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 and the emotional context of the conversation
- **Handling failures gracefully**: the persona must remain consistent when the system fails — robotic error messages that break the established voice undermine trust
- **Avoiding false humanity**: conversFacilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.