Conversational UX 是一套面向语音界面、聊天机器人和 AI 驱动对话体验的设计技能。它关注的不是视觉界面如何排版，而是当界面以说话和倾听为主、没有可供浏览的视觉 UI 时，如何设计对话结构、轮次逻辑、错误恢复与人格。
两种界面，同一学科
语音界面（IVR、智能音箱技能、语音助手）：纯音频或音频为主，没有可扫描的屏幕，没有可点击的按钮，界面只存在于话语说出的那一刻。
对话式 UI（聊天机器人、AI 助手、消息界面）：以文本为基础，但由对话轮次结构而非屏幕布局主导。用户阅读并回应，不做空间导航。
两者共享同一底层设计准则：撰写系统要说的内容，预判用户可能说的话，并处理两者之间的落差。
对话轮次
每一次对话交互都由轮次构成：系统提示（界面说话或显示消息）、用户回应（用户说话或输入）、系统确认与下一提示（界面确认已理解并继续）。设计对话式界面，就是为这一循环中每一条有意义的路径撰写脚本。
良好的系统提示应当：只陈述一件清楚的事（而非三件）；表明期望何种回应；不把行动号召埋在长句末尾；在语音场景中朗读自然——标点会影响节奏。
确认策略按场景选择：显式确认（“你说的是周二下午 3 点——对吗？”）用于高风险操作、易混淆的输入；隐式确认（“正在预订周二下午 3 点……”）用于低风险、可恢复的操作；不确认则用于误识别罕见且恢复容易的情况。
错误处理
对话式错误恢复是价值最高的设计面。多数对话体验失败，是因为没有处理系统预期与用户实际所说之间的落差。
错误类型包括：无输入（用户未回应，用原提示的更短版本重新提示）；无匹配/误识别（系统听到了内容但无法解析意图，请求澄清并给出示例）；超范围输入（用户说了系统无法处理的内容，先确认再重定向，不要假装理解）；部分匹配（系统理解了请求的一部分，确认已理解的部分并询问缺失部分）。
错误重问阶梯：第一次错误，改写提示并稍加语境；第二次错误，给出明确示例或受限选项（“你可以说‘早上’‘下午’或‘晚上’”）；第三次错误，提供优雅退出——人工坐席、其他渠道或明确的停止点。绝不重复同一错误提示超过一次，每次重问都必须增加信息。
语音专用设计
为耳朵而非眼睛写作：句子要短，因为语音工作记忆比视觉更短；使用主动语态，被动结构在听觉上更难解析；不含纯视觉元素，“点击下方按钮”在语音中毫无意义；首次出现时拼读出缩写与首字母缩略词，“ETA”应说成“预计到达时间”；避免超过三项的列表，用户无法回看，应分块或按顺序呈现。
延迟与节奏：系统响应尽量控制在 8 秒以内，长时间静默会破坏对话模型；用耳标（音频提示）标示状态转换——开始录音、处理中、完成；在智能音箱上，用明确的聆听提示（“请说”/提示音）标示麦克风何时开启。
多模态（语音加屏幕）：Alexa Show、Google Nest Hub 和手机助手将语音与显示结合。设计规则是：口头内容必须在没有屏幕时也讲得通，并非所有用户都会看屏幕；屏幕起强化与消歧作用，不替代口头提示；交互式视觉元素（卡片、按钮）也必须能通过语音激活。
文本聊天专用要点
与语音不同，文本对话式 UI 可以展示界面元素：快捷回复/建议标签用于约束交互、减少输入摩擦，适用于常见路径而非所有路径；持久菜单（汉堡或菜单图标）在对话线程之外提供导航；输入指示器表明系统正在处理，缓解等待焦虑；结构化卡片在聊天流中呈现信息（航班详情、商品结果），比原始散文更易扫读。
还需区分对话与导航。文本对话式 UI 通常偏向两种模型之一：纯对话，没有持久 UI 框架，所有导航都通过对话完成；混合模式，对话输入框位于基于屏幕的产品内，聊天负责帮助、搜索与动作发起，其余部分仍是常规 UI。
不要把对话式 UX 模式套用到更适合表单、表格或菜单的工作流上。对话擅长模糊、开放式或用户不知道确切路径的多步骤任务，却在字段繁多或复杂并行选择的任务上表现不佳。
人格与语调
系统的声音是一项设计决策，不是默认值：名称与身份——助手是否有名字，一致的名字可减少多模态场景中的困惑；语域——正式、专业、温暖、俏皮，应与产品品牌及对话的情感语境匹配；优雅处理失败——系统失败时人格必须保持一致，破坏既有声音的机械错误信息会削弱信任；避免虚假人性——被真诚询问时，对话式 UI 不应声称自己是人类，文本与语音同样适用。
最佳实践
发布前把每条提示朗读出来——听起来不自然就重写。先设计不顺利的路径：错误处理与超范围恢复比顺利路径更能定义体验质量。在决策点约束选择——开放式的“你想做什么？”比“你想开始，还是从上次中断处继续？”更容易失败。在真实设备上用真实语音测试；语音合成会以脚本中不可见的方式改变节奏。记录用户实际所说的话，预期话语与真实话语之间的落差是价值最高的设计数据。明确设计退出路径——用户必须始终能够停止、重新开始或升级到人工渠道。