时间: 2021-07-30 10:14:19 人气: 9 评论: 0
在上一篇文章中，我们简单了解了一下“语音交互”的相关发展历程，以及实现原理等，那么此次我们落实到产品本身，来谈谈“语音交互产品”在设计、制作时的相关原则。
语音交互能满足用户怎样的需求？或者说，我们在设计一款“语音交互类产品”时，应着重考虑哪些方面的“痛点”？
以定闹钟为例，目前我用的是IPhone7，我如果想通过传统方式定闹钟，我的流程是：亮屏-上划打开控制栏-点击图标-选择闹钟-定闹钟-结束（因为我的控制中心没有添加闹钟，而是秒表，所以需要多一步骤）。而如果通过语音助手，我只需要：嘿，Siri（启动Siri）-帮我订一个明早8点的闹钟-结束。
因此“语音交互”所需要满足的很重要一点就是操作便捷性，能动动嘴皮子就解决的事，往往**比动手来的轻松很多。若是一款语音交互产品，给用户的感觉就是我说了半天都解决不了我的需求，还不如我直接点手机来得快，那无疑它是失败的。
最直接的场景——开车。虽然明文规定开车的时候不许接打电话，但实际生活中仍有很多人还是**在驾驶途中接电话。即使有耳机，在有电话接进来的时候往往也需要我们再按一下相应的按键，才能接听。但在有“语音助手”的情况下，我们也许只需要说一声“接听”就可以了。包括我们临时有急事想要拨打电话给别人时，同样可以满足对应需求。
因此在很多时候，如果产品的语音交互功能完善，就可以为用户解决很多烦恼，同样也可以避免很多安全事故的发生，因为这个时候人的注意力不需要再集中在操作设备身上，只需要简单说几句话就可以解决一切。
“语音交互产品”更可以解决不同设备之间的信息流转问题，这就是未来的智能家居概念，通过语音来控制所有的家具设备。因为不同的设备在输入方式的选择上可能**存在差异，比如：有些是按键，有些是触摸等，但如果所有家具都能利用“语音交互”来完成相应的控制，那一切就**随心所欲很多，而需求往往同样对应着合适的场景。
目前很多的现有场景其实都适合添加“语音交互”的元素进去，所以我们简单地将其概括为三方面。
高效性适用于很多场景，比如办公场景：给XXX发送一封邮件，邮件内容是***；比如生活场景：我要去某地，请从我当前所在位置为我找一种时间最短的出行方式。诸如此类还有很多，用户追求的就是足够的快速，足够的方便。讲一句话需要多久呢？
结果导向，用户关注的是事情或者命令执行的结果，并不关心过程。比如：用户想要查询他买的股票是涨了还是跌了，对他来说也许关心的只是最后呈现的这么一个结果，那他只需要通过语音助手询问即可获知。因为本身通过“语音交互”执行命令时，用户就已经放弃了操作的过程，设备已经把所有的过程通过用户的一句话给省略了。
有些时候我们在进行网上购物的时候，也许用户就不**选择用“语音助手”来做推荐，因为大部分的用户乐于享受浏览琳琅满目的商品的过程。但同样也有很多时候用户只想快点结束过程，好达到目的，比如获知天气、定闹钟、查路线等。此种场景也多见于“工具型”产品中。
但基于目前的一个技术限制，“语音交互”功能本身也是偏向结果的，即用户较难从一次语音交互过程中获得什么享受。
即可以通过语音来实现远程控制设备，我们不需要去触摸设备，不需要有其他操作，只需说一声，设备就能运转起来。也许是简单的让放在桌上的手机设置一个闹钟，也许是让家中的电器开始运作。通过“语音交互”，我们确实能消除很多由于空间而带来的限制。
那基于此，有适合“语音交互”发挥其功能的场景，同样**有不适合语音交互的场景。
场景大致也分为三种：
在这个时候，影响的主要就是ASR（语音识别）与TTS（文本到语音）这两个环节，一个是人对设备说话，还有一个是设备反馈给用户声音。如果环境很吵闹，首先就**影响机器听取用户的声音，在将语音转文字这一环节就容易产生偏差，直接导致后续的“自然语言环节”出错，从而毁坏接下来所有的流程。
而同样，周围声音吵，机器有反馈用户也可能听不清，从而也容易对机器发出的声音产生误解。
其实这点在日常生活中就能明白，如果周围很吵，一般不**有人还**去使用“语音助手”。
这个主要是考虑到目前的一个“语音交互”技术发展的程度，现在我们绝大多数时候使用相关的语音助手，目的一般都是很明确的。解决一个问题或者制定一个任务，往往是结果导向，只要设备实现了我的这么一个要求，那么这次“语音交互”就可以算是成功的。
而“交流发散”指的是什么呢？
它主要说的是用户与设备如两人闲聊一般聊天，即交流没有目的性，这样子的对话产生的内容是呈发散性的，生活中的例子，比如：“调戏Siri”，很多用户用各种话来测试Siri，期待一个回答。但由于目前的技术限制，语音交互还远远无法实现“交流”，即如果用户注重过程，那么其实是没那么理想的。
这一点上其实与“交流发散”都有点类似，即追求结果，那么势必过程就**变得其次。因此如果用户在使用“语音交互”时流程过长，往往**得到不好的体验；或者说，本身这个指令的过程就是比较冗长的，以目前的技术也许根本不适合采用“语音交互”技术。
其他不适合的场景其实还有很多，比如：重视视觉效果的场景。“点外卖”，虽然我们之前经常**用这个来举例，但就现在来说，如果使用语音助手点外卖，稍稍显得有点没必要。
因为我们点外卖，包括购物，其实很看重视觉体验，你总不能光靠听声音就知道这个商品的成色等，而且同时本身它的流程也比较长，可能还包括手动确定订单、支付金额（也许**有声纹认证）等步骤，还无法完全依靠“语音交互”来实现。
之前我们一直说，就目前的“语音交互”的应用来说，往往能实现的功能都是偏结果型的，因此一段语音交互对话，其实是带着目的性的（与设备产生互动其实也是带着“消遣时间”的目的），或者说，设备是带着任务来与用户产生此次对话的。
任务型对话：其目标是为了达成用户所希望完成的任务，满足用户有直接目的的需求。（如：定闹钟、查路线等）
在这里，可以将这么一段“任务型对话”简单分成三个部分：
设备需要分析用户想要干嘛，也就是理解用户需求。只有在充分理解用户需求的基础上，才能设计出一款成功的产品。基于这个道理，同样要建立在理解用户想法上来去开展接下来的对话流程。
“槽位”是什么？
在“语音交互”中，它可以被理解为“关键字”，设备想要完成执行用户所下达的任务，它必须清楚地知道这个任务究竟是什么，这就涉及到对一段话中槽位的匹配。
我们举两个例子：
（1）定闹钟——“我要定个闹钟”
很显然，这是不完整的，给你定什么时候的？几点的？
在这里，时间的槽位就是缺失的，导致设备无法执行命令。
好，那这个时候，用户说“给我定个八点的闹钟”。这时候完整了吗？其实还是没有完整，因为不知道是早上八点还是晚上八点，时间的槽位依然没有明确定义，这次的任务依然无法执行。
最后用户说“给我定一个明天早上八点的闹钟”，这个时候，相应的槽位就补充完整，可以正常执行。
（2）打电话——这也是我们很常用的的“语音交互”功能。
用户说“我要打个电话”，同样，打电话给谁？电话对象这个槽位缺失。
接下来，是“给李四打个电话”，这么一看貌似已经没错了，对象也有了，具体指令也有了，但其实还是存在隐患，万一用户的手机是双卡的呢？其实任务依然无法执行，因为设备不知道用户**选择哪张卡来进行拨号，也许可以提前设置默认号码，但同样这也是槽位之一。
而且很多用户也许**给自己的联系人设置备注，或者出现同名的情况，比如：用户手机里有两个叫李四的联系人，这时候设备还应该去询问“要拨打给哪个李四”。
因此在设计这么一款语音交互产品时，就槽位判断的准确性是很重要的，一旦产生误解，或者对槽位未精确定位，相关操作就无法执行。
这个就和槽位定义相互关联，因为在一场“语音交互”过程中，顺利的话也许用户一开始就把所有槽位都说到了，那么设备就可以直接执行命令。如果出现槽位缺失，那么设备这时候就应该提示用户补充相应的槽位。
但流程分支，不光包括“槽位缺失”这一情况，还**存在“增加指令”（如用户还需要在定一个闹钟）、“放弃指令”（用户操作到一半，突然选择放弃）、“删除任务”（如删除此前设置好的闹钟）、“修改指令”（用户一开始定的早上8点的闹钟，操作中突然说要把这个闹钟改到9点）等等，这里就不一一列举。
与做APP一样，在设计“任务型对话”的流程时，我们同样需要考虑尽可能多的操作与情景。
以定闹钟为例，“设置一个明早八点的闹铃”：设置闹铃是相应需要执行的操作，明早是日期，八点是具体时间。因此这样一段对话其槽位都是完整的，流程也是最简单的，因为用户已经把所有的信息都说完整了，设备只需要执行就可以了。
“明天叫我起床”，显然缺少具体时间的槽位，虽然相应的执行操作内容是完整的，但因为缺失信息，依然导致任务无法完成，所以设备**发起新一轮的对话，要求用户补充对应确实的槽位。
这种情况相对也常见，很多用户**先说：“给我定个闹钟”，等到机器响应之后，再说“定到明天早上八点”。
即在一轮对话中，即使用户槽位表达完整，但因为出现了分支情况，导致任务依然无法立刻执行。比如：用户说“打电话给张三”，但也许用户不止有一张卡，这个时候就产生了“用哪张卡拨号”的分支；也许用户通讯录中不止有一位联系人叫张三的，那这个时候的分支流程又变成了“呼叫哪个张三”的情况。
类似这种，在一轮“任务对话”过程中，出现了分支流程时，对应的操作又应该怎么设计，这就要求产品经理能充分考虑到用户在不同情况下的一个需求，从而进一步完善相对应的功能。
也许是设备还没有执行完成任务时，突然退出的情况，在这里包括：用户关闭相关功能、用户放弃操作等情况。如果是用户直接强行退出程序，自然也没有后续进程可言，但也许可以考虑到，当用户重新启动该功能时，设备是否可以自动询问：“上次我们还有一个任务没有完成，是XXX，是否将其继续完成”。
但如果是用户停止了任务，比如用户说“给我定个闹钟”，但就在设备询问“要定几点？”的时候，用户说“算了，不用了”，那这个时候，设备应该如何回复。
因此在这一环节主要考虑的就是当一场“任务型对话”结束时，设备可以执行怎样的一个操作，来反馈给用户。
以上就是关于“语音交互产品设计原则”的简单赘述，最重要的一点是：当我们在设计语音交互的功能时，我们应该结合实际问题，从实际出发，把语音交互作为一种更高效的生产力，从而给用户带来更好的体验，带来更高的效益，而不是作为一种噱头添加到我们的产品中去。
本文由 @二十一弦 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
