近来对语音交互设计又有了新的感想，总结一下。本文是依据个人工作经验及相关资料中的内容整理出来的，非教程。有不对的地方欢迎指正吐槽。文中图片为网络搜集，若侵权请联系处理。

工作背景

先描述一下我的工作环境，若没有遇到与我类似的环境则可以忽略其中的一些方法或观点。

一、产品的语音识别系统非自主研发，是由其他厂商提供。在自然语言理解方面无法做过多干涉，只能依赖于提供商的软件升级。原生语音交互场景的数量及其场景资源也依赖于系统提供商。

二、产品的外形设计虽是自主研发，但是工设很糟糕，无论是外观还是内部构造都差强人意。这方面我没有太多发言权。

在产品的设计中没有做过与自然语言理解及虚拟形象相关的工作，若下文中出现与之相关的观点，纯属个人臆想。

语音交互原理

语音交互产品设计要解决两个问题：自动语音识别（ASR）与自然语音理解（NLU）。通俗点说就是语音的接收与反馈。

其中自动语音识别又分两种情况。一种是语音接收成功，一种是语音接收准确。

语音接收成功指设备唤醒之后（如果唤醒失败则无响应）识别到的用户语音指令。如果识别到的用户的指令是无规则的声音或是一句不完整的指令也属于语音接收成功。

语音接收准确指的是唤醒设备之后用户的声音指令被准确接收。因为有时设备接收的声音未必是用户想发出的指令。比如，在我们的测试中语音输入“张三”时设备有很大概率会识别成“张山”。

只有在语音接收成功的时候才会出现语音接收准确问题。

自然语言理解又分命令-控制模式与对话模式。

这两者都是根据用户的指令操作。不同的是命令-控制式单纯只是去执行，对话模式则会分析当前语境给出最优答案。

以用户要看电影为例，命令控制式下用户给出指令要看电影，设备会给出一个推荐电影列表。对话模式则是在根据语义给出相应的推荐，比如“最近比较流行《权利的游戏第八季》，是否要看这部呢？”

我们的产品设计是 命令-控制式 基础上加入一些人性化的反馈设计。

产品定位

关于产品的定位的想法有些偏感性。因为有些用研无法去做，也没有相应的数据支撑。觉得无聊的可以略过本节。

前期在为公司产品做市场调研及竞品分析时发现，当今的家庭语音设备大部分是面向儿童群体。做完会议报告之后上层领导将将产品定位为一个面向家庭的产品。主要原因是我们的产品有部分面向成人的功能， 领导层觉得功能越多受众就越广。

为此针对家庭做调研、用户画像等工作，不过由于个人能力问题导致失败了。从能想到的比如家庭收入入手，利用相关利益人、四象限法等方法进行尝试。但是最后依然没有顺利建立一个家庭的用户画像。找不到那个可以让一个家庭购买产品的决定性因素。在调研过程中发现家庭成员间的需求还会出现相对立的局面。

比如面向儿童的设备应当体型应当小巧，界面卡通风格，最好还能自己跑来跑去。但对于成人设备的高度会成为一个很大的使用问题，毕竟不能像孩子一样趴在地上去玩。

重新去思考这个问题时发现之前可能进入了思维误区——也许不该去建立家庭的用户画像。某个家庭成员的需求大于设备的购买成本时就可以买入，并不一定要家庭所有人都需要（产品的功能）。比如，家里有身体经常不适的老人。视频医生功能能提供更好更便捷的医疗服务。上班的子女可以为老人购买一个设备而不必去考虑孩子会不会需要这个设备。当然，可能大家比更早的看透了这一点，所以智能语音设备大都主打儿童群体。

那从另一个角度想一下，是否存在同时满足老人，夫妻及孩子这三类人群的产品呢？答案是有的。而且很常见很实用，以至于忽略了他们的存在。

沙发旁的电话座机、客厅里的电视机、角落里的洗衣机、客厅里的冰箱等。这些产品没有专门的为去讨好某一用户群体而设计，但是整个家庭都在用。你的冰箱上面不会设置一个显示屏，在检测到小朋友靠近时会出现冰雪女王来他互动吧（好主意！加上一个屏！这样就是智能冰箱了）

这样想的话产品的定位就有了新的方向。

看下智能音箱设备的基本功能：语音人机交互、播放音乐、远程监控、连接智能设备。他还可以像路由器作为一个连接网络的终端产品一样，成为一个连接智能设备的终端。

脱离“智能”、“语音”这几个词的控制，从一个客观角度观察的话给现有产品加入语音控制操作也不失为一个好主意。不过，家里有多个可用语音控制的设备也是很头疼的。这时就需要有个一个控制终端将他们都连接起来统一管理。小米貌似走的是这个方向——建造一套由自家设备构成的生态圈再通过小爱同学来统一控制。因为如果是不同厂家的智能设备的化在缺少协议的情况下适配连接是个很头疼的事。

总结一下，智能语音设备的定位看好两点。一是针对某一类人群的专用设备，像传音手机那样。二是作为连接控制其他设备的终端设备。

人机交互

先说下交互系统

语音交互与手势交互、触屏交互等其他方式一样属于众多交互方式中的一种。在进行语音交互设计时可以考虑将他们结合使用。

语音交互系统设计时要同时考虑 声音系统、GUI系统、灯光系统。

声音系统包含语音交互与声音反馈。语音交互指的是用户通过语音给设备指令及设备通过语音方式反馈的这个交互过程。声音反馈主要是指设备在被唤醒或识别时反馈给用户的声音反馈，如微软小娜在被唤醒等待指令输入时的嗡嗡声。

GUI系统是指通过屏幕上的图形界面给予用户反馈。自身不带显示屏的智能音箱设备若在与其他设备上投屏时也需要考虑视觉反馈问题。

灯光系统主要指设备的指示灯状态。常见的如冰箱门打开后的灯光指示；电视机在更换频道时接收指示灯变红状态。

灯光系统属于辅助系统，以不同状态配合其他系统与用户进行交互。

再说交互过程

前面说过，人机交互在设计时就是要解决语音的接收与识别反馈问题。细分一下可以分为：设备唤醒、语音接收、语音识别、执行反馈四个阶段。

设备唤醒主要是指设备接收到唤醒词的过程（也可以通过触屏方式唤醒）。接收到唤醒词为唤醒成功，否则为唤醒失败。关于唤醒词名字的设计，百度AI交互研究院有篇文章进行了详细的介绍。本人工作中没有想关经验，大家可以移步：拿什么名字唤醒你？我的智能小伙伴。另外小米公司的“小爱同学”是我认为国内唤醒词设计中作的的比较好的一个。

唤醒时如果唤醒失败设备是不会有声音反馈的——是废话。但是我想说需要给用户一个反馈。

举个例子：路上看到一辆共享单车，想扫码骑行。打开app后发现身边的这辆显示有故障，那么只好找下一辆。遇到下一辆时看到车子少了一个轮子，然后打开APP看到这辆车提示有故障......

语音设备在识别不到唤醒词时当然无法唤醒。但是可以通过指示灯来告知用户设备是否接收到唤醒词。如待机状态下指示灯是熄灭状态，识别到唤醒词时变为闪烁状态。

用户进行唤醒时发现指示灯的状态没有发生变化就知道没有唤醒成功。虽然也能通过设备无响应判断出设备没有激活，但是用户需要等一段时间才能进行判断。你若非要说设备不在用户视线里，用户是色盲，用户没有观察指示灯的状态......那就可以通过声音反馈来判断了。

两者是相结合的不是有我没你。

语音接收很好理解，就是输入语音的过程。这是目前智能设备产品设计中很关键的一步。如果说唤醒是设备使用的开始，那么语音接收则是交流的开始。

语音设备并不是像手机那样的大众产品，能让用户与设备进行交流至关重要。在语音接收时遇到的最大问题是设备无法正确理解用户的指令。也可以说是用户不知以何种方式操作设备。关于这点很多知名厂商做了相应的策略——说明文档可视化。如Siri，如小娜。我们的产品也借鉴了这种方法。

但是有一点貌似大家都忽略了——语音接收场景并非只有唤醒后的语音接收界面。任何一个场景，任何一个在执行或执行过后的界面都是“语音接收”界面。可视化的说明文档帮助用户进入场景，但是进入场景后的下一步操作则没有了这样的提示。用户在不知所措时会想起唤醒界面的可视说明文档，于是他们又用了唤醒词来操作。

所以“帮助文档”应该作为一个帮助系统来考虑。针对新手用户，是不是可以在任何他感到疑惑的界面都加入帮助说明文档的入口；对于专家级用户则可以通过设置隐藏入口。如果界面做不到“傻子见了都会用”的程度就放下心态，耐心的引导。

产品是来用的。

语音识别方面没有相关经验。了解过置信度与N-Best列表相关技术但是并未做过设计，略过不表。

执行反馈分为识别失败与识别成功两种情况。这里的识别失败是指设备接收到了语音，但是无法识别。如用户说的是：“啊嘛吧嗯库卡啦”这种以及因为各种原因超出语音库内容的指令。设备需要给用户一个友好的指令反馈。那么接下来无论是前面说的设备把“张三”识别成了“张山”还是正确的识别到了“今天的天气”都会去执行。

带显示屏的设备执行指令的结果通常显示在“场景”里，可以理解成我们手机上的APP。每次执行结果进入一个APP里，可以返回主页。不过有点不同的是设备主页不像手机一样可以显示出所有应用的启动图标，而是要么是个卡通表情要么是帮助文档。你并不知道你的设备有哪些功能——You know nothing about it（帮助文档场景会显示所有场景及用法）。

当在某一场景中操作完成后可以从当前场景继续执行下一条指令切换到另一场景。如在天气预报场景可以唤醒设备进入百科的场景。但这种方式会出现一个问题：当在听歌时想打开房间里的灯。那设备执行开灯的指令后要回到歌曲场景还是跳转到智能家居的场景？又比如在与家人进行视频聊天时想查看一下天气，视频聊天功能要不要被打断？这需要分场景对待。

产品经理与设计师要经过调研分析出哪些场景是“主场景”，哪些场景可以是被嵌套执行的“子场景”或者说场景在哪些情况下可以被嵌套执行。比如在看视频时想知道当前时间，指令“现在几点了”可以在视频场景嵌套时间的场景；指令“我要看下当前时间”则进入时间场景。

然后是交互方式

目前可用的交互方式有语音交互、触屏交互以及手势交互。

语音交互通过语音的方式与设备进行交流互动。语音交互方式又分为 语音唤醒操作、热词操作、多轮对话操作 三种。

语音唤醒操作顾名思义是用来唤醒设备，是从待机状态通过唤醒词将设备唤醒从而进行一系列的操作。还有一个使用场景就是在场景中通过语音唤醒来打断当前场景的操作既而进行其他操作。唤醒操作的主要特点就是需要一个唤醒词，如“Echo”。在某些场景里如果持续使用唤醒操作很不友好，因此可以使用多轮对话方式。

多轮对话方式更接近人与人之间的交流，可以在场景内实现与上下文相关的操作。比如在翻译场景里，翻译完一个词后想继续翻译下一个词语只需要说出类似“翻译橘子”的指令即可，不需要先通过唤醒词唤醒。

热词操作可以当成唤醒词操作的一种。他是场景内的一种特殊词汇，在需要唤醒场景中用户通过热词可以进行更简单的操作。如听音乐时可以不必唤醒设备直接说“下一首”切换到下一首歌。因为热词所在场景是需要唤醒的场景，所以在这个场景内除非检测到唤醒词或者热词不然不会打断设备的操作。

触屏操作是移动设备常见的操作方式。当语音交互设备所处环境不适合进行语音交互时要允许用户通过触屏方式对设备进行操作。

手势操作在工作及直接竞品中未遇到，暂无更多的研究。

这三种方式应当是相互协作的。不必因为是“语音设备”而非要设计成只以语音交互为主的方式。解决用户的问题是第一位的。当用户在看电视时手机响起，拿起身边的遥控器按下静音键是个很方便的操作。当然，如果此场景中设置了“静音”的热词那用语音来操作也很方便。

最后说两个案例

案例一：使用者是一位27岁刚结婚的美女，名字就叫桂花吧。桂花是个温柔体贴，美丽大方的女人。无奈不怎么会做饭，成家后一直在学习。在学习的过程中桂花习惯做法是在厨房里一边做，一边通过手机查看菜谱（要问桂花为什么不是事先背下菜谱，桂花表示懒得背）。现在让桂花来体验我们的智能语音设备，她的操作是这样的：

1、把设备带入厨房放到一个易于观看的位置。

2、唤醒设备并进入之前已经找好的菜谱场景。

3、按照步骤开始备菜（这时手上会沾满油渍污渍，不方便触屏操作）。

4、放油、炝锅、手动打开抽油烟机（菜谱场景须是唤醒场景不然有可能识别噪音）。

5、按步骤炒菜（通过热词进行翻页）。

6、制作完成，盛盘。

7、关闭燃气灶、抽油烟机、洗手，拿出设备。

8、伴随着音乐吃饭。

这个案例中解决的用户痛点主要是：桂花在做饭过程中不方便用手操作设备（可能会两只手都用来做饭），可以让她通过声音来操作。在菜谱的场景中是不能使用多轮对话模式的。在这样一个嘈杂的环境中如果识别始终开启的话有可能把环境音当成了指令去执行。如果每操作一步都通过唤醒词来完成，考虑到此时的每一步语音操作都需要很大声的喊出，会提高出错率。所以使用热词功能在不需要唤醒的情况下识别“上一页”、“下一页”等简单的词。

案例二：主人公李磊是一名*粉，30岁的单身男士。自己家中有不少*家的设备。今天的活动轨迹如下：

1、周末的早上因为没有定闹钟醒来不知几点（在枕头旁摸索了一下手机没有找到）。

2、翻身冲智能语音设备的方向喊“XX同学，现在几点了？”。

3、听到回复是早上七点，感觉时间还早继续喊道“一小时后叫我”，然后继续睡。

4、八点被闹钟喊醒，通过唤醒词打断闹钟。

5、起床后去洗漱，让随机播放歌曲。

6、出门吃早饭。路上想起智能音箱设备还在唱歌，拿出手机通过APP关闭设备。

7、回家路上通过手机APP打开热水器烧水（非24小时通电）。

8、洗澡的时候想起今天没有打扫卫生，语音控制扫地机器人扫地。

9、饭后躺床上想象要是有个翠花那样的对象该多好。（设备提醒已经晚上十一点了，请按时休息）。

10、在床上通过语音关灯睡觉。

以上就是结合自身经验对智能语音设备的用户群体、使用场景及操作流程的理解。其中有的想法因为没有实践经验及数据支撑会有些理想化。

希望以后能继续从事语音交互相关工作，在实践中去验证这些方法或探索新的可行的解决方案。