语音助手的替代语音 UI

对于大多数人来说，在考虑语音用户界面时，首先想到的是语音助手，例如 Siri、Amazon Alexa 或 Google Assistant。 事实上，助手是大多数人使用语音与计算机系统交互的唯一环境。

虽然语音助手将语音用户界面带入了主流，但助手范式并不是使用、设计和创建语音用户界面的唯一方式，甚至也不是最好的方式。

在本文中，我将讨论语音助手所面临的问题，并介绍一种用于语音用户界面的新方法，我称之为直接语音交互。

语音助手是基于语音的聊天机器人

语音助手是一种使用自然语言而不是图标和菜单作为其用户界面的软件。 助手通常会回答问题并经常主动尝试帮助用户。

助手不是直接的交易和命令，而是模仿人类对话并双向使用自然语言作为交互方式，这意味着它既可以接受用户的输入，也可以使用自然语言回答用户。

第一个助手是基于对话的问答系统。 一个早期的例子是微软的 Clippy，它臭名昭著地试图帮助微软 Office 的用户，根据它认为用户试图完成的事情给他们指示。 如今，助手范式的典型用例是聊天机器人，通常用于聊天讨论中的客户支持。

另一方面，语音助手是使用语音而不是打字和文本的聊天机器人。 用户输入不是选择或文本，而是语音，系统的响应也是大声说出来的。 这些助手可以是通用助手，例如可以以合理方式回答大量问题的 Google Assistant 或 Alexa，也可以是为快餐订购等特殊目的而构建的自定义助手。

尽管用户的输入通常只是一两个词，并且可以作为选择而不是实际文本呈现，但随着技术的发展，对话将更加开放和复杂。 聊天机器人和助手的第一个定义特征是使用自然语言和对话风格，而不是定义典型移动应用程序或网站用户体验的图标、菜单和事务风格。

推荐阅读：使用 Web Speech API 和 Node.js 构建简单的 AI 聊天机器人

源自自然语言反应的第二个定义特征是角色的错觉。 系统使用的语气、质量和语言定义了助理体验、同理心的错觉和对服务的敏感性，以及它的角色。 一个好的助手体验的想法就像是和一个真实的人订婚。

由于语音是我们最自然的交流方式，这听起来可能很棒，但使用自然语言响应存在两个主要问题。 其中一个问题，与计算机如何模仿人类有关，未来可能会随着对话式人工智能技术的发展而得到解决，但人脑如何处理信息的问题是人类的问题，在可预见的未来无法解决。 接下来让我们看看这些问题。

自然语言反应的两个问题

语音用户界面当然是使用语音作为一种形式的用户界面。 但是语音模态可以用于两个方向：用于输入来自用户的信息和将信息从系统输出回给用户。 例如，一些电梯在用户按下按钮后使用语音合成来确认用户选择。 我们稍后将讨论仅使用语音输入信息并使用传统图形用户界面将信息显示给用户的语音用户界面。

另一方面，语音助手使用语音进行输入和输出。 这种方法有两个主要问题：

问题#1：模仿人类失败

作为人类，我们天生倾向于将类似人类的特征归因于非人类物体。 我们看到云中飘过的人的特征，或者看着三明治，它似乎在对我们咧嘴笑。 这叫做拟人化。

这种现象也适用于助手，它是由他们的自然语言反应触发的。 虽然图形用户界面可以构建得有些中性，但人类不可能不开始思考某人的声音是属于年轻人还是老年人，或者是男性还是女性。 正因为如此，用户几乎开始认为助手确实是人。

但是，我们人类非常擅长检测假货。 奇怪的是，越接近人类的东西，越是微小的偏差开始干扰我们。 对于试图变得像人类但并不完全符合它的东西，会有一种令人毛骨悚然的感觉。 在机器人技术和计算机动画中，这被称为“恐怖谷”。

我们试图让助手变得更好、更人性化，当出现问题时，用户体验就会变得更加令人毛骨悚然和令人失望。 每个尝试过助手的人都可能偶然发现用一些感觉愚蠢甚至粗鲁的东西来回应的问题。

语音助手的恐怖谷带来了难以克服的助手用户体验质量问题。 事实上，图灵测试（以著名数学家艾伦·图灵命名）是通过当人类评估者展示两个智能体之间的对话时，无法区分它们中的哪一个是机器，哪一个是人类。 到目前为止，它从未被通过。

这意味着助手范式承诺提供永远无法实现的类人服务体验，用户必然会感到失望。 当用户开始信任他们的类人助手时，成功的体验只会增加最终的失望。

问题 2：顺序和缓慢的交互

语音助手的第二个问题是自然语言响应的回合制特性会导致交互延迟。 这是由于我们的大脑如何处理信息。

我们的大脑中有两种类型的数据处理系统：

• 处理语音的语言系统；
• 专门处理视觉和空间信息的视觉空间系统。

这两个系统可以并行运行，但两个系统一次只处理一件事。 这就是为什么你可以同时说话和开车，但你不能发短信和开车，因为这两种活动都会发生在视觉空间系统中。

同样，当您与语音助手交谈时，助手需要保持安静，反之亦然。 这将创建一个基于回合的对话，其中另一部分始终是完全被动的。

但是，考虑一个您想与朋友讨论的困难话题。 你可能会面对面而不是通过电话讨论，对吧？ 这是因为在面对面的对话中，我们使用非语言交流向我们的对话伙伴提供实时视觉反馈。 这创建了一个双向信息交换循环，并使双方能够同时积极参与对话。

助手不会提供实时视觉反馈。 他们依靠一种称为端点的技术来决定用户何时停止说话并在此之后才回复。 当他们回复时，他们不会同时接受用户的任何输入。 体验是完全单向和回合制的。

在双向和实时的面对面对话中，双方可以立即对视觉和语言信号做出反应。 这利用了人脑的不同信息处理系统，使对话变得更加顺畅和高效。

语音助手陷入单向模式，因为它们使用自然语言作为输入和输出通道。 虽然语音输入的速度比打字快四倍，但消化速度却比阅读慢得多。 因为信息需要按顺序处理，这种方法只适用于不需要太多助手输出的简单命令，例如“关灯”。

早些时候，我承诺讨论语音用户界面，该界面仅使用语音来输入来自用户的数据。 这种语音用户界面受益于语音用户界面的最佳部分——自然性、速度和易用性——但不会受到不好的部分——恐怖谷和顺序交互的影响

让我们考虑这个替代方案。

语音助手的更好选择

克服语音助手中这些问题的解决方案是放弃自然语言响应，并用实时视觉反馈取而代之。 将反馈切换到视觉将使用户能够同时给出和获得反馈。 这将使应用程序能够在不中断用户的情况下做出反应并启用双向信息流。 因为信息流是双向的，所以它的吞吐量更大。

目前，语音助手的主要用例是设置闹钟、播放音乐、查看天气和提出简单问题。 所有这些都是低风险的任务，在失败时不会让用户太沮丧。

正如《华尔街日报》的大卫·皮尔斯曾经写道：

“我无法想象通过语音助手预订航班或管理我的预算，或者通过对着我的扬声器喊配料来跟踪我的饮食。”

——《华尔街日报》的大卫·皮尔斯

这些都是信息量大的任务，需要正确进行。

然而，最终，语音用户界面将失败。 关键是要尽快解决这个问题。 在键盘上打字甚至在面对面的对话中都会发生很多错误。 但是，这并不令人沮丧，因为用户只需单击退格键并重试或要求澄清即可恢复。

这种从错误中快速恢复的方式使用户能够提高效率，并且不会强迫他们与助手进行奇怪的对话。

直接语音交互

在大多数应用程序中，通过操纵屏幕上的图形元素、戳或滑动（在触摸屏上）、单击鼠标和/或按下键盘上的按钮来执行操作。 可以添加语音输入作为操作这些图形元素的附加选项或方式。 这种交互方式可以称为直接语音交互。

直接语音交互和助手之间的区别在于，用户不是要求化身（助手）执行任务，而是直接用语音操作图形用户界面。

“这不是语义吗？”，你可能会问。 如果您要与计算机交谈，是直接与计算机交谈还是通过虚拟角色交谈真的很重要吗？ 在这两种情况下，您只是在与计算机交谈！

是的，区别很微妙，但很关键。 当单击GUI （图形用户界面）中的按钮或菜单项时，很明显我们正在操作一台机器。 没有人的错觉。 通过用语音命令代替点击，我们正在改进人机交互。 另一方面，借助助手范式，我们正在创建人与人之间交互的恶化版本，因此进入了恐怖谷。

将语音功能融合到图形用户界面中还提供了利用不同模式力量的潜力。 虽然用户可以使用语音来操作应用程序，但他们也可以使用传统的图形界面。 这使用户能够在触摸和语音之间无缝切换，并根据他们的上下文和任务选择最佳选项。

例如，语音是一种非常有效的输入丰富信息的方法。 在几个有效的替代方案之间进行选择，触摸或单击可能会更好。 然后，用户可以通过说“给我看看明天从伦敦到纽约起飞的航班”之类的话来代替打字和浏览，并使用触摸从列表中选择最佳选项。

现在你可能会问：“好吧，这看起来很棒，那么为什么我们以前没有看到过这种语音用户界面的例子呢？ 为什么大型科技公司不为这样的事情创造工具？” 嗯，可能有很多原因。 一个原因是当前的语音助手范式可能是他们利用从最终用户那里获得的数据的最佳方式。 另一个原因与他们的语音技术的构建方式有关。

一个运行良好的语音用户界面需要两个不同的部分：

1. 将语音转换为文本的语音识别；
2. 从文本中提取含义的自然语言理解组件。

第二部分是将“关掉客厅的灯”和“请关掉客厅的灯”变成相同动作的魔法。

推荐阅读：如何使用 API.AI 为 Google Home 构建自己的操作

如果您曾经使用过带显示屏的助手（例如 Siri 或 Google 助手），您可能已经注意到您确实可以近乎实时地获得成绩单，但是在您停止讲话后，系统需要几秒钟实际执行您请求的操作。 这是由于语音识别和自然语言理解都是顺序发生的。

让我们看看如何改变它。

实时口语理解：更高效语音命令的秘诀

应用程序对用户输入的反应速度是应用程序整体用户体验的主要因素。 初代 iPhone 最重要的创新是反应灵敏且反应灵敏的触摸屏。 语音用户界面对语音输入做出即时反应的能力同样重要。

为了在用户和 UI 之间建立快速的双向信息交换循环，启用语音的 GUI 应该能够在用户说出可操作的内容时立即做出反应——即使是在句子中间。 这需要一种称为流式口语理解的技术。

与在处理用户请求之前等待用户停止说话的传统回合制语音助手系统相反，使用流式口语理解的系统从用户开始说话的那一刻起就积极尝试理解用户意图。 只要用户说出可操作的内容，UI 就会立即对其做出反应。

即时响应立即验证系统正在理解用户并鼓励用户继续。 这类似于人与人交流中的点头或简短的“啊哈”。 这导致支持更长和更复杂的话语。 分别，如果系统不理解用户或用户说错话，即时反馈可以快速恢复。 用户可以立即纠正并继续，甚至口头纠正自己：“我想要这个，不，我的意思是，我想要那个。” 您可以在我们的语音搜索演示中亲自尝试这种应用程序。

正如您在演示中看到的那样，实时视觉反馈使用户能够自然地纠正自己并鼓励他们继续语音体验。 由于他们不会被虚拟角色所迷惑，因此他们可以以与拼写错误类似的方式将可能的错误联系起来——而不是个人侮辱。 体验更快、更自然，因为提供给用户的信息不受每分钟约 150 个单词的典型语速的限制。

推荐阅读： Lyndon Cerejo 设计的语音体验

结论

虽然到目前为止语音助手是语音用户界面最常见的用途，但自然语言响应的使用使它们效率低下且不自然。 语音是一种很好的信息输入方式，但听机器说话并不是很有启发性。 这是语音助手的大问题。

因此，语音的未来不应该是与计算机的对话，而是用最自然的交流方式代替繁琐的用户任务：语音。 直接语音交互可用于改善 Web 或移动应用程序中的表单填写体验，创建更好的搜索体验，并启用更有效的方式来控制或导航应用程序。

设计师和应用程序开发人员一直在寻找减少应用程序或网站摩擦的方法。 使用语音模式增强当前的图形用户界面将使用户交互速度提高数倍，尤其是在某些情况下，例如当最终用户在移动设备上、在旅途中且打字困难时。 事实上，即使在使用台式计算机时，语音搜索的速度也比传统的搜索过滤用户界面快五倍。

下一次，当您考虑如何使应用程序中的某个用户任务更易于使用、使用更愉快，或者您对增加转化感兴趣时，请考虑是否可以用自然语言准确描述该用户任务。 如果是，请使用语音模式补充您的用户界面，但不要强迫您的用户与计算机对话。

资源

• “语音优先与未来的多模式用户界面，” UXmatters 的 Joan Palmiter Bajorek
• “创建高效语音应用程序的指南”，Hannes Heikinheimo，Speechly
• “触摸屏应用程序应具备语音功能的 6 个原因”，Ottomatias Peura，UXmatters
• 混合有形和无形：使用 Adob​​e XD 设计多模式界面，Nick Babich，Smashing Magazine
  （ Adobe XD 可用于制作类似的原型）
• “音速下的效率：语音操作的承诺”，Eric Turkington，RAIN
• 在电子商务语音搜索过滤中展示实时视觉反馈的演示（视频版）
• Speechly 为此类用户界面提供开发者工具
• 开源替代品：voice2json