你可以再说一次：关于语音交互的重复原则
共 6024字，需浏览 13分钟
·
2022-07-01 00:21
点击 ▲ 三分设 关注，和 6 万设计师一起学习进步
译客 2019 · 第 15 篇
作为现在大热的语音交互，已经有不少文章进行了设计探讨。但是大部分的文章还是以笼统性地介绍为主，并没有深入探讨。而在此篇，google 的设计师专注于讲解“复述”这一设计法则是如何提升语音交互用户体验的，并且结合案例，可以让读者对于语音交互如何提升用户体验有个更清晰的概念。
这篇po文摘选于《产品设计里语言设计的作用》某章节——“ 对话从这里开始”
作为初来乍到的健身房新人，我最近一直在脑海里反复告诫自己：“一分耕耘一分收获”。但是作为一个语音交互设计师和语言学家，相比提醒自己需要在背部下拉机上重复训练，我发现自身的注意力更集中在思考语言上出现的复述法则。
这里有段关于“复述”概念的小例子
A: 乔虽然是服务员，但是从另一方面来讲他也很爱涂涂抹抹啦
B：哦是吗？他喜欢涂涂抹抹哪种风格的画？
A：画？我说的是他给别人的房子涂涂抹抹！
原文，帮助理解
A: Joe’s a waiter, but he paints on the side.
B: Oh, what kind of pictures does he paint?
A: Pictures?! He paints houses.
动词 “涂刷” （paint）出现了2次，而名词 “画” （picture） 出现了一次。“明确地复述”（即B根据上文A说的“paint“，提出疑问”paint“的是什么”picture”） 将2个句子连接了起来，让对话符合逻辑。语言学家会将此作为描述语言中“连贯性”的很好的案例。
“连贯性”一般发生于一段话里，解读一个事物时，需要参考同一段话中的其他事物。衔接手段 —— 如复述、代词和话语标记① ——是指那些连接碎片化口头语或书面语的文字，让想法和细节可以融合并保持清晰意思的词组或者短语。由于这些方法将文本片段以有意义的方式连接起来，它们对确保我们交流的可靠性和理解的简便性起到了帮助。
①话语标记：话语标记是指在句法上独立的一个单词或一个短语，它一般在句中起提示、停顿或过渡的作用，大多数时候没有实际意义，如果去掉也不会影响句子的意思。类似于“well”, "I mean"。
正如“复述”在日常的对话中有效发挥作用一样，它也是语音交互中极具价值，却经常被忽视的技巧。为了弄清楚为什么复述在语音交互中如此重要，我们首先必须理解语音识别技术中的“错误接收信息”问题。
错误接受信息
首先，“正确接收信息”是指用户说出某些内容且识别器作出了正确理解。与其相反，“错误接收信息”发生于当用户说出某些内容，而识别器理解错误的情况。例如，用户说“到奥斯汀（Austin）的往返机票”，但识别器错误地将话语理解为“往波士顿（ Boston）的往返机票”。其他错误接收信息的例子是“6月13日（thirteenth）”被误认为是“6月30日（thirtieth）” ......或“四十（forty）美元”被误认为是“十四（fourteen）美元”。
随着语音识别系统变得越来越准确，错误接收信息的情况变得越发少见（即便如此，为它们设计依然至关重要，原因我们马上就会看到）。也许有一天这种情况会成为过去，但在此时，我们还没有拥有 “完美”（恩，跟真实人类一样“完美”）的语音识别技术，那么我们怎样才能将问题最小化呢？那就是复述！
这是一段识别器没有重复它所听到的“疑问”的小例子：
用户：11乘3等于多少？
语音助手：等于21。
原文帮助理解：
User: What’s 11 times 3?
Assistant: The answer is 21.
这种反应令人困惑，因为我们大多数人都知道答案不是21。这条实际上是被“设计”过的回复，看起来却像语音助手连基本的算术都做不好。而且，如果这是一个更复杂的数学问题，我们可能把这个答案当作正确结果并接受且执行它（因为我们可能无法判断它的对错性）。
现在这里有一个如果识别器向用户重复它认为听到的内容，交谈会如何进行的小对话：
用户：11（eleven）乘以3等于多少？
助理：7（seven）乘以3是21。
用户：不，11----乘以3等于多少？
助理：11乘以3等于33。
原文帮助理解：
User: What’s 11 times 3?
Assistant: 7 times 3 is 21.
User: No, what’s 11 times 3?
Assistant: 11 times 3 is 33.
通过复述我们认为用户所说的内容，很明显马上就显现出一个关于语速过快的识别问题 ——“错误接收信息”。通过使系统的识别假设对用户透明开放，语音助手似乎不再是数学不好（只是在某些场合下听力有点问题）。同时用户明白需要再次询问。
隐喻式确认
当我们只复述了来自用户请求的重要部分的信息时，称为“隐喻式确认”。这种复述在语音交互中很有用，这样用户就可以知道系统是否正确理解了请求。一方面，当识别器理解正确时，“隐喻式确认”提供了切实的保证（因为它会复述重要部分）。这种保证让用户对识别技术充满信心，尤其是如果他们过去有受到过其他不精准系统的煎熬。另一方面，当识别器理解错误时，“隐喻式确认”让用户知道他们需要再次尝试或改善他们提出的请求。这使得这个设计可以“被原谅”。也就是说，当错误发生时，这种设计可以最大限度地减少错误接收信息的后果。
以下是“隐喻式确认”的更多例子：
用户：佐治亚州的座右铭是什么？
助理：佐治亚州的座右铭是“智慧，正义，适度”。
用户：谁是印度总理？
助理：印度总理是Narendra Modi。
用户：致电AmberGómez。
助理：打电话给AmberGómez。
原文帮助理解
User: What’s the state motto of Georgia?
Assistant: Georgia’s motto is “Wisdom, Justice, Moderation.”
User: Who is the Prime Minister of India?
Assistant: The Prime Minister of India is Narendra Modi.
User: Call Amber Gómez.
Assistant: Calling Amber Gómez.
特别是如果用户无法使用屏幕 | 假设他们正在开车 | 那么听到“AmberGómez”他们知道他们即将与对的人联系。毕竟，设想一下当我们使用语音进行信息输入后，等到跟另一人交谈的那刻才意识到联系错了人，我们会感到尴尬与懊恼。这种经历让我想起一位店主给我发了一条短信，为“昨晚的争吵”发自内心给我道歉 | 然而我们并没有吵架过 | 他希望我收到时已经平静下来。糟糕，发错人了！（没错，我还回复了。）
当然，“隐喻式确认”不一定基于逐字重复原则。它也可以用同义词或释义替换：
用户：设置明天早上5:30的闹钟。
助理：好的，5:30AM。你的闹钟已设好。
......“AM”与“早上”同义。
原文助于理解
User: Set an alarm for tomorrow morning at 5:30.
Assistant: Okay, 5:30 AM. Your alarm’s set.
…where “AM” is synonymous with “in the morning.”
这里还存在一些不需要“隐喻式确认”的补充情况。例如，如果您要求您的语音助手打开闪光灯，则灯应该马上亮起——不需要信息确认。由于看到指示灯亮起本身就是一个确认，所以听到“你的闪光灯已经开启”（隐喻式确认）不会增加任何用处。（也许语音助手可以通过简单地确认来告知收到，例如“没问题”或“好的”。）另一方面，如果用户坐在客厅里然后要求他们的语音助手关掉卧室的灯，那么这里确实需要一个隐喻式确认，这样用户才知道发生了什么以及在哪里（“好的，关掉在卧室里的灯”）。
另一个考虑因素是用户是否需要看屏幕。例如，如果用户要求查看旧金山的地图，则用语音形式来进行“隐喻式确认”并不重要，因为用户无论如何都要瞥一眼屏幕，来查看识别系统给予的内容反馈。另一方面，如果用户询问旧金山的天气，我们无法猜测他们会不会参考屏幕上的信息，所以“隐喻式确认”他们的请求是个好主意。
直白确认
复述用户所说的话是另一种确认方式的基础——“直白确认”。与“隐喻式确认”不同，“直白确认”会向用户发出声明，要求他们给予“是”或“否”的确认。这里有个例子：
网友：我需要6月7日从L.A到迈阿密的航班。
助理：好的，是6月7日从Los Angeles(洛杉矶)到迈阿密航班。我理解对了吗？
用户：是的，你对了。
......语音助手重复“迈阿密”和“6月7日”，并用“Los Angeles”取代用户的“L.A”。
原文助于理解
User: I need a flight from L.A. to Miami on June 7th.
Assistant: Okay, that’s from Los Angeles to Miami on June 7th. Did I get that right?
User: Yes, you did.
…where the Assistant repeats back “Miami” and “June 7th” and replaces the user’s “L.A.” with “Los Angeles.”
直白确认和隐喻式确认的适用情况
“直白确认”适用于以下情况：
当这个字面意思的错误成本很高时，例如出售100股谷歌股票 应用于即将执行一些难以或无法撤回的操作，例如取消订单 用户已投入时间在系统里输入了许多模块的信息，例如预订机票 有一个关于交易或法律的请求需要用户明确口头同意，例如在最终确定汇款之前 （语音助手）对特定情况识别结果的准确性，信心很低
“直白确认”的好处是用户清楚如何应对。当用户被问到一个确认“是或否”的问题时，他们将知道如何在（语音识别）“接收错误信息”的情况下使对话回到正轨。
然而，“直白确认”的缺点是感觉对话进展缓慢，尤其是在多次确认的情况下。
相反，“隐喻式确认”适用于一下情况：
不太会发生由于误识别而导致的不良后果 对于识别准确度的信心很高
“隐喻式确认”的优点是速度。当系统一直正确接收信息时，相对使用体验会很高效。而当系统错误地接收信息时，用户也只丢失了语音助手复述所消耗的那几秒钟，他们还是可以简单地复述或重申他们的需求。
“隐喻式确认”的一个潜在缺点是，当用户需要修复系统的错误接收时，他们可能不知道该说些什么。在这种情况下，应该构建语法识别以配合用户试图更改错误的需求。这需要用到关于用户日常交谈的行为数据，以及语法识别的迭代改进（类似于乐器使用前的“调音”功能）。
在考虑使用哪种类型的确认时，重要的是要将识别准确性和识别错误的成本考虑在内。
总而言之，重复用户刚刚说过的内容是语音交互中信息确认决策的核心。反过来，这些策略是使这个设计可以“被原谅”的基础。也就是说，确认机制可以最小化错误接收信息的后果。
确认机制还可以建立用户的信任度。如果用户知道语音助手永远不会根据没有事先进行双重确认的识别结果做出决定，他们将可能更信任该技术并感受到对发生事物的控制权。
想要更多精彩小窍门，请查看Google的最佳语音设计案例（http://actions.google.com/design）。
特别感谢 Eunice 刘协助整理内容
故事来自谷歌鹅的设计案例。查看更多编辑文章请访问design.google
热门文章推荐
共创成长训练营
三分设·星火会员
我们一起聊设计
三分设·微信读者群/城市群
欢迎添加 ⭐️ 星标，获取每日好文推荐，每天早上 8 点，准时充电。加入设计微信交流群 三分设读者 5 群，期待与更多优秀用户体验设计师一起成长， 添加 益达 微信号【 Lil_Bug 】or【 Red-boy2020】，备注【 三分设读者 】加入读者群！
分享设计心得，定期直播，零距离连麦，答疑解惑
↓↓↓点开『阅读原文』，欢迎你的加入星球