技术驱动的新技术，要真正落地到应用层面，面向用户，就少不了设计体验。从人们真实的对话行为中去归纳原则，复用到人机交互之中。
第一章
对话式交互的概念及机制
对话式交互目前依赖于机器学习及人工智能，识别语音输入的相关问题大部分已经得到解决。
我们面临一个挑战：如何构建一种继承人类自然语音会话的用户体验模式。
1.良好对话的关键要素，包括
A.轮流（Turn-taking）：对话中基于相互来回传递的微妙信号进行轮流表达。如果会话中缺少这种有效的轮流表达，就有可能难以保持信息的同步或无法跟上对方节奏。
B.串联（Threading）：在自然语言中，对话的元素通常会被连贯的串联在一起，包括上下文以及随时间演进的对话方式。这种串联帮助我们跟进会话过程。
C.利用语言的潜在效率：人们经常会用简略口语来交流，人类可以了解其中含义。我们对话中自动补全句子之间“没被说出的”潜台词，有些表达可以不言而喻。但是与软件系统进行对话，需要弥补人类语言中那些似乎不合逻辑的，无法被计算的自然属性。
D.预估用户行为的多样性：对同样的内容，人们会根据情景上下文和对话的期许，采用不同的词汇和方式来表达。所以对话式UI应该考虑支持这种多样性，以便所有用户都能够无障碍体验。
注意：设计师不应该仅仅关注所谓的“愉悦路径（happy path）”而是要在所有场景中创造稳定的体验，即使是那些看起来像是“出错”的场景。在任何对话中，都可能出错，就像人们经常会发现和修复自己的错误一样，设计师必须也应该可以在对话的过程流中修复出现的问题。
2.理解合作式行为（cooperative behavior）
轮流表达、上下文和串联是合作式会话的组成部分，由哲学家保罗 格里斯普及的概念。他称之为合作原则（Cooperative Principle）。他的格里斯原则，诠释会话中 人们交谈应该尽可能的真诚、详实、有相关性并且清晰。
对话式UI应该遵循这些合作原则，同时也要支持有过不良对话体验的用户。
3.尽量口语化
好的UI体验不会被限制在一个固定的脚本中，也不应该像过去的触摸式屏幕交互那样强迫用户沿着单一路径去操作。对话式UI应该聚焦到发挥语言 和 表意 的强大力量，采用人们日常的语言来交流，而不时为了把用户束缚在“愉悦路径”上而去“教导”用户。另外，也要尽量避免说那些显而易见的东西，或是高高在上的语气说话。人们不会喜欢那种听起来比他们自己要聪明的设备。
4.向用户传递信息
好的UI也意味着确认用户的输入和管理用户的预期，以便获取用户的信任、传递信息。
比如在用户提出请求，在UI 体验上可以进行确认--用类似“OK”、“Sure”、Alright\Thanks\Got it等短语进行反馈，来表示接收到指令和正在聆听。随机的确认语可以让体验更加流畅自然。
进行反馈后，系统可以请求显性或隐性的确认。通过显性的确认（通常在重要的场景中，如订购机票），UI会在进行下一步之前请求用户的口头确认。而隐形确认（通常适用在低风险的场景，如播放一首歌），UI会将用户请求中的关键信息融入到自己的反馈中，来给与用户反馈，向用户传递信息，这种确认不需要用户的口头确认发。
tip：未来也许不会再有人点击下拉菜单，但人们还是仍然会指着地图、相互纠正对方的话。好的信息软件在处理信息时，会更贴近人类本来的方式，而不是电脑。
5.首先，我们要教会机器与人类对话，构建对话式UI体验方法
人类不可能在短时间内改变说话的方式，此外，人们自然而然形成的关于对话的评判标准也是不可能轻易改变。
实际应用：
A.轮流：谈话中，语法可以帮助聆听者预判出适时给与回应的时机，韵律（结合节奏、音量、音调和停顿的信号）表明何时是轮换的关键点，人们利用这些提示线索可以互相传递对话的主动权。
B.合作原则：人们需要以合作的方式表达、以获得他人的理解。基础的合作性对话原则包括人们的谈话行为需要真诚、详实、与当时场景有相关性以及清晰。
C.语义和语境：对话的含义与所处的语境密切相关。在对话中，我们没有说出来的潜台词往往也会传递出含义。如果我们没有这些谈话的预设和原则惯例在运作，我们会不得不在口头上表述很多内容，来让对方理解。
对话回合也不一定是一问一答式，从聆听者角度的表达也可以形成对话回合
以及上文提到的支持或否定的句式
如果对话UI没有产生这些对话回合的串联，那么对话就会不流畅，或不容易理解。所以串联是创造一种可以吸引用户的良好体验的重要手段，如下
E.修复：对话失败有可能是因为双方缺少共同的认知背景。而如果对话不符合合作法则，也可能会导致错误的表意。例如当一个人问：你知道谁会去么？然后简单的回答：是的。这就是不恰当不自然的表达，会使对话很难挽回修复。
即使在功能性的对话中，形式与内容也有可能是不准确，不得体或是荒谬的，需要修复才可能回到正确的轨道上。对话中任何一方都可以在对话的回合之内与外部修复这段对话，说话人通常能够发现和修复他们自己的错误。而对话UI需要能够根据交互的流程和自然属性来做出修复。
6.对话式构建UI的基础
对话是一种基于原则的协商互动行为。对话的参与方在丰富而微妙的语境下创造并认同语言的表意。理解这一点可以为对话式UI的设计提供一种理论模型。
第二章
对话设计的五个核心要点
1.创建用户画像
首先要构思好你的产品理念。例如，如果你的产品品牌期望给用户传达快速、高效的意向，那么在设计对话UI时，就需要突出直观、高效、简洁、数据驱动的特点。如果是轻松娱乐化的品牌，那么可以传达适应性、贴近、亲切的特点。有了品牌理念，就可以按照几个维度来创建对话UI的Guideline：如对话的节奏、语调、积极性、声音属性、传达的印象。将规范明确，有助于实现中有据可依。
2.突破框架去思考
定义好对话的品牌意向和基本属性，不要马上开动设计逻辑，比如用刻板的逻辑，将机器与用户的场景台词串在一起。机器与人的对话存在多种多样的可能性，所以不是直接考虑核心场景就可以了。你需要列举诸多可能存在的场景，考虑到意外状况，去撰写对话草稿。然后再梳理一个总体的逻辑，逻辑不需要细化到每个细节、对话留白、重点要围绕用户的意图展开。
3.考虑用户场景
设计对话UI需要考虑以下几个场景相关的问题：
a.用户在哪里？所处的环境是怎样的？
b.用户正在做什么？
c.用户使用的是什么设备？
e.用户的交互体验是怎么的？
f.用户要完成什么任务？目标是什么？
g.用户的期望和意图是什么？
设计师要试着去满足用户的意图，而不仅仅考虑满足功能。
4.对话不存在【出错】的概念
人的表达会存在各种各样的情况，所以不管用户说什么，不要把它当成是一个错误来处理，而是要考虑如何把这转变为一个机会，去推进更顺畅自然的沟通。
5.站在更高角度去思考
对话UI 的使用不仅仅为了好玩，所以不要只是考虑做一个小游戏，而是更多的思考如何让它真正的帮助人们创造价值。
实际应用：
构建优质对话体验主要步骤
A.选择正确的用户场景：当用户选择对话UI而不是传统UI时，通常会有意识的进行权衡。一般情况下，选择对话UI的场景是他们在户外，没时间看网站上信息，或者眼镜盯着其他地方（不能专心于任务），或者腾不出双手。适合简单、直观、不需要太复杂性的互动。
不要试图将现有的移动或PC应用直接转换为对话UI。因为对话UI有他自己的节奏和简单属性，一旦经由其他交互模式演变，就容易变得复杂。
用户场景的指导原则
a.人们可以快速做出回答的场景：指只要简单输入的内容，例如基本用户信息、地点、时间与日期。对于用户来说，已经熟知的信息很容易想起来，为后续对话节省时间。
b.快捷，同时又有强制性操作的场景：这类操作通常可以为用户节省很多时间，使用户受益。例如，在几秒内订购食品，在30分钟后送达，或是预订搭车，几分钟后出租车会出现在家门口。还有其他的便利操作，包括查找答案、快捷计算、记录或跟踪信息，以及任何可以在不中断当前任务的情况下拿出手机或找到一张纸等。
c.本身就更适合语音操作的行为场景。在某些场景下，你会期望不占用双手去完成任务，例如做饭时听菜谱，开车时做笔记。这种场景下，原本与屏幕的交互需要快捷的点击与手势，如果对话式UI 能提供比较快捷、解放双手的交互，会使操作任务更容易达成。
B.创建用户画像
在开始设计你的对话之前，首先要思考你期望它听起来如何，要给人传达怎样的感受，比如游戏需要一种奇特的语气。新闻阅读器，需要谨慎严肃的语气。
a.对人物个性的感知
人们会对[媒介]角色（例如虚拟助理）产生像对真人一样的心理反应。我们会本能的将人类个性与性格迁移到数字对话中（无论是语音还是可视的文字对话），哪怕只有短暂的几秒，也是如此。每段声音都有一个主题，我们会自然而然的在脑海中构建出这个说话者的精神意向。同样我们也会像评判一个真人那样，去评估程序设计出来的任务特性，不管这些特性是否是有意设计的。
很多人觉得，当他们与那些似乎缺乏交流能力的设备互动时，会显得愚蠢、尴尬。而人类语言具有亲密性和个性化的属性，这些决定了我们通常不会选择使用对话式UI，除非它能提供其他交流模式无法提供的益处。对话式UI的设计应当要符合人们对于一个助手角色（或谈话中担任任何角色）的心理模型。而用户研究会帮助引导人们去理解这个模型。所以首先要聚焦到为真实的人而设计，之后再让机器去跟随。
注意：人物画像可以帮助你设计、撰写UI对话，所以要尽早确定，这样就能更容易的决策出正确的用词、语法和句子结构。要记住，无论你是否打算创建用户画像，用户都将会感知到一个角色，而这一点对你的品牌至关重要，你需要将你期望的被用户感知到的体验串联起来，去有意识的进行设计，而不能把这个机会丢给偶然，听之任之。
C.撰写对话
当你确定了用户场景，并构建了用户画像，但不要冲动开始开发。你需要用铅笔和纸先构思对话。
首先，你可以写一些用户可能可能参与其中的独立或多段对话。思路参考
a.一个给予用户的【愉悦路径】，即可以用最简单的方式完成任务的路径，不会过于复杂。
b.其他完成任务的路径，能够使用户完成和【愉悦路径】同样的任务。这可能是多样化的，因为有的用户会选择一次只说一部分信息，而其他用户可能会一次把信息全说完。
c.需要进行修复调整的对话场景，例如系统无法支持或不能理解用户需求。
d.用户中途退出，以及用户完成任务后对话结束的场景。需要考虑到如何对话的结束足够明确。
e.对用户的问候语，以及引出对话操作的方式。
f.当熟悉了对话听起来的感受，就可以开始考虑它出现在屏幕上的方式。例如你可能希望语音助手说出的内容比屏幕展示更丰富。或是在必要的时候，要针对不同的设备创造不同的对话。通常情况下，这种策略是有帮助的，比如针对只提供语音体验的设备，去单纯的设计简单的语音交互，如对内容快速重新排序，而对于同时支持语音和屏幕UI交互的设备去设计完整的购物车体验。
使用口语化表达
你可以大声地把设计的对话读出来，这样可以用来检验，确保对话更自然，并能够让对话适合你所定义的用户画像特性。
D.进行测试
找一些开发团队以外的人，在没有任何提示的情况下试用几次。注意哪个对话任务完成起来有困难，或是用户与语音交互的场景中，听者的感受如何。之后收集一些主观反馈，例如他们在哪里卡住了，在什么地方感受不顺畅。当然这些信息只是你海量用户中一部分反馈，但可以帮你在产品真正上线发布之前搜集一部分有价值信息。
设计需要遵循的原则
1.保持简洁
尊重用户的时间。提供核心路径，不要阻碍用户。
2.给予用户信任
人们熟悉对话，也知道如何谈话，所以不需要告诉他们怎么说，或一字一句教他们。只需要提供最自然的沟通方式，把对话推进下去就可以。
3.考虑对话场景
对话需要符合场景，并且要能够随着用户当前需求以及所处的环境而适应变化。
4.听起来愉悦，但又不分散用户注意力
可以为对话添加人的个性化特质，但又不能太过度，以免妨碍用户完成任务。
5.要能够使新手用户感兴趣，同时也需要持续吸引专家用户
为海量用户进行设计，并不意味着只满足最低等级的需求。
6.轮流交谈
当轮到用户说话时，不要贸然强行打断。如果是问用户问题，那就不要在他们回答的时候又突然插入一些其他指令。
7.不要猜测用户的意思
提供事实信息，让用户自己做决策。
对话UI设计的注意事项
1.需要做的包括：
a.遵循基本的对话原则以及日常谈话模式（包括问候语）
b.遵守格里斯法则
c.包容多种对话口吻风格
d.通过直观的例子告诉人们可以说什么（但是不要“教导他们”）
e.直观的展示系统正在聆听的状态
f.使用随机化的表达，使对话听起来更自然
g.对于重要的请求，需要明确的显性确认，而对于低风险的任务，可以采用隐形的确认。
h.对待【出错】，可以把它转变成一种提供有价值（自然）的互动机会。
2.不可以做的包括：
a.向用户提问后，还在继续说。
b.使用刻板的对话脚本。
c.想要教导用户，让他们说安排好的台词。
d.说那些显而易见的内容。
e.用高人一等的口吻说话，或是听起来很机械的回答用户。
第三章
猜数字的对话游戏案例
1.选择正确的用户场景
游戏对于完成任务的角度来说，是低风险的，但是难点在于用户很容易陷入无聊，所以游戏的对话UI需要较高的吸引力，来满足用户愿望。
2.创建用户画像
猜数字 这个游戏的用户画像具有以下的特征：
a.乐观、愉悦、鼓舞人心。
b.有引导性、机智，能够推动游戏的进行，并鼓励用户探索。
c.不会很正式，会采用简单的语言，这样游戏能够吸引不同的用户年龄层与群体。
取一个名字，叫数字精灵，赋予它更多的个性特征，这些源自人们对魔法的认知，以及对猜数字的内在期望。
要注意，即使你没有为对话UI注入【人格】，用户在与对话交互时还是会感受到一个人的存在。
3.撰写对话
在确定了游戏的用户场景，构建了用户画像，可以准备开始构思对话框架，梳理用户旅程。
A.对话段落1：愉悦路径
描述一种典型的一个游戏回合的过程，用户猜了三次。
下一步做什么？开始开发？如果就在这里停止，开始专注这段愉悦路径对话的开发，那么游戏会非常无聊。用户有可能在游戏里循环玩上百个回合，所以我们需要有机会去添加一些趣味性，以持续地吸引用户。
B.连续玩两次的愉悦路径
完善你的用户画像
以上对话比上一段包含更多的谈话回合，所以可以观察到我们是如何将人格特性注入其中的，这样设计可以让游戏更为独特，但是同时为了覆盖这些特殊场景，也会增加一些开发成本。
C.试探性的猜测
保持让用户处于正轨上
这段对话描述了一个用户随机说出一个数字，系统提供一些线索帮助他们猜出正确答案（23）。有时用户会尝试测试系统的边界，去看看会发生什么（比如上面例子里，系统已经提示要比50更小，然而用户还是猜90）。以上对话展示了我们如何引导用户朝着最终要猜出的数字目标前进，同时又能够包容多样变化，并保持吸引力。
D.试探性的猜测
当用户在猜数字的过程中，突然问长城有多长，系统巧妙地问用户【你已经退出猜字谜游戏了么】，这样来请求确认，以推进对话。
F.对于超出时间的对话修复
上面例子中，用户长时间不回答，系统会智能的更具时长做出不同的响应判断。
E.用户连续三次猜同一个数字
掌控【不好】的输入
当用户故意连续猜三次同一样的答案（50），不顾系统的提示，而系统以比较幽默的口吻来回应。
既然产品是一个游戏，所以我们可以用有趣的方式来引导处于边缘场景的用户，这可以作为设计的一部分。这些边缘场景也值得去认真打磨构思，因为我们的目标用户就是这些容易去探索系统极限的人，所以可以更加关注如何去满足他们的需求。这个例子的错误与段落2中例子类似，在把对话实现的过程中，需要注意这些类似的场景，是否可以用对应的逻辑框架来处理，同时又能保留这种多样性。
F.退出游戏。用户放弃，游戏结束
当用户直接说出“我放弃了”，系统也能够根据这个指令，并且告诉用户正确答案。
4.进行测试
完成一组对话的撰写后，大声把他们念出来，因为你很有可能撰写对话时采用书面语言，所以通过念出每段对话能够帮你找到表达不合适的地方。
第四章 对话UI设计走查清单
问候语和结束语
1.是否告诉用户你是谁
你所提供的服务（应用页面）是需要通过什么进行唤醒，所以需要能够让用户知道当前正在与他对话的对象，明确他们正处于你的服务之中。
a.说话人是否有告诉用户他们正在和谁对话？
b.当从主APP转换到应用页面时，过程是否明确，用户是否知道当前正在和谁对话？
2.对话包含的信息要适度
根据你的产品与用户的熟悉程度，提供不同程度的问候语：
a.对于新接触到产品与品牌的用户，他们是否能够明白理解对话？一开始的问候语包含的信息是否合适？是否存在信息过量的问题？
b.对于多次访问的用户，问候语是否有重复的问题？是否可以有更简短、亲切的问候提供给他们？
3.采用合适的方式结束对话
当用户完成目标时，可以给他们机会去做其他事情，或让他们继续说话。需要注意是否提供了一个无障碍的快捷退出路径？是否为“nevermind”或“no，thanks”这类表达赋予了快捷退出的含义？
自然的对话
1.轮流机制
好的谈话者知道如何提供给对方正确的线索和暗示，让对方知道该他说话了。
a.每次当你要让对话说话时，需要给出明确的上下文提示。不要只是做一个陈述，然后直接等待用户回答或直接打开麦克风。
b.可以给用户提出一个问题，或是通过一个提示来把谈话的主动权移交给用户。问过问题后要停下来，不要继续说话。
c.听起来自然。对于每一段写出的对话，要读出来，目的是为了确保它听起来像是真实的人说出来的，用对话的思维去撰写，而不是其他媒介形式直接转换的（例如移动APP或网站）
人物画像
1.反映品牌的独特性和特色
无论你是否有意规划构思，你的用户都将会感受到一个人物的存在，所以如果还缺少品牌的人物画像定义，就需要尽快去创建了。
2.留住用户，让他们回访
要把你的对话UI人物当成一个真实的人去构思，确保你自己和用户愿意多次与他进行互动。
3.保持一致
在对话的整个过程中保持人物的一致性，避免让用户感受到突兀或困惑，以至于让他们以为在和多个不同的人在对话
对话修复/容错
1.通过预见变化来防止出错
要能够理解多种近似的替代表达方式，例如yes、yeah、sure、it does、it sure does、of course、definitely
2.提供有用的提示或生成新的问题
当用户说了一些系统不能识别理解的内容，或者他们根本不说话时，可以做出调整，询问新的问题。
3.准备好在任何时候提供帮助支持
用户可能在任何情况下请求帮助（例如询问：“我能做什么？”），所以要准备好给予提示，或是提供帮助性的对话。注意：要用明确的指令来避免让用户困惑
4.要让用户可以重复接受信息
当用户输入像“什么”、“请重复”、“再说一遍”之类的短句，需要能够识别并给出对应的响应
5.对于任务完成失败的状况给予优雅的处理方式
如果用户没有给予回答，或是在尝试了两到三次，都没办法识别，那么就需要用恰当的语句来退出当前任务。
第五章
用户对话中的自然惯例
对话不仅是简单的信息互通。在对话中，我们会分享各自对话题的自然假设。我们知道谈话应该如何展开。我们也会对参与者谈话贡献的质量与数量有所期许。此外我们会保持礼貌，遵守一致性及其他交谈的自然法则。每个人都本能知晓如何在表面意思下探寻更深层次的含义。
合作法则，人们为了相互理解，需要合作式的谈话。在假定谈话存在潜在的合作关系时，我们可以忽略大量信息，提升谈话效率。通常在问[你是否...]时，实际上并不只是期望对方回答是或否，而是代表一种间接礼貌的询问更多细节的方式。
格里斯法则，用来定义合作式谈话的基础原则
a.质量：只说真实的内容
b.数量：恰到好处，不多不少
c.相关：只说和主题有关的内容
d.态度：简单直接，避免模棱两可
总之，人们需要在对话中真诚，提供有价值的信息，紧扣主题并且保持简洁清晰。这也是对话UI要遵循的原则。
1.逻辑和准确性不是万能法则
口语表达通常会呈现的无逻辑和不精确。例：他一共有5个孩子，那么“他有2个孩子”在逻辑上也是对的。但这个表达在谈话中就会有误导性，因为没有交代清楚上下文背景，例如可以补充“他的另外三个孩子...”。
另外有时会人们会故意打破合作原则。在某些场景下，他们只是尝试让自己表现的礼貌。例：当问及某人工作面试中表现，他们可能为了避免给出负面答案，会说“他的领带不错”。
对话UI必须要去适应、符合人们这些自然的谈话法则。
2.语法识别和对话修复/纠错密不可分的
UI设计需要预见[出错]，并且要了解语义识别（在对话中人们的回答可能出现的全部情况）是如何构建出来的。例：机票预订中的确认场景
如果答案是肯定的，人们很可能给出一个简短的回答，如yes、yeah、correct、that's right等等，如果答案是否定的，人们通常不会只说no，而是可能说“不，不是Geneva，我要去Jamaica”或者“不是13号，是30号”或者是只回答他们听到的部分，例如“时间对了，日期不对”。
所以如果由于技术限制，你的UI还不能够达到这样职能的交流程度，那么也就不应该让用户误以为系统可以达到。这种情况下，对话的修复就要有一定的限制性，例如：我理解的对吗，这样的表达，只需要用户回答是否。也就是说让用户了解到UI的局限，可以预先规避表达不自然的问题。
当UI没被设计好，不能理解正确、有质量的信息或附加信息，那么就很可能把一些自然的合作化的口头表达误以为是没有合作性的。因此，当人们的表现不符合系统预期时，这种语言误解会不同程度的展现为粗暴、机械化的错误提示，例如“这个回答无效”，或是表现出一种假装关心的语气，像是“对不起，我没听明白这个回答”。
3.用户多样化的回答是机会，不是“错误”
要考虑如何设计问题，能够预先判断出需要修复的场景，以便让对话保持在正轨上，同时不会引起用户不适或分散用户的注意力。事实上，这样的场景有机会转化为另一种有价值的对话。
目前为止，用户会倾向于紧紧围绕对话的字面意思去互动，而不会提供一些额外信息，尽量避免所谓的“自然的合作互动”以免引起机器的理解错误。因为他们过去曾经在语音识别方面有过糟糕的体验，UI设计师需要尽量的让这些用户感到舒服。例如，在以下场景中，对话UI需要搜集日期和时间数据，他需要用一种通用的，并且同时适合搜集这两种信息的提示方式：
然而，有的用户更愿意试探，或每次提供较少的信息，此时UI不应该把这种情况定位为出错，而是应该去做出简单的调整和适应：
上面的过程并没有把对话UI的自然、合作互动、适应性的这些潜在逻辑暴露给用户。用户可能在根本没有提示的前提下用简单的指令就完成了整个任务，也就是给出一两条信息，由UI自己把那些潜在缺失的、用户没有说出的信息补充完整。比如“把闹钟设到周一早晨6点”，“在6小时后叫醒我”，“把闹钟设到7点”。采用“好的，什么时候？”这种提示可以激发用户把脑海中想到的日期、时间或者两者直接表达出来，这种提示也是符合合作互动原则的。
4.尽量不要教导用户
好的对话UI应该能够利用语言和表意的内在力量，而不是去展现机器处理指令的能力。它需要利用好人们已知的，也是最熟悉的沟通系统-日常对话。不去教导用户。如果你想要帮助用户理解怎样推进对话，可以用比较直观的方式来引导。不推荐用“如果要继续到下一个，可以说下一个”可以用更加直观的引导。如：“您是要重复、回答、还是去到下一个”
5.体验自然的对话UI要经受住时间的考验和用户的认可
合作原则强调了我们基于认知共享的高效的沟通能力，利用好这种自然对话中的惯例原则，用户会本能的知道如何操作并且感觉舒服。
6.在创建对话UI需要注意：
a.理解语义识别和对错误的修复
b.适应用户的不同说话风格
c.让用户能够依据直觉就知道要说什么
第六章
开启口语表达的力量
对话UI的一个优势是人们本来就知道如何去对话。好的对话UI界面应该是符合用户直觉的，不需要教育用户操作，不像视觉UI那样，要教导用户按钮或手机触摸按键的意思。然而有时候，在用户请求帮助或者不确定如何进行下一步（尤其是新用户）的时候，我们还是不得不让用户知道要说什么。
构建对话UI 的注意点，可以通过利用口语表达的那种符合直觉的惯例来创建更好的对话体验。
1.围绕已获取的信息进行沟通交流
如果用户提出一个疑问，或是想知道如何完成某个任务或操作，对话UI应该围绕着系统已获取到的信息进行沟通交流，这样人们就能理解听到的内容。增强对对话系统的信任，也就是所谓的[隐形确认]（implicit confirmations）
用户的目的可能很简单，例如：
也可能是为了进一步的答案，例如：
需要注意，由于语音UI是线性，用户在交互中不能跳跃，必须逐句的听。而屏幕就可以每次给用户呈现一个书面的视觉反馈，甚至同时展示配图，不像语音，只是说“米开朗基罗，艺术家”。语音UI需要向用户传达一种信息，就是他们听到的内容就是他们所要求的，更进一步讲，更多附带的信息需要放在最后去传达，这也被成为【末尾焦点】end-focus法则。
2.用具体例子让用户知道要说什么、怎么说
对话UI还应该提供给人们一些可选择的方式，让他们能够表达请求，或是用例子来说明，例如：
3.要有信息含量，哪些显而易见的就不用说了
没有价值的信息会让你的说话角色听起来很丧、没深度。用户不会喜欢低估他们智力的设备。例如让用户提出问题：“我怎样能够接收到新闻？”回复“去说接收新闻”这样的回答是没有帮助意义的。即使换一个词说“听新闻”效果也一样。
同一个用户可能已经知道或尝试过某些方法来查找信息，而人们更愿意去探索他们还可以做什么。对话UI可以通过一些直观的引导，帮助这些用户来探索更多可能性，例如：
UI对话应该在用户还没有明确要求帮助的时候，就让用户知道要说什么。而这样的引导也需要避免冗长啰嗦。例如：
4.让用户信任，为需要帮助的用户提供额外的引导。
对话UI不应该试图去教导用户要说什么，以此来避免用户偏离【愉悦路径】。对于没有遇到困难的用户来说，引导是多余的。但是在后退和修复场景中，就需要进行一些提示，尤其是当有用户似乎被卡住的时候，例如：
在对话中，问完问题，没等用户回答，就突然又继续说话，这是不好的设计，而且这种情况下，用户要么必须等待漫长的初始化过程，要么就会去打断对话（如果有用的话），而这样也会使用户成为不善交谈的被动参与者。
总结和建议
在构建对话体验时，要记住以下几点：
a.围绕已获取的信息进行沟通交流。
b.用具体例子让用户知道要说什么。
c.避免说废话.
d.只在需要的时候才提供引导。
第七章
通过确认和应答给予用户信心
对于界面设计师来说，一个基本的挑战就是判断用户何时遇到了问题。而避免问题的第一步就是让用户知道系统正处在聆听状态。有两种方式来达成：确认和应答，
确认就是让用户知道系统正确理解了他们的问题、指令或回答。而应答是指一些词语或短句（像是OK或Aright），用来表明系统已经获取到信息。
1.为什么需要确认
确认可以给予用户更多信心，如果缺少确认机制，那么就会存在系统误解用户输入，错误引导用户的风险。例如用户提问：“上海天气怎么样”却错误的得到北京的天气预报。
这种出错风险的严重程度取决于具体的操作内容，聪明的设计师应该知道如何根据不同的场景提供对应的确认，从而避免错误的引导用户。通常设计师需要在隐性确认和显性确认两种方式中进行选择。
A.显性确认
显性确认中，系统会把主动权交给用户。在进行下一步操作之前，像用户进行口头确认，例如：
对于有多条内容，但都是与同一个操作有关，也可以同时一起进行确认：
显性确认通常适合的应用场景包括：
a.比较难撤销的操作
b.对于购买者的消费协议或法律法规的口头确认（例如在付款之前的最后确认）
c.系统性能不够好
B.隐性确认
这种确认是隐形的，也就是说系统会重复关键信息，这样用户就可以快速的知道系统已经识别到了这些信息。
重复的信息不一定是特别精确，例如：
隐性确认适合系统对获取信息的识别准确度较高，出错的可能性较低的场景中。这种确认的优势是效率比较高，而劣势是一旦出错，用户可能不知道该怎么样去纠正。遵守下面的几条原则，可以帮你更好的进行决策。
a.不要直接让用户退出
很多对话UI 在隐性确认中，会遵循一种【快速回退】策略（类似隐性回复后提供撤销？）。例如，当确认的信息错误的时，让用户直接说【go back】。但并不推荐这种方式，建议根据合作对话原则，根据用户具体场景，自动组织语言，适应对应的情况，来引导用户回到正确的路径上。如果不得不提供【out】的直接退出路径，也需要同显性的方式来确认。
b.有些场景中不需要提供确认。例如打开闪光灯，就可以立即打开。对于这种结果可以理解感知的操作，只要直接执行就好了。（也是一种隐性操作）
当已经决定好采用那种确认的策略，接下来就可以考虑准确度，以及出错时进行纠正的用户成本问题（例如用户付出的钱、时间以及情绪投入的成本）。
2.关于应答
应答是一些像是Okay、Sure、Thanks、Got it这样的短语，可以确保让用户知道他们说的话已经被系统获取到，以及让对话流畅自然。
应答用于在话题更换前表示接受、拒绝、二次确认、更正。注意对重复的信息需要谨慎应答，避免滥用。
好的对话 UI能够组成自然的轮换发言，它可以传达出对说话人的关注，并表现出随时待命，根据用户需要来推进对话。简单的应答可以让用户知道系统已经接受了上一轮的对话信息。应答传递出系统正在追随着用户，并且反过来也可以向用户传递产品、品牌已经公司价值观。缺少应答，用户可能会质疑刚刚说的话，系统有没有听懂。对话UI可以在进行下一步操作前，通过随机的确认（如Sure,for what time？）来消除用户的这种质疑。应答也可以结合其他一些连接词（Next、And、So、Actually），把整个对话更好的连接在一起。
注意事项：应答需要符合场景、品牌、任务类型和对话细节（像是用户是否处于正确无误的路径上，或是提出的问题是否已经被识别理解）。
在真实的对话中，我们经常会听到如【Alright then】、【You got it】、【Doh】之类的应答。但是在对话UI中，需要考虑这些应答是否能够符合你的角色画像和要传达的体验。
应答需要谨慎克制的使用，不是每个句子都会有应答做开头。当对话已经策划好，写好草稿，就能比较容易的确定出要添加应答的位置和数量了。
直接明确重复用户的请求，也是一种应答。例如【关闭我的麦克风】，【麦克风已关闭】，这种方式可以让用户明确知道系统已获取到他们的请求。但是，你还是可以通过应答来传递轻松自然的氛围。
要避免应答单调、套路化的方式之一就是随机机制。为了保持新鲜感和多样性，可以提供一个特殊的随机应答列表，也可以对同一个词变化声调，产生多种表达。
3.总结：使用确认和应答来构建流畅的对话
在对话UI中，确认和应答是最重要的技巧之一。它们把一系列相关独立的、机械化的对话串成一个自然流程的整体。此外，也能够结合场景，促进对话的节奏感与效率，让对话更容易理解，让用户对当前的互动已经整个智能对话技术更加信任。
建议：
a.对于高风险的请求，使用显性确认，使信息更清楚明确。
b.对于简单的请求，使用隐性确认，以提升对话效率。
c.不要直接让用户退出，避免使用【go back命令策略】
d.利用应答让用户知道系统已经接收识别了来自他们的信息，
e.利用随机的应答来避免单调和套路化。
第八章 对话中不存在“错误”
对话UI设计中难度最大也最容易被忽略的一点，就是对于【无法匹配】（系统无法识别用户的话）和【没有输入】（用户没有说话）的状态中进行复原。
我们经常会把这些状态错误的理解为一种边缘状态，而只是做一些简单的处理应对。例如向用户道歉，把同样的问题再问一遍，或是用过于正规、机械的方式，使对话呆板，甚至更严重的，让用户产生受挫感。当用户听到【我没听懂那句话】，或是【抱歉我没理解】，他们会理解为【我什么都听不懂】，或是【这个技术不能运行】。所以无论是对于用户体验，还是对于app本身要取得成果，对【错误】的修复都极其重要。
以下内容概述了如何把【错误】转化为对话UI的一部分
A.不要把技术上的【出错】当做用户的错误
B.对于不同类型的【出错】提供对应适合的处理方式
C.通过提供帮助来避免出错
D.要知道在什么情况下放弃
E.使完成任务的路径更强，来掩盖错误。
1.把出错看成是机会
任何请求都是有目的，用户总是希望完成某些任务，即使没有明确说出来。用新的方式处理错误，把它们当做是对话中的转折点，通过对出错处理来建立和营造与用户有效互动的机会，来建立信任。
理解人人都会犯错，犹豫和错误纠正都是正常的。人与人之间可以通过本能实时互动相互纠正，机器要避免超时问题和识别错误，唯一的方式就是不要把这些问题当成是用户输入内容的一部分，而非 [错误] 。在对话开始时，需要采取一些提示机制（参照上一章的通过确认和应答给予用户信心），之后需要通过一些策略来规避这些问题的出现，制定一种能够适应不同场景和情况的应对策略。
2.要知道什么会导致出错
要使语音对话能够顺利进行，需要很多条件很好的结合在一起，才能达成，包括语言信号处理、语言分析、音频数据传输、软件触发等。所有机制要能够合理的获取分析用户的输入，并提供一个对应的输出。一旦用户的输入不符合预设，就会引发【出错】，这个时候就要开始注意了。
A.区分机器逻辑和用户的真实互动情景
机器的触发与相应，所处的环境条件与用户视角所感受到的完全不同的。譬如噪音、中断、话说到一半被打断，以及选择太多，要认识到用户在真实交互的过程中，会遇到很多问题，可能和程序预设的逻辑存在非常多的差异。
从机器角度来看，有四种常见的情况会导致出错：
a.没有获取到任何输入。可能因为确实没有，或是系统没有检测到。结果造成了系统获取信息超时。（对话中的网络原因）
b.虽然获取到信息，但因为背景噪音或多个用户说话而不能识别或解析。
c.识别了用户的输入信息，但系统不知道如何去回应处理。错误的解析信息，无法正确的处理需求。
d.错误的识别了用户的输入信息，谈话会继续向错误的方向继续，用户被误导。这种情况可能是最坏的。
解决这些问题的方法
第一步先把问题简单归类，基本归为以下两种：
a.输入缺失（no-input error）：系统未获取到用户输入
b.无法匹配（no-math error）：获取到输入，但是系统无法正确的分析处理
这是用程序化的方式来入手解决问题，接下来需要用更有策略的方式
3.设计处理错误的策略
使用一些工具，通过代码和逻辑来实现这些策略，例如API、AI
A.应对错误的有效的提示策略
a.无内容的快捷重复提示
b.有内容的快捷重复提示
c.重复询问
d.更改问题
e.回答一个没有明说的请求
f.积极主动询问
B.及时提供帮助
修复问题很重要的一点就是要准备好去帮助用户，当他们出现困惑，没有听懂问题，或是不知道该说什么的时候。设定好一些提示，采用预防机制。此外也需要准备好去应对用户的一些寻求帮助的要求，可能是想要重新理解机器发出的内容，用户可能会说“解释一下”“帮助”“我不知道”之类
C.知道合适的退出时机
另一种防止用户受挫的策略，就是提供一种让用户可以轻松结束对话的方式。他们想要结束可能会有多种原因，毕竟生活充满了多种多样的情况。为用户的离开做准备是非常关键且有技巧的。通过这样的方式，也可以让用户知道如何再回来，并接着上一次的服务继续。
a.系统主动退出的例子
b.用户主动退出的例子
D.提供规避错误的路径
如果用户没有直面出错，那么就会感觉到对话还在顺利进行，这样即使后续再次面临出错，感受也相对平和。
a.始终保持人性化的表达：提供多样性，可以让对话听起来更自然吸引人。这种原则不仅是针对提示，而要贯穿整个对话始终。应该要使用随机的，多样化的提问内容和回答。以下是一些策略，来帮助建立人性化体验
提供一个用于提示的文案列表，随机的从这个列表中选择进行提示，通过排列组合可以创建大量不同的提示。在提示中，把固定的文字用占位符来替代，当做一种变量，在正式运行时，就可以产生成多变的内容，例如【welcome，...】。要记录曾使用过的提示语，在下一次随机生成提示时，不要用之前用过的。
b.努力获取用户的信任
对用户可能随意尝试输入的一些对系统如何回应的试探，做一些准备。新用户会试探下系统能否为他们提供期望的信息。
c.积极主动的协助用户达成目标
可以提示用户任务完成进度，处于何处，以及回到主路径的方式。有时可能也需要主动地把控局面，根据你程序的角色画像以及自信的程度，去推动对话继续进行。