编辑导语：在语言交互设计中，任务型对话也是常见的业务设计之一。合理的任务型对话设计可以协助用户高效获取信息、完成任务、达成目的。本篇文章里，作者总结了语音交互设计中任务型对话的设计原则与注意事项，一起来看一下。
设计脚本的本质是让用户理解对话的边界，帮助用户快速完成任务。如果对话过程中需要多轮对话，脚本能引导用户给出够用的正确的信息，然后执行用户希望完成的任务。
脚本可以模拟用户和智能助手之间的对话，就像电影或戏剧里一样，它是确定对话如何互动的好方法，还能帮助你发现一些你设计时没考虑到的状况。一个好的脚本应该是站在人们如何交谈的视角进行的，而不是通过阅读和写作视角进行刻板设计。
设计对话脚本时我们关注以下几点。
一、提升对话内容的多样性
尝试在固定回答上加入不同的对白，可以使你的语音技能听起来更真实，对于那些常用或重复交互来说可以减少机械感和枯燥感。
当用户调用技能时，可以考虑丰富多变的欢迎语，包括首次使用欢迎语、回归欢迎语和个性化的欢迎语，然后询问用户他们想要做什么；当用户多次调用技能后可以缩短问候语，帮助用户快速获取他们所希望的交互结果。
除此之外，可以考虑在此处提供关于技能基本功能的提示。设计固定回复时可以通过同义词为答案增加变化，然后从这些答案里随机选择一个作为回复。
除了固定回答的多样性，你的智能助手应该提供尽可能多的信息以促进对话。
二、尊重用户的时间
回复内容尽量在短时间内将必要的信息表达出来，避免输出不相关的信息影响用户。智能助手的回应越冗长，用户越难跟上和记住沟通的内容。
而且在交谈中，说得太多与说得太少一样不合作。从用户的角度出发，保持简短和最佳相关性有助于理解。
三、保持文案的一致性
写脚本时保持语句中动词、名词搭配时语法的一致性，还有对用户、智能助手自己的称呼。
这里有一个文案小技巧，能用“咱”时就不用“你”字，通过共同感可以拉近用户和智能助手的距离。
四、减轻用户的认知负担
透过一致的称谓来称呼同一事物，能帮助用户降低对同一事物的认知负担，并且避免不一致的心智传达给用户。统一的称呼可以让用户更清楚他正在进行的操作，不用再花时间去理解新称谓是指代什么。
人们在谈话中会自然而然避免含糊不清的表达，使用熟悉的单词和短语也有助于减轻用户的认知负担。因此编写对话内容时，应尽量避免使用“科技术语”、“专业词汇”、“方言用语”等，避免编写出不具普遍性的对话内容。
五、逐步向用户获取信息
用户在进行语音交互的大部分时候，无法圆满地将完成意图所需的关键参数都提供出来，此时应避免垄断对话，一口气向用户提出所有选项/问题，而是将信息分解成单个的独立问题，一条一条提问引导用户给出所有的答案。
六、尽量提供少于三个的选项
尽管在语音设计中提供选择列表的行为是不被鼓励的，但当用户提出一个开放性需求/问题时，多少会遇到需要进行选择的时刻。
尽量提供少于三个的选项供用户选择，如果选项过多则为用户找出与输入预期匹配度最高的前三个选项，列表中的第一项应与用户刚刚采取的操作最为相关，这样可以帮助用户节省时间和精力。
七、不要假设用户会准确地把你设想的对白表达出来
在“合作原则”中，所说的话应该满足交际所需的信息量，所以用户经常提供比语言助手真正需要的更多信息。
例如用户可以说“计划旅行”时，他也许会图方便地直接说“计划去夏威夷的旅行”，甚至把出发日期都直接说出来了。请把这种“过度回答”当做一个礼物，因为你不需要再问很多问题，用户把答案都预先告诉你了。
除此之外，包容多种对话口吻风格。用户在对话时会通过不同的说法来表示自己的意图，所以设计脚本时尽量把用户可能会说的句子、短语和单词最大范围地呈现出来，这样才能保证用户可以更好地使用你的技能。
但是有一种情况在设计上没有很好地解决办法，那就是用户说话时突然改变主意会立刻进行更正。
比如，用户可能会说“不”或者“我是说”，后面跟着正确的信息。这种情况非常依赖语音交互系统的泛化能力，在意图、词槽设计上没有较好的解决办法。
八、不要假设用户知道该怎么做或会发生什么
不要猜测用户的意思，提供事实信息让用户自己做决策，当用户需要提供信息时给出提示。
另外一个情况是，用户回答的顺序和剧本流程设计的不一致，例如买电影票时用户有可能先选电影院，或者先选电影，甚至是先选时间段，在设计剧本时要考虑全部情况。
九、在追问过程中为用户提供指导
用户给的指令或者提出的问题通常是不完整的。当用户给予的关键实体词不满足意图的需求时，智能助手需要与用户进行多轮交互获取更多的关键参数。
提出问题引导用户输入，是一种自然的提示方式。追问时要么直接问问题，要么在提示的结尾处抛出问题，这样用户就会知道如何立即回复。反之，如果问得很绕弯子，或者在应答的中段问问题，可能会导致用户在麦克风打开之前或者提示还没说完之前就开始回答，极易造成识别错误。
在设计多轮交互的追问句中，建议包含“当前情境”和“需进行的操作或选项”，这样的追问句能为用户提供继续对话的线索，并指导用户下一步该说什么。
十、避免用户进行复杂或带来高歧义性的输入
通过语音交互填写邮箱、密码和网址对用户来说是一件非常痛苦的事情，因为中间掺杂了中文、大小写数字、数字甚至是标点符号，朗读起来一点都不自然；对计算机来说，这些输入简直就是天灾。
另外，多音字、同音异义词的识别准确率也非常低，所以尽量避免让用户进行复杂或带来高歧义性的输入。
十一、针对重要请求，向用户发出显式确认；针对风险较低的请求，可以采用隐式确认方式
确认是语音界面与用户沟通的一种方式，用于检查用户的问题、命令和回复是否被正确理解，它可以保证对话的流畅度和准确度，让用户知道系统已经理解了自己的话，有利于建立用户信任并且提升语音交互的体验。
在对话中有两种类型的确认方式：显式确认和隐式确认，笔者建议系统根据不同的情境和置信区间选择合适的确认方式。
显式确认通常要与用户核实其提供的输入是否被正确地处理，或者请求用户允许操作。
采用显式确认时，智能助手在得到用户确认之前不会执行后续操作。对于某些难以撤销的操作，采用显式确认方式征得用户口头同意是较为合适的，例如资金转账的最终确认环节和免责协议的确认，但是过度的确认会让用户感到厌烦。
采用隐式确认方式，意味着VUI在回复中融入了用户话语中的关键信息，以便表明VUI理解的内容。对于识别准确性为中到高，并且潜在的负面影响较低时，采用隐式确认的方式是较为适合的。
隐式确认的优点是效率高，缺点是用户经常会不知道如何让对话重回正轨。
十二、尽量少用语气助词
在句末使用“阿、啊、啦、唉、呢”等助词可以增强语气和气势。
常见的语气词有以下这些分类：疑问语气、祈使语气、感叹语气、肯定语气和停顿语气。
目前的TTS技术很难通过文字和语境将正确的语气表达出来，大部分的语气助词只能平调朗读出来，效果很不佳，因此写脚本时注意语气助词的使用。
十三、检查对话内容是否符合人物设定
不同性格的人说的话的特征是不一样的，就像一名傲娇少女突然降低音调大吼“拿命来”的话会让用户吓了一跳。最重要的一点，切勿用高人一等的口吻和用户说话。
十四、在引起用户负面情绪的关键点上加入情感化设计
用户最讨厌别人对他说“我不知道你在说什么”，如果智能助手连续多次和用户说“我不知道你在说什么”，用户会对智能助手产生愤怒甚至绝望的感情，同时对智能助手失去信任。
为了避免这种灾难事故的发生，建议在设计对话时引入用户体验地图，在引起用户负面情绪的关键点上加入情感化设计或者转移话题。
撒娇也是一种能缓解用户情绪低落的好方法，例如第一次听不懂时可以试着回答“不好意思，这项技能我还没学会哦”；第二次听不懂时可以试着回答“回去后我会好好努力学习的，要不换个问题？”；第三次仍然听不懂时试着回答“我真的不会嘛，不要为难人家好不好”。
十五、在合适的场景说合适的话
如果深夜用户设置一个闹钟结果智能助手的回复时长高达15秒，相信用户一定会发疯。
在权限允许的情况下，如果我们能获取到用户的时间和定位信息，笔者建议对话设计时一定要考虑时间和定位信息，智能助手和人一样，要在合适的场景说合适的话。
十六、考虑多种交互方式
语音交互不一定只能通过对话进行交互，还可以结合结构化的文字和图像进行表达。有些比较复杂的内容需要播放很长的文案，例如天气预报。
这时候采取视觉可视化的方法让用户一眼就能看完，能有效提高整个交互效率。
十七、优先撰写愉悦路线
先写一个可以完成任务并且完整简单的对话，它从开始到结束，中间没有任何分支，这就是我们想要的愉悦路线。
完成愉悦路线以后，我们考虑其他可以完成任务的对话路线。这些路线和愉悦路线所完成的任务是一样的，但是中间多了一些小插曲，例如用户并没有表达出所有信息，需要语音助手去引导。
#专栏作家#
薛志荣，微信公众号：薛志荣，人人都是产品经理专栏作家。畅销书《AI改变设计-人工智能时代的设计师生存手册》作者，全栈开发者，专注于交互设计和人工智能设计。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于CC0协议。
