语音交互产品的设计原则


时间: 2021-07-30 10:14:19 人气: 9 评论: 0

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

语音交互所满足的需求

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

1. 快捷性

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

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

2. 安全性

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

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

3. 差异性

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

适合语音交互的场景

目前很多的现有场景其实都适合添加“语音交互”的元素进去,所以我们简单地将其概括为三方面。

1. 追求高效

高效性适用于很多场景,比如办公场景:给XXX发送一封邮件,邮件内容是***;比如生活场景:我要去某地,请从我当前所在位置为我找一种时间最短的出行方式。诸如此类还有很多,用户追求的就是足够的快速,足够的方便。讲一句话需要多久呢?

2. 偏向执行

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

有些时候我们在进行网上购物的时候,也许用户就不**选择用“语音助手”来做推荐,因为大部分的用户乐于享受浏览琳琅满目的商品的过程。但同样也有很多时候用户只想快点结束过程,好达到目的,比如获知天气、定闹钟、查路线等。此种场景也多见于“工具型”产品中。

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

3. 设备优势

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

那基于此,有适合“语音交互”发挥其功能的场景,同样**有不适合语音交互的场景。

不适合语音交互的场景

场景大致也分为三种:

1. 嘈杂环境

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

而同样,周围声音吵,机器有反馈用户也可能听不清,从而也容易对机器发出的声音产生误解。

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

2. 交流发散

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

而“交流发散”指的是什么呢?

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

3. 过长流程

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

其他不适合的场景其实还有很多,比如:重视视觉效果的场景。“点外卖”,虽然我们之前经常**用这个来举例,但就现在来说,如果使用语音助手点外卖,稍稍显得有点没必要。

因为我们点外卖,包括购物,其实很看重视觉体验,你总不能光靠听声音就知道这个商品的成色等,而且同时本身它的流程也比较长,可能还包括手动确定订单、支付金额(也许**有声纹认证)等步骤,还无法完全依靠“语音交互”来实现。

之前我们一直说,就目前的“语音交互”的应用来说,往往能实现的功能都是偏结果型的,因此一段语音交互对话,其实是带着目的性的(与设备产生互动其实也是带着“消遣时间”的目的),或者说,设备是带着任务来与用户产生此次对话的。

任务型对话的概念

任务型对话:其目标是为了达成用户所希望完成的任务,满足用户有直接目的的需求。(如:定闹钟、查路线等)

在这里,可以将这么一段“任务型对话”简单分成三个部分:

1. 意图定义

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

2. 槽位定义

“槽位”是什么?

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

我们举两个例子:

(1)定闹钟——“我要定个闹钟”

很显然,这是不完整的,给你定什么时候的?几点的?

在这里,时间的槽位就是缺失的,导致设备无法执行命令。

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

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

(2)打电话——这也是我们很常用的的“语音交互”功能。

用户说“我要打个电话”,同样,打电话给谁?电话对象这个槽位缺失。

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

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

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

3. 流程分支

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

但流程分支,不光包括“槽位缺失”这一情况,还**存在“增加指令”(如用户还需要在定一个闹钟)、“放弃指令”(用户操作到一半,突然选择放弃)、“删除任务”(如删除此前设置好的闹钟)、“修改指令”(用户一开始定的早上8点的闹钟,操作中突然说要把这个闹钟改到9点)等等,这里就不一一列举。

任务型对话的流程设计

与做APP一样,在设计“任务型对话”的流程时,我们同样需要考虑尽可能多的操作与情景。

1. 槽位完整表达时

以定闹钟为例,“设置一个明早八点的闹铃”:设置闹铃是相应需要执行的操作,明早是日期,八点是具体时间。因此这样一段对话其槽位都是完整的,流程也是最简单的,因为用户已经把所有的信息都说完整了,设备只需要执行就可以了。

2. 槽位部分表达时

“明天叫我起床”,显然缺少具体时间的槽位,虽然相应的执行操作内容是完整的,但因为缺失信息,依然导致任务无法完成,所以设备**发起新一轮的对话,要求用户补充对应确实的槽位。

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

3. 含有分支流程时

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

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

4. 主动或意外退出时

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

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

因此在这一环节主要考虑的就是当一场“任务型对话”结束时,设备可以执行怎样的一个操作,来反馈给用户。

总结

以上就是关于“语音交互产品设计原则”的简单赘述,最重要的一点是:当我们在设计语音交互的功能时,我们应该结合实际问题,从实际出发,把语音交互作为一种更高效的生产力,从而给用户带来更好的体验,带来更高的效益,而不是作为一种噱头添加到我们的产品中去。

 

本文由 @二十一弦 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
6人打赏
---蛙鱼源码WAYUYM.COM---专业提供网站模板,网站源码下载,教程培训,程序插件,网站素材等建站资源,主要收集各类精品源码资源,包含CMS程序模板、网站源码、游戏源码、APP源码等 ,所有资源都没有水印适合搬运,我们致力于打造一个优秀的建站资源共享学习平台!

专业厂家,设备先进,技术力量雄厚,自动化生产技术先进,产品质量符合国家标准,价格合理,https://www.69shenlan.com/,具有质量保证,生产及时,交货快捷的特点。 我们的宗旨:做我们擅长的事,希望用我们的创意和创意为客户实现战略定位,塑造品牌,强化形象!
我们的要求:坚持“优质产品、优质服务、优惠价格、快速交货”的经营方针,努力开拓市场,真诚为客户服务! 我们的发展:以独特的专业和专业精神,https://www.69shenlan.com/1:1--

3年

评论