语音交互设计

一、语音交互

在《科技想要什么》一书中,凯文·凯利向我们介绍了一种全新的科技观,即科技并非是由线路和金属构成的一团乱麻,而是有生命力的自然形成的系统,正如生物演化一般,科技也有独特的演化路径,而通过追踪长期的技术发展趋势,我们可以对“科技想要什么”有所理解。

那么,以这种观点来看待技术的发展,我们会发现技术的一条演化路径,就是从电气化,到互联网化,再到移动互联网化,最后到现在的智能化。而在这条路径中,我们可以清晰地发现人与机器交互方式也在随着变化,从电气时代的旋钮按键交互,到互联网时代的鼠标键盘交互,再到移动互联网时代的图形界面交互,这样可以看出随着AI技术的发展,必然会带来交互的革命,产生新的交互方式,将我们从鼠标键盘和触摸屏上解放出来。那么人与机器的交互就会从不平等的单向被动模式转变为逐渐平等双向的多模态主动模式,而语音交互就是这个过程的第一步,也是基础性的一步。

对于语音交互来说,这是一种更自然的交互方式,非常贴合人类的直觉,即使是一个对技术完全不熟悉的人,只要给他一个界面,并通过界面问题一个问题,他也可以很自然地进行回复。并且通过应用语音交互,人们不再是只能跟一款产品进行对话,而是可以同时与多种产品进行对话,这将极大地增加交互价值,带来全新的交互体验。

虽然语音交互已经有了一些落地应用的场景,但还未成熟到可以替代鼠标键盘和触摸屏,这就需要我们从设计层面思考语音交互的设计原则,规避一些无法实现或不好实现的功能特征,从而带来全新的交互体验。接下来将从情感设计和用户界面设计两个方面阐述我所学习和思考的关于语音交互设计的一些原则方法。

二、情感设计

从语音交互的特性上来讲,其主要载体为语音,是人类主要的沟通方式,其中包含了语气、音量、语调和语速,能够传达大量的特征信息,比起简单的文字来可以让人感受到同理心,体验到生命感,就会让人对产品产生依赖,寄托情感,所以情感设计必不可少。

2.1人物模型

对于新生事物,尤其是没有实体、需要依靠想象的事物来说,人们更倾向于从人类形态对其进行认知,如影视作品中的外星人大多是人形的,所以,对于语音交互产品这种新生事物来说,赋予其人格化,会更符合人类的认知,而且人格化更有利于表达情感,容易让用户接受,所以在情感设计中,最基础也是最先需要考虑的就是要为产品设定一个人物模型。

设定人物模型还有一个好处是用户可以通过与产品的交互感知到这个人物模型,进而推断出产品人格或角色的标准化心理形象。所以,通过人物模型这一媒介,可以在用户认知中塑造出特定的品牌形象,因此,人物模型的设定决定了用户对产品的态度,就需要谨慎细致地进行人物模型的设定,总的来说有以下几个各方面需要考虑。

2.1.1情感存在性

虽然情感是语音交互的一大亮点设计,但也是可以考虑反其道而行之,把语音交互设计成一个工具,因此在考虑如何设计人格时,首先要解决的是人物模型的情感存在性问题,人物模型是否存在情感决定了后续的一系列设计。可以回答以下几个问题:

你介意打破用户把语音交互幻想成人类的倾向吗?

你会让用户问系统自身相关的问题吗?比如喜好、经历背景等

你认为的系统自然拥有的价值观和行为应该有哪些?

对于不符合价值观的事应如何处理?比如如何处理粗鲁和粗俗的行为?

当你确定了以上几个问题的答案后,只会产生两种结果:一是不需要情感,那么之后所有的设计就需要从工具的角度出发进行设计,所有的设计都是为了提高效率而设计;二是需要设定情感,那么对以上问题的回答就会让你有一个大致思考的方向,而接下来就需要细化这个方向,进行人格化特征的落实。

2.1.2人格特征 

在设定产品人格特征时需要考虑两个原则,一个是真实性原则,也就是说对产品人格的设定需要真实可信,符合产品真实的使用情况,所以就需要我们用真实的人格来定义声音,那么就需要先找到一个这样的形象,一个可行的方法是从产品定位的场景和用户群两个角度出发找到最符合用户认知的真实人格,然后根据这个真实人格形象撰写详细的个性特征,并设定我们希望用户如何看待产品;二是一致性原则,不要贪多求全,进而过度设计一些不必要的人格特征,要求设定的人格特征必须适合产品使用场景,不能在严肃认真的场景中设计出轻浮、玩笑的特征。但要注意一点,不要设置太强的个性,个性太强会来了负面的影响,

2.1.3行为原则

在设定完人格特征后,就会对产品的行为产生影响,决定了一些情景下如何表现。就需要认真思考符合人格设定的一些原则,可以从多个视角考虑这个问题:产品目标、公司目标、道德目标和社会目标等。通过对这些目标的思考,就可以帮助设定一系列的原则。

对于这些原则来说,一方面是可以演进以适应新的场景,另一方面需要有一套核心的原则作为指导方针,定义你设计的人格应该完成什么样的目标,以及对完成目标有什么帮助,并以此指导对话。例如如何对辱骂性语言进行回复。

2.2可视化形象

2.2.1存在性

对于语音交互来说,是否有一个可视化的形象也是一个非常值得考虑的问题,因为一个可视化形象可以让用户对产品的感知更加形象,而且提供视觉反馈,会使交流流畅,在情感表达上也更加方便。但对于不同的产品和场景来说,一个可视化形象的存在与否有着不同的利弊,因此对于是否设计可视化的形象有以下几条原则:

1、场景原则,要根据场景的内在要求决定是否设计可视化形象。比如当你的产品是用来搜索查询时,就可能不需要一个可视化形象,而如果产品是一个真人对话式场景的话就需要一个可视化形象。

2、产品载体原则,要针对产品载体设计相应的视觉化形象,比如对于无屏幕的硬件产品,如音箱等,可能的视觉化形象就是简单的发光提示,而对于App或网站,可能就是一个人物或卡通形象。

3、用户特性原则,视觉化形象有着不同的类型,要根据用户群的特性进行选择,比如针对儿童群体,一个可爱的卡通形象比较适合,而对游戏群体来说,一个真人角色形象比较适合。

2.2.2交互设计原则

当选择设定一个可视化形象,也即虚拟角色后,就需要在与用户交互的层面上来考虑产品的设计,主要有以下一些问题:

一是与人物模型匹配的问题,视觉化形象要从角色的顶层人格特质开始设计,需要设计与人物模型相应的形象来展示相关人格特征,考虑需要展现的博学、专业或更具有同情心等问题,并且对于性别的设定来讲,虽然现有的产品女性的设定比较多,并且一个女性角色可能会让用户更容易交流情感,但在产品设计时不要假设用户更喜欢女性虚拟角色,而应该尽可能多进行用户测试;

二是情景匹配的问题。虚拟角色的形象和行为表现应该与对话场景匹配一种,即在快乐的氛围下,展示愉快的形象,在伤心的情景下要表现安慰的行为,需要注意的一点是在该情境下虚拟角色需要展示多少部分,仅展示脸,还是脸和上身,或是整个身体;

三是对错误的处理。当出现未识别到用户语音或回复内容无法匹配等错误时,需要让虚拟角色表现出愧疚、自责等情感,从而将产品错误转化为一次情感交流,减轻用户对产品的坏印象,并且通过匹配聪明的回复,来增加趣味性,让对话继续下去;

四是GUI的使用问题。在一些产品中,如App,会有图形交互界面,因此,用户面临着是选择通过说话还是使用图形用户界面来回复。一般的原则是尽量引导用户通过语音回复,培养用户使用语音交互的习惯,但如果出现异常或错误的情景,可以让用户通过GUI进行回复的选择,这样可以让用户在产品未识别到语音或不太想说话时根据GUI提示来继续对话,可以带给用户良好的体验;

五是话题转换和打断的问题。在对话中,用户可能并不会等待产品完整的回复就进行打断,因此要设置等遇到用户打断情况下的角色形象,不能在用户打断后,还继续说话;

六是进入和退出对话时,要通过角色的形象产生视觉反馈,让用户知道在可以在何时说话,并能够做出相应的倾听或回复的动作。

其次还存在一个需要额外注意的问题就是恐怖谷陷阱,即当你看到一个与人类极其相近但并不完全相像的事物时会感到恐怖,因此在设计时不要让虚拟角色太过逼真,或是可以使用卡通形象。

总之,设置一个可视化形象的目的就是要吸引用户注意力,保持用户的参与度,让用户能够更顺畅的进行对话,并获得情感上的交流,因此就要根据人物模型设置一个合理的形象,即符合用户预期,又能让用户对产品有形象化的认知,产生沉浸式投入。

三、用户界面设计

对于语音交互的产品来说,想要带给用户真实顺畅的体验,就要从两个方向上的进行考虑,一个是前面提到过的情感设计,通过设置一个合适的人物模型,展现出适合场景和用户的人格特征,以此吸引到用户的投入,并与用户产生直接的情感交流,同时也可以考虑是否设置一个可视化形象来让用户对产品的感知更加形象化,提高用户参与度;另一个就是需要进行用户界面和产品对话机制的设计,以保证产品能够恰当地展示形象,与用户保持一个良好的对话互动,让对话进行的更加顺畅,接下来就讲一下关于用户界面的设计。

3.1对话式设计

语音交互关键的一步是要让用户有真实的对话感,这样才能让用户投入进去,交流情感,所以一个对话式交互机制的设计必不可少,而目前产品设计的多是一连串的单轮对话,每一个独立对话都是一个简单的交互,下一对话不会继承上一个对话里的信息,只是独立地完成与用户的信息交换。但现实中的对话并非这样的,真正的对话是具有上下文记忆的,能够明白当前对话出现过之前说过的内容,感知对话的情景,所以对话式交互设计非常重要,可以带给用户真实的对话体验。

一般来说,会将对话式设计定义为用户与产品进行一轮以上的交互。而要进行一轮以上的对话,就需要从对话的设计和管理两个角度进行考虑。

3.1.1对话设计

在进行对话设计时,一定要以场景和用户为中心。以场景为中心,就是要考虑对话的情景来进行设计,主要分为封闭域对话和开放域对话。

a、封闭域场景

对于封闭域场景来说,一般是围绕一个特定的话题进行交流,要求用户输入指定话语才能继续对话,这也就决定了该场景下对话的特征,一是输入和输出有具体可分的类别且可以枚举,二是对话有流程,具有明确的开始和结束。

因此,在产品设计上就有三个特征需要考虑,第一个是对话设计的目的,是为了解决某个特定的问题或需求,所以对话的输入输出是有一定范围的,而且整个流程具有条理清晰且逻辑合理的特点。

在设计时,一是要将用户的输入所有可能性句式尽可能穷尽,然后设定同一合理有趣的回复,让用户不管输入何种句式都能得到回复;

第二个是场景特性,是单一可控的,换个角度看就是不同的场景对对话的要求就不一样,因此对话设计必须符合该封闭域的内在要求;

第三个是对跳出边界的处理,因为对话的输入和输出是一个有限的集合,而用户并不会严格按照集合进行回复,所以随时面临用户跳出话题边界,比如聊起其他话题、不按规则出牌等,就需要对这种情况设计如何进行回复,但不要设置统一回复,而是要想好所有可能的跳出情况,然后为每一种情况设计单独的处理,这样更能让用户有真实的对话体验,让用户更加投入,带来沉浸式体验。

b、开放域场景

对于开放域场景来说,对话非常像一个搜索引擎,用户想说什么就说什么,系统会针对用户输入来回复相应的内容,这样对话的输入输出无法穷尽,也没有明确的流程,就需要有一个严格的产品机制来保证对话的流畅性。

这里在设计时需要考虑的几点,一是需要不断的给用户制造符合情景的话题,否则用户就会因为缺少可以继续交流的内容而终止话题。可行的方法是围绕情景建立一个话题库,让其包括情境下一些基本的话题以及当下的热点话题,然后设计一个产品主动问询机制,当满足缺少话题的条件时,系统会主动从话题库中搜索合适的话题与用户交流,这样既能让对话进行下去,也能让用户感觉到产品的主动性,从而带来不一样的体验,需要注意的一点是不能在用户不想交谈时制造新话题,因此对主动问询机制触发条件的设置需要考虑周全;

二是语料的问题,由于是在开放的场景下问答,无法通过人力将对话编写的很全面,因此所有语料一般都是来自网络上公共的人人对话,但也可以通过用户对产品的使用来搜集与用户的对话,但搜集到并不是终点,还应该对语料进行相应的处理才可以使用,比如去除不符合场景的、带有侮辱歧视性质的内容;

三是要能够与用户建立亲密感和信任感,因为现阶段用户使用产品多为尝鲜调戏而来,输入也是千奇百怪,因此如果只针对内容进行回复就无法在用户心中形成固定的印象,自然也无法建立起亲密感和信任感,因此在设计时,需要着重考虑人物模型和风格的设定,回复时要符合这些设定,这样才能让用户认知到一个清晰固定的形象,从而让用户感受到情感的交流,进而与用户建立亲密感和信任感,提升用户粘性。

c、用户中心

以用户为中心,即在设计对话时,时刻考虑到用户的意图,要思考用户是完成一次性的任务还是进行多轮对话。对于完成一次性的任务,就要设计出合理的流程来对用户进行引导,让用户能够高效率地完成任务。但对于进行多轮对话时,就要去了解用户,要思考用户的下一步会做些什么,不强迫用户展开新一轮的对话,并且让用户决定何时开启对话以及对话要持续多久。

在设计时,就可以为用户设计一个私人对话数据库,主要可以存储三方面的内容:一是通过与用户对话积累的一些用以支撑对话的通用知识,通过查询这些知识,可以更好地理解与用户的对话内容;

二是通过用户在交流过程中,面对某些问题时所采用的行为模式进行积累。那么在之后的对话中,就可以根据这些模式来进行回复,既可以回复与用户行为模式不同的对话,带来趣味性,保持用户的新鲜感,也可以回复与用户行为模式一致的对话,就能维持系统对话行为的一致性,为用户提供熟悉感,让用户感到是在跟一个对象进行对话;

三是学习并了解一些用户的基本情感反应,能够知道用户在什么情景下说的的那些话代表了什么情感,从而做出更适合的应对。

3.1.2对话管理

想要进行真正的多轮对话,除了对话设计外,还需要对话管理,能够让系统记住过去的信息,这样在后续的对话中,能够利用上下文信息进行合理回复,保证对话的持续进行和话题轮换。

首先,需要建立用户画像,让系统能够感知到一些基本的用户特征,然后在这个特征基础上生成与用户的对话;

然后,是让系统知道需要记忆哪些信息,比如说对订外卖来说,要获得以下信息:店铺名、饭菜名、饮料名、街道地址和电话号码等。因此就要针对产品的应用场景,提前把系统需要的信息想好,并设定合理的词槽。

同时,还要考虑这些信息的获取机制。需要思考以什么样的顺序获取信息是比较符合用户习惯,是让用户一次性提供还是通过对话一点点得到,并且要在对话中通过合理流程引导用户,让他们以自己的方式提供这些信息。

最后,要把这些获得的信息储存起来,就可以进行上下文跟踪和语境感知,即通过查询这些记录着已发生的对话内容的信息,来理解接下来用户输入的内容,就可以清楚知道一些代词、时间的含义,既可以给用户正确的反馈,以及根据已记录的信息改变自己的提问方式,同时避免重复的提问或回答。

并且在存储对话信息的同时,也可以设计一个对话自我学习机制,让系统可以根据这些对话信息,提取其中的数据特征来优化和生成新对话,然后再用这些新生成的对话反哺系统,就会产生对话内容的自我循环进化,能为用户提供更多新鲜的回复,提高用户体验。

另外,还要考虑的一点是关于对话标识的设置。这样能够让用户了解对话的进展情况,让对话显得自然流畅,使得产品更加人性化。

对于标识,主要考虑的方向就是使用一些基本的对话礼仪,并且要适合系统角色的设定,一般包括以下三个方面:时间线,如首先、然后呢,最后等;接收回执,如谢谢、好的、知道了等;积极反馈,如做的不错、很高心认识你等。在编写完对话方案后,可通过与别人做一次“剧本朗读”,这样能帮助你决定在对话的哪个部分中添加对话标识。

3.2用户机制

3.2.1模式选择

在模式选择时,需要考虑是让用户随时可以向系统提问/命令,还是让用户进入一个有明确开始和结束的封闭式对话。

当参加的是一个有明确开始结束流程的对话时,选择的模式就是命令-控制模式。在这种模式下,必须考虑用户如何进行开始和结束以及系统如何回复。对于开始来说,要让用户给系统明确的指示,比如按键或者说关键词唤醒。对于系统回复,需要考虑不同的情况,在开始时,可以采用非语言性的提示音效或者视觉反馈的方式进行响应,然后用户就知道系统正在聆听。然后要设置合理的聆听等待时间,一般情况下10s是一个合适的值,也可以根据实际情况进行调整。当在这段时间内未收到用户回复时,根据对话内容来决定是询问还是结束对话。在结束对话后,要根据对话内容决定是继续处理后续请求还是等待下一次明确对话。

当选择让用户随时向系统提问或命令时,就选择对话模式与用户进行对话。整个过程是自然开始的,无需明显的确认。要在对话过程中利用对话技巧进行话轮转换,比如说问问题、虚拟形象的眼神交流、适时的停顿以及指出明确的方向,需要注意的是不要强迫用户对话,对于可能存在用户打断对话的情况时,要先说可能的指令在说问题,如果为匹配到合适内容,可以设计合理的提示让用户明白为了继续对话应该做些什么。

当然这两个模式并不是选择一个就不可以在使用另一个了,也可以同时使用,但最好在模式转换时,设计合适的提示,让用户大致知道对话模式已改变。

3.2.2用户管理

在进行对话设计时,不可避免的一点就是如何对用户进行管理,这样才能够让用户对系统有一个合理的期望,培养用户的使用习惯。

需要注意的以下几点,一是要先理解答案再提问,比如在用户写完电子邮件时,会出现提示“您是发邮件还是更改邮件”,而用户遇到此问题的下意识的回答很可能是“是”,所以就要在系统中建立对这种情况的回复,需要修改提示内容,让其更加明确,如“您想做什么:发送邮件还是更改邮件”;

二是要对已完成的任务有一个提示,虽然不必要,但万一遇到设置失败的情况就可以提醒到用户;

三是在用户设置了可以完成某项任务的预期时,一定要设置相应的取消任务设置;

四是可发现性,要能够让用户知道什么时候可以说话,以及可以说些什么,最好的方式就是借助用户的自然语言进行功能设计,这样比较贴合用户的实际使用体验;

最后一点是不要责怪用户,用户总是对的,要把错误归结为系统设计,然后设置聪明有趣的回复,这样不会影响用户对系统的看法。

另外,需要额外考虑新手用户的体验,通过设置包含教学细节的引导提示来让用户明确使用流程和产品认知。同时,不要晾着用户不管,在用户要求很多时,可以先满足用户的部分要求。总之,用户期望管理的目的就是让对话适应用户的行为,不让用户感到厌烦。

3.2.3数据处理

通过与用户对话产生的数据,具有巨大的价值,一方面可以让产品记忆过去的对话内容,与用户进行多轮对话;另一方面,可以作为素材来让产品使用,并且可以通过分析这些数据来改进产品。所以产品都通常都会存储这些数据,但不可避免的就是会遇到用户隐私的问题,因此在存储这些数据时,一定要采取匿名存储的方式,将一切有关用户隐私的信息去除掉。

3.3确认模式

3.3.1唤醒词

在确认模式中,首先需要考虑的就是产品的唤醒机制,即如何让产品开始进入回应模式。当前主要的策略就是通过唤醒词进行产品唤醒,比如亚马逊Echo音箱的“Alexa”,这是一种不需要身体接触设备就可以唤醒产品的非常便捷的方式。

那么如何制订合适的唤醒词就很关键,一般来说,唤醒词首先要易于识别,且不易混淆,因此一些过短的词句就无法使用,一般会要求使用的词是多音节词,并且需要确保唤醒词能让人很容易说出口,因此,现行的唤醒词大多是产品的名称,或者加上打招呼用的礼貌用语,如hi、ok等。

另外,还需要考虑的是误唤醒和唤不醒的情况。首先来说,这是一个识别灵敏度问题,需要多测试调整,让产品在识别过度和识别不足之间取得平衡。其次,对于误唤醒情况来说,要确保不选择人们在谈话中常用的词,而对于唤不醒来说,可以考虑增加一些视觉识别方案,从语言和行为两方面来确保能够唤醒产品。最后,需要注意的是要在本地处理唤醒词,这样才能最快地响应用户。

3.3.2确认策略

在唤醒产品进入对话后,就需要设置合适的确认策略来确保用户能够感觉到自己被理解。但也要注意,不能让产品出现过度确认的情况,比如重复向用户确认命令,这样会让用户脱离对话的情景,并感到厌烦。

在设计确认策略时,主要从以下几个方面考虑:一是错误的后果是什么?是否重要?对于订票转账这种行为不允许出错,而如果是为了娱乐的化,出错可能是一种加深用户印象的方式;二是系统反馈的方式是什么?是文本、语音,还是视觉反馈,如果带有屏幕的话又该如何反馈;三是以什么样的形式来确认比较合适,是明确还是含蓄,或者是混合形式。

而在确认方式上只有两种,显性确认和隐性确认,下面介绍一下具体的方法策略。

a、显性确认

一是通过重复用户的回复/要求来进行强制确认,这种方式最直接,但可能在体验效果上不是很好,只有在一些特殊场景下使用,比较合理;

二是设置相应的视觉形象,对于无屏幕的产品可以通过发光响应,而对于有屏幕的,可以通过视觉形象或GUI展示相应的形象或按键来对用户进行确认。

b、隐性确认

一是将答案和原始问题的一部分连起来一同回复用户,比如说用户询问世界上最高的山峰是什么?系统回复“世界上最高的山峰是珠穆朗玛峰”;

二通过行动相应,比如说用户命令开灯时,打开相应的灯光就行,无需再回复“好的,将为您打开灯光”,但要注意用户指令到操作的延迟,若无法立即产生操作,需要让用户知道系统已经接受到指令,一个好的办法是设计一个操作提示音。

c、三级置信度

一个混合显性确认和隐性确认的策略是通过评估置信度阈值来进行确认,不同的置信度阈值采取不同的确认策略,一般采用三级置信度的方法,比如在置信度为80%以上的区间,采取隐性确认的方式,在79%-50%的区间内,采取显性确认的方式,当置信度低于50%时,通过提示用户再说一遍的方式来进行确认。

3.4异常处理

为了让用户有一个良好的体验,除了需要考虑正常的运行机制外,还需要考虑对异常的处理,这里主要包括对错误、歧义和延迟的处理。主要的目的就是让系统在对话出现问题时,也能对用户提问进行反馈,让对话进行下去,带给用户真实的对话体验。

3.4.1错误处理

a、未检测到语音

对于未检测到语音的情况,首先需要明确的一点就是这并不等于用户什么也没说,有可能是因为某种原因,系统为检测到。

一般有两种处理方式,一是明确地说出来,一种是什么也不做。不同的情况可以采取相应的方式。

当你的系统只使用语音,用户没有其他的回复方式,而必须要用户回复才能继续时,就需要采用明确地说出来;当用户通过其他方式进行下一步操作,或是就算什么也不做,也不会中断对话时,就什么也不做。

需要注意的是不能每次都提醒用户,那样会很烦人,可以利用人类已经适应的对话规则,使用一些微妙的反馈来提醒用户。

b、检测到语音但未识别

在某些情况下,ASR工具确实检测到音频信号,但无法给出任何可靠地识别结果。面对这种情况,处理方式和第一种错误非常相似,可以明确地说出来,或是什么也不做。还有一种处理方式是专门设定一个对这种情况的回复,比如说“对不起我走神了,可以再说一遍吗”,通过回复引导用户进行下一步操作。

c、识别出语音但系统无法处理

对于识别的内容系统无法处理,这种情况多是由于在对话数据库中未包括对一些情况的处理,因此需要对用户可能会说到的所有情况做更完善的预测,并设置相应的回复。

d、部分语音识别错误

当遇到部分语音识别错误时,需要靠系统机制来规避,比如设置一个完备的N-Best列表,或对真实用户响应的数据进行分析,来建立解决方案。

3.4.2歧义消除

歧义通常有三种情况:

一是用户只提供部分信息,就会使系统没有足够的信息来进行回复。在这种情况下,处理方式是可以通过上下文信息来推测用户所说的内容是什么意思,然后直接回复,让用户来进行确认。还可以对用户进行进一步的问询,这就需要设置一个主题列表,对于缺失的部分进一步询问用户;

二是用户提供过多信息,导致指令不明确。这种情况下,可以通过询问用户想要做什么来进行确认,但不要在下次提问时询问上次已经确认的事;

三是用户提供的信息超过系统能够处理的范围,那么就需要通过对话引导用户缩小范围。

3.4.3延迟

通常延迟由以下原因产生:糟糕的连接性能、系统处理进程、数据库访问。面对这些原因,必须今早考虑到用户可能面临的延迟,确保系统有对应的处理措施。一个可行的做法是将原因告知用户,或者是设置有趣而聪明的回复来让用户等待,比如说“突然身体不舒服,等一下再回复你呦”。还可以做的是将语音进行分布处理,对于唤醒来说放在本地进行,而对对话音频的处理放在云端进行,从而提升效率。另外,需要注意的一点是延迟并不一定都是不好的,有时候,人类对话就是会有延迟,因此,会在一些地方如回复之前加上一些延迟,让对话显得流畅,不会让用户感觉到异样。

3.5帮助和其他通用部分

为了带给用户更好的体验,我们需要确保每一个状态都包含一组通用组件:重复、菜单、帮助、操作和再见,这样可以符合用户已有的操作系统,如重复、取消和获得帮助。

对于系统的帮助部分,要注意以下几点:一是要做用户需要时就能得到,因此需要提供操作说明,让用户知道可以做什么,还要考虑用户会如何表达求助以及该提供怎样形式的帮助;二是要与上下文有关,但也要考虑在没有上下文帮助时如果提供;三是如果有屏幕时,要利用好视觉空间。

最后值得说的一点是关于交互载体的选择,虽然语音交互给人的印象可能是用语音进行交互,但实际上语音交互指代的是一种更符合人类交流的一种自然交互方式,所以载体并不局限于语音,对照现实中人类交互,我们可以发现除了语音外,还有视觉、肢体动作等,因此,一个好的语音交互设计必定是多模态的,通过语音+表情+动作+文字的组合形式,可以减轻用户的认知负担,更加合理地给用户展示信息,带给用户更好的体验。而在设计多模态时,一个可靠的模型是梅拉比安沟通模型,将动作和语言串在一起。背后的理论是:有效沟通要素的重要性:文字7%,声音语调38%,动作55%。

以上内容来自近期对《语音用户界面设计:对话式体验设计原则》一书的阅读和在饭团AI产品经理大本营的学习和思考。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,928评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,192评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,468评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,186评论 1 286
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,295评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,374评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,403评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,186评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,610评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,906评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,075评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,755评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,393评论 3 320
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,079评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,313评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,934评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,963评论 2 351

推荐阅读更多精彩内容