语音应用开发中的 11 个常见错误

在海外市场，Amazon Alexa 已经拥有超过 15000 项的技能。为语音助手开发技能俨然成了一门有利可图的生意。事实上，已经出现专门为 Alexa、Cortana 等语音助手开发技能的公司或个体开发者。

本文编译自 Avoid These 11 Common Mistakes When Building Voice Applications，介绍了一些语音应用开发中常见的误区。

随着基于 Alexa、Cortana Skills 及 Google Actions 的语音应用数量的快速增加，开发语音应用的或良好或错误的实践，成为了一个热点议题。Voicebot 采访了 11 位语音应用设计和开者领域的专业人士，向他们请教开发者应该避开的误区。本文的目的在于使世界上少一些难用的语音应用。下面是问题及专家的回答。

开发者普遍会犯什么样的错误，导致语音应用的用户体验糟糕？

1. Jess Williams, Opearlo

发布语音应用之前，不做验收测试（beta test）。新版的 Amazon Alexa 提供了简单易用的验收测试工具。验收测试也有助于发现语音交互的缺陷。

2. Dan Whaley, Sabio

首要的问题在于“应用场景”——开发应用前，没有考虑特定任务是否适合用语音的方式完成。许多任务不是过于复杂，就是依赖于视觉上的层次关系。这使得用户难以通过语音接口，去理解系统的反馈，最终导致任务失败。典型的例子是机票预订。关于应用场景的判断，一个比较好的经验法则是，如果你不能（或不愿意）一边洗澡一边做某件事，那么这项技能很可能就不适合做成语音应用。

3. Paul Burden, Our Voice

对于简单的任务（例如，查询时间、天气、热点新闻等），语音助手能够很快地回复。但是，有些复杂的任务刚需要较长的处理时间，用户可能会缺乏足够的耐心。这时，他们会反复呼喊唤醒词，从而打断处理进程。对于 Echo，这会中断当前进行中的任务，转而等待新的指令。

举个具体的例子。“华盛顿大都会地区运输管理局”（Washington Metropolitan Area Transportation Authority，WMATA）开发了一款非常棒的技能，能够查询地铁系统的实时状况。想要查询地铁信息，用户只需要说：“Alexa, ask DC Metro when the next train arrives at the Bethesda stop.”。Echo 通常需要 8、9 秒的时间回应。8、9 秒似乎不是特别久，但是用户经常打断处理进程。我建议这项技能增加一个设计，在 Alexa 被打断时，向用户确认是否中止查询进程（e.g. Do you still want me to get the Metro information for you?”）。

4. Jo Jaquinta, Tza Tza Tzu

话痨。对于音频流，你不能快进、跳过或回退。你必须把音频内容全部听完。因此，当语音应用扔出一段非常长的语音回复时，用户要么怨念地等着音频播完，要么怒删 app，要么听了后半段却忘了前半段。语音应用的回复要简洁明了、传达信息要点。但同时，用户如果愿意，他们应该有办法进一步了解更精确、详细的信息。

5. Scott Werner, SaySpring

在很多常见错误中，我早期（以及许多新手）在项目中犯过的最大的一个是：没能让用户了解，他们能用这款语音应用做些什么。开发者曾经花了大量时间思考、构建应用，对于应用的技能烂熟于心。因此，当应用反馈“你接下想要做什么？”或“还有别的吗？”，开发者知道应该如何回复。但是，对于普遍用户而言，他们并不熟悉这些技能，很容易如堕五里雾中。

6. Adam Marchick, VoiceLabs

我认为一个常见的（但可以理解的）错误在于，语音应用的开发者，试图在一版应用中塞进太多的东西。现在的“对话 AI”非常强大，以至于开发者情不自禁地想在应用中一口气添加 10 项甚至更多的功能。

我的建议是，在语音应用的第一版中，提供 1 到 3 项关键功能，满足用户的潜在高频需求（每天或每周都会使用的）。然后，在运营过程中，不断分析总结，哪些功能设计是成功的，哪些地方会使用户困惑，哪些新技能是用户希望增加的。在用户对已有功能产生黏性的基础上，逐渐增加更多的功能。相比于网页或移动应用开发，语音应用开发更加具有迭代性。

7. Pat Higbie, XAPPmedia

在一轮对话中给用户太多的选项。不同于网页和手机，语音交互场景下，用户需要记住所有的选项才能进行有效的回复。因此，每轮对话提供的选择不能超过 3 项或 4 项。

8. Stephane Nguyen, Assist

语音交互通逻辑通常是基于树状流程开发，类似于互动式语音应答（IVR，Interactive Voice Response）系统（图1）。但是，人类实际的交流过程——特别是语音交流——是非常跳脱的。有多少次，你正在和朋友谈论热映中的电视剧时，朋友突然来了句”哦，对了，晚上我不想吃麻辣烫了，去吃披萨吧“。你当然不需要再重走一遍”订餐“流程来改变心意。

图1. IVR 系统示例【src】

注：这点恐怕更多是“非不为也，是不能也“。

9. Ahmed Bouzid, Witlingo

开发者并不完全理解，语音做为一种交流媒介，同视觉和触觉有着本质上的不同。在图形界面下，我们可以使用诸如下拉菜单、复选框列表、单选按钮或图片等方式来指导和帮助用户，从而可以提供任意多的选项供用户选择。用户也没有过多的认识负担，他们可以快速地浏览各个选项，然后做出决定。但在语音交互中，信息（文字）是线性、依次传达给用户的，因此：

用户每次只能听取一个选项。
用户必须记住所有的选项——而这会产生认识负担。
用户希望澄清某个选项时，必须打断当然的播报流程——而在图形界面中，使用 hover 的方式可以对选项提供解释。

更糟糕的是：语音是暂态的，转瞬即逝。因此，暂停进行中的交互流程，然后在适当时候恢复，是难以实现的。例如，你正在听着小曲，逛着淘宝时，门铃响了。在图形界面下，你只需要离开电脑去应门；取完外卖后，你可以接着逛逛逛，买买买。在语音接口下，相同场景的使用体验不要太糟心了，有没有。

10. Nick Schwab, 独立开发者

在我见到过的语音应用中，一个常见的错误是，给用户一个冗长的语音反馈。对大部分应用（游戏和新闻类除外）而言，用户不想被迫听需求之外的信息。相比于无选择性的将信息抛给用户，询问用户是否需要更详细的额外信息是一种更好的做法。

11. John Kelvie, Bespoken

应用一旦上线，便疏于管理。愤怒导致用户的差评，这是任何开发者（不论是玩儿票、独立开发者还是企业开发者）所不愿见到的。虽然开发者不能控制用户的怒火，但是搞清事故的来龙去脉，即时解决问题才是王道。