语音交互产品的设计原则

  在上一篇文章中,我们简单了解了一下“语音交互”的相关发展历程,以及实现原理等,那么此次我们落实到产品本身,来谈谈“语音交互产品”在设计、制作时的相关原则。

  语音交互能满足用户怎样的需求?或者说,我们在设计一款“语音交互类产品”时,应着重考虑哪些方面的“痛点”?

  以定闹钟为例,目前我用的是IPhone7,我如果想通过传统方式定闹钟,我的流程是:亮屏-上划打开控制栏-点击图标-选择闹钟-定闹钟-结束(因为我的控制中心没有添加闹钟,而是秒表,所以需要多一步骤)。而如果通过语音助手,我只需要:嘿,Siri(启动Siri)-帮我订一个明早8点的闹钟-结束。

  因此“语音交互”所需要满足的很重要一点就是操作便捷性,能动动嘴皮子就解决的事,往往会比动手来的轻松很多。若是一款语音交互产品,给用户的感觉就是我说了半天都解决不了我的需求,还不如我直接点手机来得快,那无疑它是失败的。

  最直接的场景——开车。虽然明文规定开车的时候不许接打电话,但实际生活中仍有很多人还是会在驾驶途中接电话。即使有耳机,在有电话接进来的时候往往也需要我们再按一下相应的按键,才能接听。但在有“语音助手”的情况下,我们也许只需要说一声“接听”就可以了。包括我们临时有急事想要拨打电话给别人时,同样可以满足对应需求。

  因此在很多时候,如果产品的语音交互功能完善,就可以为用户解决很多烦恼,同样也可以避免很多安全事故的发生,因为这个时候人的注意力不需要再集中在操作设备身上,只需要简单说几句线. 差异性

  “语音交互产品”更可以解决不同设备之间的信息流转问题,这就是未来的智能家居概念,通过语音来控制所有的家具设备。因为不同的设备在输入方式的选择上可能会存在差异,比如:有些是按键,有些是触摸等,但如果所有家具都能利用“语音交互”来完成相应的控制,那一切就会随心所欲很多,而需求往往同样对应着合适的场景。

  结果导向,用户关注的是事情或者命令执行的结果,并不关心过程。比如:用户想要查询他买的股票是涨了还是跌了,对他来说也许关心的只是最后呈现的这么一个结果,那他只需要通过语音助手询问即可获知。因为本身通过“语音交互”执行命令时,用户就已经放弃了操作的过程,设备已经把所有的过程通过用户的一句话给省略了。

  但基于目前的一个技术限制,“语音交互”功能本身也是偏向结果的,即用户较难从一次语音交互过程中获得什么享受。

  即可以通过语音来实现远程控制设备,我们不需要去触摸设备,不需要有其他操作,只需说一声,设备就能运转起来。也许是简单的让放在桌上的手机设置一个闹钟,也许是让家中的电器开始运作。通过“语音交互”,我们确实能消除很多由于空间而带来的限制。

  在这个时候,影响的主要就是ASR(语音识别)与TTS(文本到语音)这两个环节,一个是人对设备说话,还有一个是设备反馈给用户声音。如果环境很吵闹,首先就会影响机器听取用户的声音,在将语音转文字这一环节就容易产生偏差,直接导致后续的“自然语言环节”出错,从而毁坏接下来所有的流程。

  其实这点在日常生活中就能明白,如果周围很吵,一般不会有人还会去使用“语音助手”。

  这个主要是考虑到目前的一个“语音交互”技术发展的程度,现在我们绝大多数时候使用相关的语音助手,目的一般都是很明确的。解决一个问题或者制定一个任务,往往是结果导向,只要设备实现了我的这么一个要求,那么这次“语音交互”就可以算是成功的。

  它主要说的是用户与设备如两人闲聊一般聊天,即交流没有目的性,这样子的对话产生的内容是呈发散性的,生活中的例子,比如:“调戏Siri”,很多用户用各种话来测试Siri,期待一个回答。但由于目前的技术限制,语音交互还远远无法实现“交流”,即如果用户注重过程,那么其实是没那么理想的。3. 过长流程

  这一点上其实与“交流发散”都有点类似,即追求结果,那么势必过程就会变得其次。因此如果用户在使用“语音交互”时流程过长,往往会得到不好的体验;或者说,本身这个指令的过程就是比较冗长的,以目前的技术也许根本不适合采用“语音交互”技术。

  的场景。“点外卖”,虽然我们之前经常会用这个来举例,但就现在来说,如果使用语音助手点外卖,稍稍显得有点没必要。

  因为我们点外卖,包括购物,其实很看重视觉体验,你总不能光靠听声音就知道这个商品的成色等,而且同时本身它的流程也比较长,可能还包括手动确定订单、支付金额(也许会有声纹认证)等步骤,还无法完全依靠“语音交互”来实现。之前我们一直说,就目前的“语音交互”的应用来说,往往能实现的功能都是偏结果型的,因此一段语音交互对话,其实是带着目的性的(与设备产生互动其实也是带着“消遣时间”的目的),或者说,设备是带着任务来与用户产生此次对话的。

  设备需要分析用户想要干嘛,也就是理解用户需求。只有在充分理解用户需求的基础上,才能设计出一款成功的产品。基于这个道理,同样要建立在理解用户想法上来去开展接下来的对线. 槽位定义

  在“语音交互”中,它可以被理解为“关键字”,设备想要完成执行用户所下达的任务,它必须清楚地知道这个任务究竟是什么,这就涉及到对一段话中槽位的匹配。

  好,那这个时候,用户说“给我定个八点的闹钟”。这时候完整了吗?其实还是没有完整,因为不知道是早上八点还是晚上八点,时间的槽位依然没有明确定义,这次的任务依然无法执行。

  最后用户说“给我定一个明天早上八点的闹钟”,这个时候,相应的槽位就补充完整,可以正常执行。

  接下来,是“给李四打个电话”,这么一看貌似已经没错了,对象也有了,具体指令也有了,但其实还是存在隐患,万一用户的手机是双卡的呢?其实任务依然无法执行,因为设备不知道用户会选择哪张卡来进行拨号,也许可以提前设置默认号码,但同样这也是槽位之一。

  而且很多用户也许会给自己的联系人设置备注,或者出现同名的情况,比如:用户手机里有两个叫李四的联系人,这时候设备还应该去询问“要拨打给哪个李四”。

  因此在设计这么一款语音交互产品时,就槽位判断的准确性是很重要的,一旦产生误解,或者对槽位未精确定位,相关操作就无法执行。

  这个就和槽位定义相互关联,因为在一场“语音交互”过程中,顺利的话也许用户一开始就把所有槽位都说到了,那么设备就可以直接执行命令。如果出现槽位缺失,那么设备这时候就应该提示用户补充相应的槽位。

  ”(用户操作到一半,突然选择放弃)、“删除任务”(如删除此前设置好的闹钟)、“修改指令”(用户一开始定的早上8点的闹钟,操作中突然说要把这个闹钟改到9点)等等,这里就不一一列举。任务型对话的流程设计与做APP一样,在设计“任务型对话”的流程时,我们同样需要考虑尽可能多的操作与情景。1. 槽位完整表达时

  这种情况相对也常见,很多用户会先说:“给我定个闹钟”,等到机器响应之后,再说“定到明天早上八点”。

  即在一轮对话中,即使用户槽位表达完整,但因为出现了分支情况,导致任务依然无法立刻执行。比如:用户说“打电话给张三”,但也许用户不止有一张卡,这个时候就产生了“用哪张卡拨号”的分支;也许用户通讯录中不止有一位联系人叫张三的,那这个时候的分支流程又变成了“呼叫哪个张三”的情况。

  类似这种,在一轮“任务对话”过程中,出现了分支流程时,对应的操作又应该怎么设计,这就要求产品经理能充分考虑到用户在不同情况下的一个需求,从而进一步完善相对应的功能。

  也许是设备还没有执行完成任务时,突然退出的情况,在这里包括:用户关闭相关功能、用户放弃操作等情况。如果是用户直接强行退出程序,自然也没有后续进程可言,但也许可以考虑到,当用户重新启动该功能时,设备是否可以自动询问:“上次我们还有一个任务没有完成,是XXX,是否将其继续完成”。

  但如果是用户停止了任务,比如用户说“给我定个闹钟”,但就在设备询问“要定几点?”的时候,用户说“算了,不用了”,那这个时候,设备应该如何回复。