Agent SkillsOwl-Listener/designer-skills › conversational-ux

conversational-ux

GitHub

专注于语音和对话式界面设计,涵盖对话流、错误恢复及角色设定。适用于无视觉UI或语音为主的交互场景,指导系统提示语设计与多轮对话逻辑。

interaction-design/skills/conversational-ux/SKILL.md Owl-Listener/designer-skills

Trigger Scenarios

设计语音助手或聊天机器人交互流程 处理对话中的错误恢复与澄清策略 定义AI助手的角色与人设

Install

npx skills add Owl-Listener/designer-skills --skill conversational-ux -g -y
More Options

Non-standard path

npx skills add https://github.com/Owl-Listener/designer-skills/tree/main/interaction-design/skills/conversational-ux -g -y

Use without installing

npx skills use Owl-Listener/designer-skills@conversational-ux

指定 Agent (Claude Code)

npx skills add Owl-Listener/designer-skills --skill conversational-ux -a claude-code -g -y

安装 repo 全部 skill

npx skills add Owl-Listener/designer-skills --all -g -y

预览 repo 内 skill

npx skills add Owl-Listener/designer-skills --list

SKILL.md

Frontmatter
{
    "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 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: conversational UI should not claim to be human when sincerely asked; this applies to text as much as voice

Best Practices

  • Write every prompt aloud before shipping — if it sounds unnatural spoken, rewrite it
  • Design the unhappy path first: error handling and out-of-scope recovery define the experience quality more than the happy path
  • Constrain choice at decision points — open-ended "What would you like to do?" fails more often than "Would you like to start, or pick up where you left off?"
  • Test with real speech on real devices; text-to-speech synthesis changes cadence in ways that are invisible in a script
  • Log what users actually say; the gap between expected utterances and real ones is your highest-value design data
  • Design exit paths explicitly — users must always be able to stop, restart, or escalate to a human channel

Version History

  • 20e34c4 Current 2026-08-19 23:21

Same Skill Collection

design-ops/skills/design-critique/SKILL.md
design-ops/skills/design-debt-audit/SKILL.md
design-ops/skills/design-impact-reporting/SKILL.md
design-ops/skills/design-qa-checklist/SKILL.md
design-ops/skills/design-review-process/SKILL.md
design-ops/skills/design-sprint-plan/SKILL.md
design-ops/skills/handoff-spec/SKILL.md
design-ops/skills/team-workflow/SKILL.md
design-ops/skills/version-control-strategy/SKILL.md
design-research/skills/affinity-diagram/SKILL.md
design-research/skills/card-sort-analysis/SKILL.md
design-research/skills/diary-study-plan/SKILL.md
design-research/skills/empathy-map/SKILL.md
design-research/skills/interview-script/SKILL.md
design-research/skills/jobs-to-be-done/SKILL.md
design-research/skills/journey-map/SKILL.md
design-research/skills/research-repository/SKILL.md
design-research/skills/summarize-interview/SKILL.md
design-research/skills/survey-design/SKILL.md
design-research/skills/usability-test-plan/SKILL.md
design-research/skills/user-persona/SKILL.md
design-systems/skills/accessibility-audit/SKILL.md
design-systems/skills/component-spec/SKILL.md
design-systems/skills/design-system-governance/SKILL.md
design-systems/skills/design-token/SKILL.md
design-systems/skills/documentation-template/SKILL.md
design-systems/skills/icon-system/SKILL.md
design-systems/skills/localization-design/SKILL.md
design-systems/skills/motion-system/SKILL.md
design-systems/skills/naming-convention/SKILL.md
design-systems/skills/pattern-library/SKILL.md
design-systems/skills/theming-system/SKILL.md
designer-toolkit/skills/case-study/SKILL.md
designer-toolkit/skills/design-negotiation/SKILL.md
designer-toolkit/skills/design-rationale/SKILL.md
designer-toolkit/skills/design-system-adoption/SKILL.md
designer-toolkit/skills/design-token-audit/SKILL.md
designer-toolkit/skills/presentation-deck/SKILL.md
designer-toolkit/skills/ux-writing/SKILL.md
interaction-design/skills/animation-principles/SKILL.md
interaction-design/skills/doherty-threshold/SKILL.md
interaction-design/skills/error-handling-ux/SKILL.md
interaction-design/skills/feedback-patterns/SKILL.md
interaction-design/skills/fitts-law/SKILL.md
interaction-design/skills/form-design/SKILL.md
interaction-design/skills/gesture-patterns/SKILL.md
interaction-design/skills/hicks-law/SKILL.md
interaction-design/skills/interfaces-that-feel/SKILL.md
interaction-design/skills/jakobs-law/SKILL.md

Metadata

Files
0
Version
20e34c4
Hash
ed9a628f
Indexed
2026-08-19 23:21

- 위키
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-08-20 04:12
浙ICP备14020137号-1 $방문자$