Google对话式UI设计手册之三——像你的用户一样有协作精神
by Xu Wenhao
在前不久，Google 基于 Creative Common Attribution 授权 发布了他们的对话式UI设计手册。BotHub.AI 作为 Facebook Messenger List DevelopmentProvider 将手册逐一翻译成了中文，希望能够进一步推动 Chatbot 在设计，使用上的发展。我们会在之后的一段时间逐步将这些内容校对后发布出来。
如果您希望进一步了解如何构建 Chatbot，欢迎来信到 [email protected] 以及访问我们的 官方网站 并订阅我们的邮件列表。
像你的用户一样有协作精神
对话远不只是简单的信息交换。
在对话中，我们在同一个话题下分享自然的假设。我们知道一个对话是如何进展下去的。我们对于每个人在其中的贡献的数量和质量都有所预期。在这之上，我们还会加上礼貌，一致性，以及其他对话中自然而然的规则。此外，每个人本能地知道当表面的含义是不清楚或者夸张的时候要予以忽略，而去寻求深层次的，非字面含义的诠释。当我们都自然地这样做的时候，对话事实上是一个相当复杂的过程。
语言哲学家 Paul Grice 说过人们必须抱着合作的态度说话才能被理解。他称其为协作原则。当假设有一个协作的暗流时，我们可以省略很多信息，这使得对话更加高效了。询问“你是否…?” 并不意味着 “回答 是 或者 不是”。相反，这通常是在间接而礼貌地提出更加具体的内容。
他还创造了 Grice 缄言 来定义了有协作精神的对话的基本规则：
- 质量 —— 只说真话
- 数量 —— 别比需要的更多或者更少信息
- 相关性 —— 只说哪些和话题有关的事情
- 礼貌 —— 简要说明，避免歧义和晦涩
换句话说，人们必须像情境所要求地尽可能地真诚，有信息量，有相关性以及清楚。这也使得用户界面高效所需要的东西
并不总是由逻辑和精确性支配对话
我们口头的捷径揭示了对话常常不合乎逻辑，以及数学。比如“Sue有两个孩子”，当Sue有五个孩子的时候也是在技术和逻辑层面正确的。但是这个陈述在对话中是有误导性的，因为它缺失了上下文信息（在这个示例中，Sue还有其他三个孩子）。
此外，人们有时候会故意地不配合。在某些情况下，他们只想要显得友好或者礼貌。例如，当被问及一个候选人在求职面试中表现得怎么样的时候，他们有时候会用“他今天戴的领带很漂亮”来规避给出负面的回复。
一个UI也必须适应所有这些规则，因为大部分人都会不加思索地遵从这些规则。
识别语法表现和修复（错误）提示携手并进
UI设计师也需要有能力预测特定类型的人类的“错误”，以及一个识别语法（任何一个人可能在对话中的某一点可能回答的内容）是如何构建的。
Alright, from Atlanta to Geneva on September 13th at 6 p.m.
Is that Right
如果答案是肯定的，人们倾向于给出一个简短的答案——“Yes”，“Yeah”, “Correct”, “That’s right”等等。但是如果答案是否定的，他们通常不会只是说“no”。取而代之，他们很有协作精神，他们会通过“No, not Geneva, I said ‘Jamaica’”或者“No, not the 13th, the 30th, three zero”这样的回复来将对话向前推进。或者他们可能会仅仅回复部分他们听到的内容，“You got the time right, but the date’s wrong.”。
如果技术的局限性使得你的UI不能够适应这些协作交流，对话中就不应当为你的用户设置系统能够做到这些的预期。如果是这样的话，在第一级的修复对话策略就会限制在一些不自然的提示，比如“So, did I get that right? Just say ‘yes’ or ‘no’” —— 这立刻给了用户距离感，并且将UI下的局限性和对话的人工本质暴露了出来，从而破坏了自然对话的潜力。
当一个UI没有设计成接受正确的，合格的，或者增加信息的回复的时候，它可能会错误地将这些自然的协作对话行为视作是不合作的行为。这些语言上的误解，会以一些所谓的“错误”提示用唐突而机械的语气展示出来，就好像一个行为失当的人一样（“That was not a valid response.”）,或者像是一种虚假的关心，好像一个缓慢的学习者在说话（“I’m sorry. I did not understand the response I heard.”）
多变的用户回复是机会，而不是“错误”
想想一个问题如何可以在保持对话正常而不是不舒服或者让人分心的情况下，设计成使用 修复提示的。事实上，这样一个实例可以成为对话中另一个有意义的话轮的机会。
在现在，因为有些人过去对于语音识别有着糟糕的体验 —— 常常和糟糕的UI设计混在一起 —— 他们可能会采取字面提示，而不是提供“自然而协作”的额外信息来避免识别错误。UI设计也应该充分地适应这些用户。
我们拿一个UI需要收集日期和时间的场景来看。它应该开始于一个对两个都有用的通用的提示：
User: Set an alarm.
UI: Okay, for when?
User: Tuesday at 6 a.m.
UI: Done. Your alarm’s set for Tuesday at 6 a.m.
但是，既然一个更加踌躇的，或者提供更少信息的用户可能将信息分开来提供，UI不能讲这个当成一个错误，而是应该简单地适应它：
User: Set an alarm.
UI: Alright, for when?
User: Tuesday.
UI: And the time?
User: 6 a.m.
UI: There! Your alarm’s set for Tuesday at 6 a.m.
上面的交流没有暴露出需要使得UI有协作精神，以及为其他可能的用户回复的隐含逻辑。对于给了部分或者全部的数据，用户可能可以不需要提示，通过一个命令来完成整个步骤，而留由UI来解释缺失的信息（”Set an alarm for 6 a.m. Monday morning,” “Wake me up in 6 hours,” or “Set an alarm for 7 o’clock,”）—— 所有这些元素都是用户所没有说出来的。
“Alright, When”这个提示有助于脑海中只考虑了一个日子或者一个时间的人，能够像两个都想好的人一样给出简单的回答。这类提示充分促进了 协作原则。
就像说笑话一样 —— 如果需要解释，你就输了
一个好的UI专注在语言和意图直觉的力量上，而不是展现一个电脑可以如何设计成接收”“命令”。它利用人们最早学会和最了解的交流系统：每天的对话。我们已经熟练掌握了我们自己的语言，所以我们无需教导，就知道如何用简单的英语（或者西班牙语，菲律宾语或印地语）来表达预期的回应或者命令。换句话说：避免使用命名，如果你需要帮助人们理解他们可以说什么来推动对话，请使用直观的东西。
所以，相较于：
To hear the message again, say ‘Repeat;’ to reply it, say ‘Reply;’ and to move on to the next one, say ‘Next.’
想想更直观的：
Repeat, reply, or go on the next one?
自然对话是经由时间检验和用户认可的
协作原则强调了我们基于有力的共同知识为基础建立起来的，通过社会适当的方法进行有效沟通的能力。通过利用自然对话的惯例而不是忽视它们，我们可以制作出用户本能知道如何使用和觉得舒服的更好的UI。
最佳实践
在你创建一个UI的时候请记住下面这些指导方针：
- 理解识别语法和修复（错误）提示
- 适应变化多端的用户说话风格
- 让人们直观地知道它们可以说什么