语音交互产品的设计原则Word文档格式.docx

语音交互产品的设计原则Word文档格式.docx

《语音交互产品的设计原则Word文档格式.docx》由会员分享，可在线阅读，更多相关《语音交互产品的设计原则Word文档格式.docx（7页珍藏版）》请在冰豆网上搜索。

因此“语音交互”所需要满足的很重要一点就是操作便捷性，能动动嘴皮子就解决的事，往往会比动手来的轻松很多。

若是一款语音交互产品，给用户的感觉就是我说了半天都解决不了我的需求，还不如我直接点手机来得快，那无疑它是失败的。

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，是否将其继续完成”。

但如果是用户停止了任务，比如用户说“给我定个闹钟”，但就在设备询问“要定几点？

”的时候，用户说“算了，不用了”，那这个时候，设备应该如何回复。

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

以上就是关于“语音交互产品设计原则”的简单赘述，最重要的一点是：

当我们在设计语音交互的功能时，我们应该结合实际问题，从实际出发，把语音交互作为一种更高效的生产力，从而给用户带来更好的体验，带来更高的效益，而不是作为一种噱头添加到我们的产品中去。