Google 对话式交互规范指南（六）：像你的用户一样，善于合作化的表达

2017-08-20 20:22:00

这一小结主要是围绕用户对话中的自然惯例展开更细致的探讨，其中给出了几条具体的设计建议。

以下为正文：

对话不仅是简单的信息互通。

在对话中，我们会分享各自对话题的自然假设。我们知道谈话应该如何展开。我们也会对参与者对谈话贡献的质量与数量有所期许。此外，我们会保持礼貌、尊守一致性及其他交谈自然法则。每个人都本能知晓如何在表面意思下探寻更深层次的含义。然而，虽然谈话是一种自然行为，但它的过程是非常复杂的。

语言哲学家Paul Grice说过，人们为了被相互理解，需要合作式的谈话。他称之为合作法则。在假定谈话存在潜在的合作关系时，我们就可以忽略大量信息，提升谈话效率。通常在问”你是否…”时，实际上并不只是期望对方回答是或否，而是代表着一种间接礼貌的询问更多细节的方式。

他也创建了格里斯法则，来定义合作式谈话的基础原则：

质量 ——只说真实的内容
数量 ——恰到好处，不多不少
相关 ——只说和主题有关的内容
态度 ——简单直接，避免模棱两可

换句话说，人们需要在对话中真诚、提供有价值的信息、紧扣主题并且保持简洁清晰。这也是对话UI要遵循的原则。

逻辑和准确性不是万能法则

口语表达通常会呈现的无逻辑和不精确。例如：Sue一共有五个孩子，那么“Sue有两个孩子”在逻辑上也是对的。但这个表达在谈话中就会有误导性，因为没有交代清楚上下文背景（例如可以补充陈述：“Sue的另外三个孩子…”）。

另外，有时候人们会故意的打破合作原则。在某些场景下，他们只是尝试让自己表现的礼貌。例如当问及某人在工作面试中的表现，他们可能为了避免给出负面答案，会说“他的领带还不错”。

对话UI必须要去适应、符合人们这些自然的谈话法则。

语法识别和对话修复/纠错是密不可分的

UI设计师还需要预见“出错”，并且要了解语义识别（在对话中人们的回答可能出现的全部情况）是如何构建出来的。例如下面这个例子：预订机票中的确认场景。

如果答案是肯定的，那么人们更有可能给出一个简短的回答，例如yes、yeah、Correct、That’s right等等，但是如果答案是否定的，人们通常不会只是说no，而是有可能回答说：“不，不是Geneva，我说的是Jamaica”，或是“不，不是13号，是三十号，three zero”，亦或是只回答他们听到的部分，例如“时间对了，但是日期不对”。

如果由于技术限制，你的UI不能够达到这样智能的交流程度，那么也就不应该让用户误以为系统能够达到。这种情况下，对话的修复就要有一定的限制性，例如“那么，我理解的对吗”这样的表达，只需要用户回答是或否——也就是说，让用户了解到UI的局限，这样就可以预先规避表达不自然的问题。

当UI没有被设计好，不能理解正确、有质量的信息或附加信息，那么就很可能把一些自然的合作化的口头表达误以为是没有合作性的。因此，当人们的表现不符合系统预期时，这种语言误解会不同程度的展现为粗暴、机械化的错误提示，例如”这个回答无效”，或是表现出一种假装关心的语气，像是”对不起，我没听明白这个回答”。

用户多样化的回答是机会，不是”错误”

要考虑如何设计问题，能够预判断出需要修复的场景，以便让对话保持在正轨上，同时不会引起用户不适或分散用户注意力。事实上，这样的场景有机会转化为另一种有价值的对话。

目前为止，用户会倾向于仅仅围绕对话的字面意思去互动，而并不会提供一些额外信息，尽量避免所谓的”自然的合作互动”，以免引起机器的理解错误。因为他们过去曾经在语音识别方面有过糟糕的体验。UI设计师就需要尽量的让这些用户感到舒服。

让我们看一个例子，这个场景中，对话UI需要搜集日期和时间数据，它需要用一种通用的、并且同时适合搜集这两种信息的提示方式：

然而，有的用户会更愿意试探，或每次提供较少的信息，此时UI不应该把这种情况定位为出错，而是应该去做出简单的调整和适应：

上面的过程并没有把对话UI的自然、合作互动、适应性的这些潜在逻辑暴露给用户。用户可能在根本没有提示的前提下用简单的指令就完成整个任务，也就是给出一两条信息，由UI自己把那些潜在缺失的、用户没有说出来的信息补充完整（例如”把闹钟设到周一早晨6点”、”在6小时后叫醒我”、”把闹钟设到7点”）。

采用”好的，什么时候？”这种提示可以激发用户把脑海中想到的日期或时间或是两者直接的表达出来，这种提示也是符合合作互动原则的。

当你必须做出额外解释的时候，你就输了，就像讲笑话一样

好的对话UI应该能够利用语言和表意的内在力量，而不是去展现机器处理指令的能力。它需要利用好人们已知的、也是最熟悉的沟通系统——日常对话。我们已经对自己的语言非常熟练，所以不需要被教导如何用英语、西班牙语、印地语等等去说出一个期望中的回答或命令。也就是说，尽量不要教导用户。但如果你是想要帮助用户理解怎样推进对话，那就可以用比较直观的方式来引导。

所以，不推荐用这种表达方式：