今天给大家分享一篇针对“语音助手”类产品的对话式交互进行讨论的文章，希望带给你更多帮助。

说到语音设计大家脑海里会浮现出各种科幻场景，其实语音设计离我们并不远，可能我们太过于熟悉，以至于忽视它的存在。

刚好自己对这一领域充满好奇，就以Siri、天猫精灵和小爱同学这三款产品体验为本，结合《语音用户界面设计》这本书的内容，写了这篇文章。

本文主要针对“语音助手”类产品的对话式交互进行讨论。

一、前世今生

看看这段话：“业务查询请按1，手机充值请按2”。每次拨打10086时，都能听到这样的回答。

这种语音交互形式叫“交互式语音应答（Interactive Voice Response，IVR）”，这也是语音设计的第一个阶段，起源于20世纪90年代。

还有我们熟悉的电话订票，电话股票交易等，都属于这个阶段的产物。

这个阶段的语音设计，为复杂的功能提供了自助的语音处理方案。语音交互的内容已经提前设定好，用户带着疑问作出特定的回答，语音系统就会给出指定的答案。

接下来的时代，各种智能设备普及了，也诞生了Siri、Google Now等语音助手，以及这几年挺火的智能音箱。

如：小爱同学、天猫精灵和腾讯听听等，几乎所有的行业巨头都参与这场盛宴，这是语音设计的第二个阶段，也是目前所处的阶段。

二、设计核心点

语音交互是一种包含丰富信息的互动形式，在设计语音交互时，可以从对话模式、引导式回答、自然沟通作为设计的核心考虑点。

1. 对话模式

谈语音设计就离不开讨论语言沟通，在日常生活中，人们之间的对话沟通从语速、用词和前后对话的内容等，就可以让对方了解到说话者表达的内容和情绪的变化。

（1）单轮对话

单轮对话是指对话内容不包含情景，没有关联上下文内容。这种对话模式导致语音交互更偏向于简短的操作任务，过于复杂的操作任务，则需要分解成简短的口令。

比如：“播放陈奕迅的歌”大多数语音系统是可以识别的；而如果说“介绍下陈奕迅”，然后再说“播放他的代表歌曲”，这种需要上下文关联、复杂的对话模式，现阶段大多数语音助手是无法识别的。

（2）连续对话

语音交互的对话模式还有另一种类型，它们搭载了自然语音处理系统，使用场景也打破单轮对话的限制，它们就是聊天机器人，也叫伴侣式机器人。

它们定位更偏向模拟人类对话，研究人机对话的领域。相信未来语音助手也可以结合对话式聊天模式，实现自然聊天并准确的进行功能操作。

比如：小米的小爱同学，有一个隐藏的技能“打开闲聊”，开启后可以进行连续对话模式。微软小冰也是聊天机器人方面比较成熟的产品之一。

2. 引导式回答

在单轮对话模式的限制中，需要特别留意语音系统的回答，引导用户正确使用简短的语音对话。

（1）确认模式

语音交互的确认模式，可以分为显性确认与隐性确认两种类型。

显性确认，是一种强制用户确认的方式。主要用于涉及钱财或者会带来严重影响的操作行为中。

当用户说帮我充个话费时，这里涉及钱财支出，则语音系统应该重复一次即将执行的命令，用户确认答复后，平台再进行对应的操作。

比如：让天猫精灵帮忙充话费，天猫精灵在进行支付前，会让用户确认一次充值内容，当用户给予肯定回答后，天猫精灵才会进行充值支付操作。

隐性确认，是根据识别的可信度进行弱确认的方式。

系统对语音内容进行打分评级，当可信度等级为高时，确认是可信的命令，直接执行对应的操作。无需用户再进行确认，或重复一次反馈结果。

比如：对Siri说“打开支付宝付款码”，Siri会直接打开支付宝软件的付款码页面，并在界面弱提示正在打开支付宝。这个过程不需要用户再去确认，因为这是一个可信的操作。

当可信度等级为中等时，系统执行对应的操作后，还需要对操作进行隐性确认，让用户知道为什么会执行当前的操作。

比如：在晚上对天猫精灵说“早上好”时，天猫精灵会播放晚间资讯，并告知现在是晚上，明天上午说“早上好”可以播放资讯等。

如下图所示（晚间资讯通过语音播放，界面没有展示文本）。

当可信度等级为低时，系统应该明确告知用户，无法识别有效的语音内容。

总的来说，隐性确认是让用户知道为什么会这样操作，用户收到语音系统的反馈就行。显性确认则是需要用户明确确认的过程。

（2）错误引导

现阶段语音系统无法避免错误识别或无法识别的情况。

出错不要紧，如何改善机器的错误反馈才是重点。

当机器无法识别或识别的内容属于低可信度时，机器需要引导用户去用正确的语句结构来对话，千万不要自作聪明地尝试回答。

比如：跟Siri对话时，如果Siri没有检测到语音，则会通过界面，给予文字反馈；超时没说话时，则会展示“你可以这样问我”的引导页。

当遇到Siri无法回答的问题时，则会给予简单的文字引导。

跟小爱同学对话时，经常会遇到跑题的情况。这种过度自信的回答很容易给用户带来负面感受。

（3）语音之外的反馈

对于语音助手类产品来说，语音是一种交互方式，但不是唯一的。产品一般会搭配硬件和软件来使用。

所以除了语音之外，不要忽略其他反馈的渠道。

同时语音交互有自身的优势，可以不受物理位置的影响，可以简单快捷的上手学习，不需要去学习界面的操作。但是界面交互也有自身优势，如展示列表类内容等复杂信息。

比如：让小爱同学播放歌曲时，小爱同学会通过语音形式播放对应的歌，但也会在界面中静默展示播放列表。

除了界面的辅助反馈外，也不要忘记物理反馈。在唤醒小爱同学和天猫精灵时，这两个音箱都会亮起灯光，用于示意已经唤醒设备，正在接收语音内容中。

3. 自然沟通

对于自然沟通的语音设计来说，可以尝试以下几个方向。

（1）个性化

每个人都有自己的说话方式，跟机器进行对话也会带着自己的习惯。每个语音系统也可以有自己的个性，这是设计者可以考虑塑造的机器人格。

比如：分别问天猫精灵、小爱同学、Siri“你喜欢什么颜色”，可以得到三种不同类型的回答。

如图可以看出Siri、天猫精灵和小爱同学都有自己的性格差异。

当调戏Siri和小爱同学，不断重复它们的回答时。

Siri会带有情绪地说“奇怪，难道这里有回音”。而小爱同学会带有情绪地说“别闹，我才是小爱”。

甚至问Siri圆周率是多少时，它还会加上一些“无意义”的语气词，如“呼气！”。

可惜的是，Siri并不是真正模拟呼气的过程，而是用平缓的语气念出了“呼气”两个字，这也许是出于对“恐怖谷理论”的担忧吧。

（2）本土文化

本土文化也是自然沟通的考虑因素之一，不同文化所用的语言不同，导致在选词造句上都存在很大的差异。

像日常沟通中，人们会用上谚语来表达自己想描述的内容。在语音助手类产品中，Siri是做得比较好的。

比如：当遇到英文单词时，Siri会用中文读出来。说谢谢时，Siri会引用“一家人不说两家话”这样的地方用语来回答。

（3）语意分析

对于实现自然沟通来说，语意分析算是重点，也是难点之一。在很多语言中，同一个词在不同场景下说出来，经常表达着不同的含义。

像“晚上好”，我们也可以用“晚安”来表达。“早上好”甚至可以省略为一个“早”字，在语音设计的过程中，建立用户词库以及关键词归类，可以更自然的分析用户的语意。

通过通配符和逻辑表达式，系统可以更好的识别含义相近的语句。

将“电脑慢”这样的关键词定义为通配符，并将“名词+形容词”的语句表达式定义为归为同一类逻辑。系统就可以认为“电脑慢”、“电脑很慢”、“电脑真的很慢”等等相近含义的语句归为同一含义。这有点像微信公众号的关键词自动回复一样。

通过建立词库的形式，也能实现更自然的语意分析。

词库有两种建立的方案，一种是将整理归纳好的词库，提前内置到语音助手中。另一种则是提供自定义功能，让用户在日常使用中，不断去教育，修正语音助手的词库。这就像输入法的词库设计一样。

比如：对天猫精灵说关闭、睡觉、闭嘴、安静等，都可以触发设备的关闭操作。而小爱同学有“小爱训练”，用户可以自定义关键词并定义该关键词要执行的操作。

这是主动去教育语音助手，形成用户独有词库的方式。

通过分析语句中的通配符，未来还有很多可能性。

当人感觉到生气时，常用命令式的对话，同时会用上情绪用词，通过这些词汇，语音助手可以更精确的识别使用者的情绪变化，做出更自然的回复。

但在准确率还无法保证的情况下，谨慎把语音助手做得过分“智能”，因为识别错误率过高，更容易引起用户的负面情绪。

（4）过度关怀

想象下，你跟朋友说“晚安”，朋友回复你“晚安，做个好梦哦。明天深圳的天气是晴转多云……”

可能偶尔一两次，还会觉得这位朋友好贴心，睡觉前还告诉你明天的天气。但长期接触后，就会觉得这位朋友好啰嗦，这个故事来源于小爱同学的晚安反馈，每次说晚安都过度关怀用户。

对于语音助手来说，虽然趋势是拟人化，但设计者要把握拟人的程度，语音助手自身提供的语音反馈应该是简明的单一操作。复杂的组合操作应该由辅助屏幕来呈现，或是由用户自定义语音任务来触发。

三、总结

语音交互相对界面交互，还存在一些缺点：在公共场景使用会有点尴尬。有些用户存在心理障碍，不适应跟机器对话。丰富的信息内容也不合适单独用语音来表示。

虽然存在这些缺点，但是语音交互还是会成为未来主流交互方式之一。它可以释放双手，学习门槛也更低，用户直觉的说出操作就行，不需要去学习界面交互。更具有同理心，通过语气、音量、语调、语速等就可以获知使用者心情的变化。

最后，在语音交互的设计中，我们可以遵循一些原则：

1. 保护用户的隐私。
2. 保持自然的沟通。
3. 保持简短的回复。
4. 提供明确的反馈。
5. 对识别内容的支持修正。
6. 了解语音识别的局限性。

作者：mufly

来源：https://www.ui.cn/detail/439773.html

本文由 @mufly 授权发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议