2.1 移动设备与IVR系统设计
让用户知道自己是在用机器为自己服务可以是他们放心大胆的询问业务问题，不用担心如果询问次数过多，是否会使人工不耐烦，长期以往，就会习惯这种解决问题的模式，一旦取消，人们会不适应
增加语音识别率除了在技术上做文章，也可以通过推测用户可能意图，在问题中做询问，减少用户需要回应的字数，在概率上可以增加识别效果，也就是将前期工作（分类，聚类，预测）做好，对于第一次使用的用户，对所有相应次数的用户的意图做统计分析，对长时间使用产品的老用户，对用户自身的生活习惯统计分析辅助询问，最好让软件（用户专属云端）在各种硬件上互通，这样对收集数据更有利
移动手机助手有两个挑战：一个是是否需要虚拟角色，一个是如何界定什么时候允许用户说话。而且对于多个选项展示的复杂结果，需要界面配合更有助于用户获取信息，如果没有见面，对于这种情况，最好询问用户是否需要将多个结果（较长答案依次读出），有时候让用户对机器行为多一些控制，比让他们感觉服务不周，有迷茫感更好
虽然有一些产品用语音解决问题，但是也会设计一个配套的APP，这样一方面有助于了解及其对自己的生活情况了解到什么程度，甚至可以自己添加一些信息，另一方面用多模态的服务方式，更有助于交互的流畅性，用户也会更从容，因为在纯语音的交流中，用户必须不断的与系统进行交互，很少有机会暂停系统，所以如何解决主动询问与沉默尴尬的界限也很重要。而且对于垂直场景的应用，APP可以让任务完成更有完整性，不要为了应用AI而应用，而要和业务需求紧密结合，从需求出发
视觉与语音要协同设计，如果两种交互方式都要应用，那么从一开始就要配合设计
2.2对话式设计
要设计一轮以上的交互，就要思考用户接下来可能会做什么（或者通过数据训练，对用户常见行为践行分类预测），不要强迫用户展开新一轮对话，而是去尝试了解用户的意图并允许用户继续交谈，此外有必要对用户近期所说的话保留历史记录，否则，与一个永远不能记住上一轮或者上几轮信息内容的机器交谈，是疲惫且无益的
对于上下文理解中，指代是很重要的，对于特殊命令词语要深度剖析，比如：“去北京坐什么比较便宜”“火车，价格XXX”，“那里的天气怎么样”，那里就要知道是在指代北京，而如果没有代词，则要有记忆功能，明确主语在指谁，比如：“北京哪里比较好玩”，“故宫”，“现在人多么”没有代词，但是要自行补充主语，是指前文的故宫。
让用户决定一次对话要持续多久，主动权会使他们聊起来更舒服，减小压力和防备心
2.3设定用户期望
“如果你不能理解答案，就不要提问”
意思是，如果你提出的问题可能得到的回答，机器会理解不了，或者用户回答的答案是不可控的，不能穷尽的，那么就不要轻易提问
必须早期就设定用户期望，让用户知道自己已经完成了什么，就会获得一次成就感和满足感，要利用好用户在使用过程中增加教学点的机会，比如：用户完成了某一件事，你可以说：“太棒了，要不要试试这个”（对待孩子也许更适合）
工程师认为，有时候为了减少延迟，机器会对用户的请求做快速恢复，但是可能事情还并没有完成，比如设置闹钟，提醒，发送消息，购买商品等，要在真正完成后告诉用户“好了，XXX已成功”让用户更确认目前的状况
如果你设置了可以完成某项任务的预期，请务必考虑与之相关的任务，比如：帮助用户设置了闹钟，那就要想到用户可能会取消闹钟，改变时间，换铃声等等（还是要从场景本身出发，考虑会更全面）
可发现性也是设计用户预期的手段之一，比如：用户使用手机可能会说，“一二三”，“茄子”，等等，相机就会自动拍照，又或者有一天突然对音箱说：“XXX，你在运行么”，“一切正常”用语音的方式检查故障，会比其他方式对用户来说更方便（还有什么例子）
当询问用户的个人信息时，要给出示例，不是说明，比如：“请说出你的出生日期，类似：xxx年xx月xx日”，而不是年月日
2.4 设计工具（在交付一个项目时，应该准备的，还包括后来的提示列表）
1 示例对话：对于常见场景，写出各场景下的示例对话，并写出异常情况下的示例对话，完成后，和另一个人大声朗读出来，（也可用TTS将设计的对话用机器读出来，成本会更高，但更好用）知道设计效果如何，对于用户可能的问题，不要只设计一个答案，会显得呆板
2 视觉原型，让对话流程可视化，让用户体验的设计更完整
3 流程图，展示可能发生的路径，要包括用户在使用系统中所有可能存在的分支，在图表中不用列出用户肯能说的每一个短语，但是要把他们适当的分组，如：听音乐的，洗澡，刚起床，刚回家，要睡觉等等
2.5 确认策略
如果过于确认刚才用户恢复了什么，会使用户反感，所以适当把握好用户能感觉到自己是被理解的，也让他们知道机器什么时候没能理解他们说的话的尺度，比如：用户说“是的”，“你说了是的，对吗”，在或者用户用语音预订饮料，机器：“请仔细听，如果有你想要喝的，请打断我，我们有：美年达，雪碧，康师傅矿泉水... ...”，“雪碧”，“再跟你确认一遍，你要了雪碧，对吗”，这就让用户觉得我为什么不直接在手机界面点击一下，问题早就解决了，除非是，用户实在不能将手腾出来的场景，（所以不要急于向用户推送都有什么，先问他们需要什么，如果得到明确结果，直接预定，如果没有，比如：“你这里都有什么？”“都可以”，再向他们推荐销量靠前的几种商品，还要注意的是，最好告诉他们推荐给他们的理由，有助于让他们做出购买决策，同时也要考虑用户可能会回复的可能情况：“有便宜的么”“有含糖量低的么”）
再决定VUI的确认策略时，可以参考以下几点：
错误的结果是什么（转错账，治错病，这都是不能接受的）
系统将以什么形式反馈（音频提示？视觉提示？如亮灯）
会有一小块屏幕么？（手表，手机）
以什么形式来确认是最符合当下场景和硬件的
（根据智能手表，耳机，语音助手，音箱，自行设计在各种情况下的确认策略）
智能硬件其实一直在听，你要做的是让他知道你想和他对话，还有让用户知道机器已经在听，比如 ：提示音，界面，语句，震动等等，本质还是在让彼此知道自己处于什么状况
语音是单通道的，所以机器和人在表达上让对方明白与否很明显的就显现出来，要根据置信度阈值将对表达的理解情况分为显性确认“你要设置一个下午两点的闹钟，是吗”和隐性确认“以为你设置好下午两点的闹钟，到时会叫你”，根据不同的置信度阈值设置不同的回复，一般为45%~80%，如果大于80%，回复“好的，以为您XXX”，如果45%~79%,“你是希望XXX是么”，如果小于45%，“对不起，没有听清，请再说一遍”
对于搜索类，如果置信度较高，可直接说答案，如果不超过80%，还是用隐性回答，这种错误后果较低，“猎豹是陆地最快的动物”，对于服务类，至少还是用隐性回答，更为保险，对于指令类，像“打开灯”如果中间有延迟，用回复先让用户知道自己的语音被识别了，对于这种让用户知道自己已经完成了什么，处于什么样的状况时，可以用简短的，有识别度的声音，比如在购买完成，预定完成，设置完成，正在倾听，即将关机等，或者在智能驾驶中，遇到红灯，前方障碍等都可加以短暂提示音
在开放域的聊天中，通用确认是很好的方式，对于用户回复的程度，正负面做分类，给予相应的回复，以确认你听明白了他们再说什么，“听到这个消息真为你开心”，或适当加入，嗯，然后呢，也很符合人们对话的语言习惯，这样会使对话更丰富（对于每一种可能的情况，都要设置一组回复与之对应）
视觉确认如果可以，要好好利用，一是可以让用户直观地知道自己和机器所处的状况，比如：自己刚做的选择是否被机器听懂，也有助于他们记住机器表达的信息，日后也可再次确认，回顾，特别是回复较长的信息
2.6 命令-控制模式和对话模式
对于命令-控制模式，让机器和人彼此知道对方和自己都处于什么状态是最重要的，即要让机器知道人要对他发出指令，人知道机器已经开始听自己的指令，机器要知道什么时候人已经发出指令完毕，要让人知道机器是否识别，是否理解，是否开始执行，要多久执行完毕等。
用户必须给出明确的指示，告诉系统自己要开始说话，比如，唤醒词，按键，图标等，这和对一个人说话一样，你要对谁说话，先要叫名字，或者眼神，或者动作，或者一个语气词等等，但是如果你的机器在感知能力上“有障碍”，那么频繁的按键和唤醒会使召唤它的人感觉不自然，特别是对用户的命令不识别或者不理解时，反复唤醒带来的麻烦会更为突出。可以理解之所以要每一次都有这样一个流程，而不是机器在说完之后等待用户接着说下文，是因为担心将用户的非指令谈话识别成了指令，所以对于不同的场景要用不同的关闭系统阈值，不能一概而论，比如在购物订票等场景，等流程完成之后，再关闭系统，对于媒体类场景，完成指令，可关闭系统，对于控制家电，软件等现在可以做到任务执行完再关闭，对于没能识别和没能理解的场景，要给用户重复一遍的机会，不要直接关掉，同时对于识别不出来，要在增加识别率和麦克风质量上做文章，也可以在用户的表达方式上做引导，对于总是不理解用户的话，要增加用户的表达方式（口音，说法），也要在表达上做引导。还有给用户多种方式结合的唤醒方式，防止多次唤醒失败的失望感。还有一种，为了使用户发出指令更加自然，也可以将指令和唤醒词同时说出，这样过程更流畅，也更接近人与人之间的交流方式。
让人知道机器已经通过某种方式准备听自己的指令了，也是有必要的，现有的方法，比如最常见的还是用语言询问：“怎么了”，“什么事”，也有非语言类语音，“bi”“bo”等等，或者用视觉反馈（光亮，屏幕，虚拟人物动作等），个人认为用语言最为回应更自然一些。
当用户输出指令输出指令完毕，也要让机器知道此刻的状况，为了避免用户因为犹豫产生的静音，使得机器等待时间太短而抢话，和人已经说完有一段时间，还没有等到机器执行，而让他们不知道自己说的机器是否听见，或者听到不想对机器说的话，所以时间的把握很重要，一般为10S（一般人在思考该如何表达下一句时，要思考几秒的时间，如果在5S左右，还是容易造成用户刚要说话，机器开始执行的情况，所以要更长一些），但是机器等待用户回复信息和发出指令时，只要还没说话，就会一直等待，要区分开两种情况。
对于对话模式，不要强迫机器每次都告诉用户自己准备要开始说话了，应该是自然的对话技巧进行话轮转换，常见的话轮转换提示有四种：问一个问题，“我想看电影”“不如你直接告诉我你想看的电影的名字吧”，在可以的情况下，尽量掌握话语的主动权，让用户发过来回答你的问题，减少答案让用户不满意的几率，当然也要视情况而定
不要再不合适的情况下进行话轮转换，比如，用户已经提出需求，在没有问题询问的情况下，就不要打开麦克风强迫用户进行下一轮说话
人们在话轮转换时，有时不容易识别，比如像“嗯嗯... ...”，有时代表着需要对方接着说下文，有时只是代表认同你说的观点，或者说我在听，中间随意的插入一下而已，所以要想办法处理这种类似情况，可以从场景出发，规避一些场景，可以从交互出发，规避这种回复，或者根据上下文判断，或者随时允许用户打断
可以加入一些微妙的回复，无论是在特定领域还是通用领域，都可能发生一些不经意的用户表达“谢谢”“你真厉害”“原来是这样”，对于这些表达如果也能配好相应的回复，会给用户以适当的惊喜（可以在设计中建立一个针对所有这些表达的回复场景）
不要可以模仿人们交流而加入一些反问句，“你觉得呢”“听听你的看法”“真的么”，一方面用户不一定会接受这种回复方式，让他觉得尴尬，不自然，另一方面，机器对对话的结果也不好掌握，用户可能会回复各种想法，机器很容易没有理解而造成谈话不顺利，要保证这个空间是在掌控下的，所有的回复反馈的消息都是可控的，所有的问题得到的回复也是可控的。
用户很有可能在系统回复完成之间就进行了提问或回答，且回复情况超出了系统设计，为了避免用户将设计好的流程打断，令机器不知如何执行，要么尽量回复主要信息或指令，将内容缩短，要么将可回复范围放在前面
对于命令-控制模式和对话模式的转换也是很常见的，“帮我查一下最近的去北京的火车”“今天下午两点发车，从长春站到北京西站，票价260元，需要为您预订么”“明天的呢”“明天最早的是上午七点，从长春站到北京西站，票价500元，接着是XXXX”
2.7 对话式标识
让人知道自己是在和机器进行对话，自己的回复是被机器感知到的，而不是处于固定的流程之中，这在系统在对话中使用一些基本对话礼仪时，人的参与度会更高，并且以同样的方式回复，（这在引导孩子说话方式时也有一定必要性）包括：
时间线：首先，完成一半了，最后
接收回执：谢谢，知道了，好的，我很抱歉
积极反馈：干得好，听到这个消息真替你开心
而要做到这些插入，比较合理的方法是“剧本朗读”，能指导你加在哪个部分
有一些人认为机器就是机器，不应该刻意模仿人类的表达方式，反而感到不自然，要注意使用适合于系统角色设定的对话式标识，你对机器的定位使得为它塑造了相应的形象，那么随之配套的表达方式，回复方式，都应该不同，这样角色会在人们的相应领域中更加立体。
作者：李洺宇
链接：https://www.jianshu.com/p/372cb6cb7fc5
随时随地看视频
