语音/对话界面设计：当界面靠说和听而不是点击时…

适用于设计语音界面、聊天机器人或 AI 对话体验的对话结构、轮次逻辑、错误恢复和人格。

适用场景

解决思路

1. 识别界面类型：若是语音界面（IVR、智能音箱技能、语音助手），按音频优先或纯音频设计；若是对话式 UI（聊天机器人、AI 助手、消息界面），按对话轮次而不是屏幕布局来设计。
2. 对每个有意义的对话路径，编写轮次脚本：系统提示 → 用户响应 → 系统确认并给出下一提示。
3. 编写好的系统提示：一次只陈述一件清楚的事；提示用户预期给出什么类型的响应；不要把行动号召埋在长句末尾；语音场景要朗读自然，注意标点会影响节奏。
4. 按风险选择确认策略：高风险动作或易混淆输入用显式确认，例如“你说的是周二下午 3 点，对吗？”；低风险、可恢复动作用隐式确认，例如“正在预订周二下午 3 点……”；误识别少且恢复容易时可以不做确认。
5. 处理无输入错误：用户没有响应时，用原提示的较短版本重新提示。
6. 处理无匹配/误识别错误：系统听到了内容但无法解析意图时，请求澄清并给出示例。
7. 处理范围外输入：用户说了系统无法处理的内容时，承认并重定向，不要假装理解。
8. 处理部分匹配错误：系统只理解部分请求时，确认已理解的部分，并询问缺少的部分。
9. 使用错误重提示阶梯：第一次错误，用稍多上下文改写提示；第二次错误，给出明确示例或受限选项，例如“你可以说‘早上’、‘下午’或‘晚上’”；第三次错误，提供优雅退出，转向人工、其他渠道或明确停止点。
10. 不要重复同一错误提示超过一次；每次重提示都必须增加信息。
11. 为耳朵而非眼睛写作语音内容：用短句；用主动语态；不要用“点击下方按钮”等仅视觉元素；首次使用缩写和首字母缩略词时拼读完整，例如把“ETA”写成“estimated arrival time”；避免超过三项的列表，改为分块或按顺序表达。
12. 管理延迟与节奏：系统响应尽量控制在 8 秒以内；用 earcons（音频提示）标记状态转换，如开始录音、处理中、完成；在智能音箱上用明确监听提示，如“请讲”或提示音，表示麦克风已打开。
13. 设计多模态（语音+屏幕）时：口语内容必须在没有屏幕时也说得通；屏幕用于强化和消歧，不替代口语提示；卡片、按钮等交互视觉元素也必须能通过语音激活。
14. 在文本聊天界面中使用快速回复/建议芯片：限制交互范围、减少打字摩擦；只用于常见路径，不要用于所有路径。
15. 在文本聊天界面中提供持久菜单：用汉堡菜单或菜单图标提供对话线程之外的导航。
16. 在文本聊天界面中显示打字指示器：表示系统正在处理，缓解用户等待延迟时的焦虑。
17. 在文本聊天界面中使用结构化卡片：在聊天流中呈现航班详情、商品结果等信息，比原始散文更易扫读。
18. 选择文本对话模型：纯对话模型不保留持久 UI chrome，所有导航都通过对话完成；混合式模型在屏幕产品中嵌入对话输入框，聊天处理帮助、搜索和动作发起，其余产品使用常规 UI。
19. 不要把对话式 UX 模式套用到更适合表单、表格或菜单的工作流；对话擅长模糊、开放式、用户不知道确切路径的多步任务，不适合大量必填字段或复杂并行选择。
20. 把系统声音当设计决策：决定助手是否有名字，并保持一致的名字以减少多模态场景中的混淆。
21. 确定语域：正式、专业、温暖、俏皮等，应匹配产品品牌和对话的情绪语境。
22. 失败时保持人格一致：系统失败时人格仍要一致，机器人式错误信息破坏既定声音会损害信任。
23. 避免虚假人性：被认真询问时，对话式 UI 不应声称自己是人类；文本和语音都一样。
24. 发布前把每个提示朗读出来；如果口语听起来不自然，就重写。
25. 先设计不顺利路径：错误处理和范围外恢复比顺利路径更能决定体验质量。
26. 在决策点限制选择：开放式“你想做什么？”通常不如“你想开始，还是从上次离开处继续？”有效。
27. 在真实设备上用真实语音测试；TTS 合成会改变节奏，这种变化在脚本中看不出来。
28. 记录用户实际说的话；预期话语和真实话语之间的差距是最高价值的设计数据。
29. 明确设计退出路径：用户必须始终能够停止、重启或升级到人工渠道。

适用边界 · 注意事项

• 不适合更适合表单、表格或菜单的工作流。
• 不适合大量必填字段或复杂并行选择的任务。
• 如果只是图形界面收集输入，应使用 form-design，而不是对话式 UX。