驾驶场景下的语音交互

时间: 2021-07-30 10:16:59 人气: 10 评论: 0

驾驶场景下，采用的具体的交互方式是什么呢？使用手，亦或是语音？您觉的哪一种更方便呢？

Why is voice user interface？

先抛出一个问题，试着回忆一下，你在开车时是如何操作导航的？

答案大类上无非两种：

与手机交互；
与车载导航交互。

那么，具体的交互方式呢？使用手，亦或是语音？您觉的哪一种更方便呢？

孰优孰劣暂不下定论，我们试着分析一下语音交互出现的原因。

笔者曾听一位百度云的副总裁说：

『人机交互方式由传统的鼠标，键**转移到了今天的 Touch 交互。而下一个交互方式的重大变革便是语音交互』。

Assume『人终究是懒的吧』，暂把这条设为定理一。

基于该法则可以推出定理二：能让人懒的方法可以获得喜欢。

那么，怎么能让人懒？

降低人的学习成本；
提高人的操作效率。

此时再看 VUI (Voice user interface)，语音交互具有学习成本极低的特点，只要能清楚的用语言表达目的即可。但是 VUI 并不能完全保证提高人的操作效率。

因此，笔者认为：VUI 最高效的应用场景是『用户明确知道任务目标，且语音交互的速度要快于接触式交互』。

以上，我们再回到驾驶场景中。

人有五感——形、声、闻、味、触。从安全驾驶的角度考虑，视线需要长时间观察路况，不宜频繁打野。信息输入层面上，耳『听』更具有优势。

大脑处理信息后，需要进行信息输出。由于双手『触』受限于方向**，再从安全的角度考虑，口『说』的优势又体现出来了。

综上，笔者理解的驾驶场景下的语音交互的适用功能为：司机对任务目标很明确，如：播放某某歌曲，且该任务通过语音操作的效率高于接触式操作。

How to do VUI design?

General Interaction Flow：语音获取 -> 语音处理 -> 信息呈现。

类似于 GUI 设计，设计师需要考虑信息的收集、处理、呈现，只是多了语音这个信息载体。

设计流程如下：

Requirements：明确商业上的需求和用户的需求，进而确定产品的需求；
Flow：从需求出发，梳理出交互流程；
Prompts：针对每一个流程，设计语音提示；
Grammar：针对语音提示，设计语法收集语音反馈；
User testing：完成设计后，通过用户测试手机反馈；
Tuning：针对反馈，进一步完善产品。

Requirements

产品需求定义是决定一个好产品的核心，只有把有限的资源集中在『刚需』功能上，用户最后才**买单。后续一切的设计，开发才有意义。

Requirements design：It is always a balance between business interest and user interest.

笔者认为：盈利导向性产品中，需求设计总是在商业利益和用户利益之间发现一个平衡点。如果涉及到公司政治因素，商业利益也包括领导的利益和团队的利益。

你需要知道公司每个部门的想法是什么，领导的想法是什么？

这是保证项目顺利实施的核心。其次，产品必须要用户获利，否则这个项目本身不具有任何意义，除非你想做官僚式产品。

设计师需要考虑商业、公司、人事、用户等各个方面的问题，理性平衡各方面因素，从而达到一个暂时的最优解。

由于软能力层面不可一概而论，本文后续只从用户体验的角度设计功能。

Flow

当功能确定之后，需要详细梳理功能的流程。流程应该反应功能的优先级，同时，确保用户的每一步操作都有相应的反馈。

笔者觉的在这一步，团队成员之间可以多多交流，多讨论流程有哪些可以优化的地方。尽可能的完善流程，以避免后续改动造成的额外成本。

其次，VUI designer 和 GUI designer 应该在这个阶段就开始多合作。鉴于车载的中控屏幕、Kombi 显示屏和 HUD（Head-up display），一个良好的 GUI 界面对于提升 VUI 的用户体验是至关重要的。

在提示信息，显示信息以及错误提示时，图形界面都可以很好的辅助用户进行语音操作。二者相辅相成，缺一不可。

Prompts

在对话设计中，需要设计师对于该门语言有着深刻的理解，包括但不仅限于：停顿、语调、用词、强调等。

每一门语言都有着其独特的 Prosody，这需要课外进行大量的积累。笔者自觉知识有限，这里仅从信息呈现的角度谈谈如何设计对话。

以下内容参考 Amazon Alexa Voice Design Guide

清晰的告知用户该做什么？
保持简洁；
避免过多选项；
提供帮助选项；
只询问必要问题；
有选择的让用户确认；
一次只处理一条信息；
让用户知道所处上下文；
一次不要呈现过多的信息；
信息可听度；
避免使用专业术语；
错误时再次提示给用户指导；
错误时提供帮助入口；
错误时不要责怪用户；
提前预测错误。

具体案例大家可以查看 Amazon 原文。

笔者这里主要强调 10.信息可听度 和 12.错误时再次提示给用户引导。

（1）信息可听度

VUI designer 写的文字最后**通过 TTS (text to speech) 的技术读出来，因此，看上去没有问题的书面用语有时在读出来时**变得不那么自然。所以，建议设计师把对话大声多朗读几遍，这**非常有助于你感知真实的用户场景。

And of course, your ears will tell you how it works.

（2）错误时再次提示给用户引导

在 Voice：user interface design一书中，作者提到了两种错误提示的方式：一种是完整提示，另一种是快速提示。

区别如下：

完整提示

System：请输入密码？
User：假如用户输错了或不知道密码，此步骤失败。
System：密码错误，请再次输入？如果您忘记密码，请登陆 APP 个人界面重新设置密码。

快速提示

System：请输入密码；
User：假如用户输错了或不知道密码，此步骤失败；
System：密码错误，请再次输入；
User：加入用户操作再次失败；
System：密码错误，请再次输入。如果您忘记密码，请登陆 APP 个人界面重新设置密码，结束操作请说『结束』。

笔者认为：完整提示更倾向于 Memory load 比较大的操作，用户很容易忘记的内容。很大概率上，用户需要完整的提示在指导其进行操作。

反之，快速提示则更适用于 Memory load 比较小的操作，用户误操的可能比较大，因此首次错误提示应该更加简洁，以高效为首要目的。可针对具体应用场景进行选择。

Grammar

语法层面设计到一些复杂的技术，笔者根据技术识别流程简单介绍下。

Recognition flow

判断结束点；
提取有效信息；
识别；
自然语言理解；
对话管理。

（1）判断结束点

End point

从发出声音到结束声音，截取声音**段。

（2）提取有效信息

Feature extraction

通过处理技术，将声波识别成为一个个发音单元。

（3）识别

Recognition

根据 Dictionary 中的发音单元和单词的匹配，将发音单元识别成特定的文字。

（4）自然语言理解

Natural language

通过算法对文字就行处理，理解其想表达的含义。

（5）对话管理

Dialog management

针对此轮对话的含义，从而进一步设计下一轮对话，其中最核心的部分是在识别模型这一块。

Recognition model

目前主要有两大识别模型：Rule based grammar 和 Statistical language model (SLM)。

两种语法的目的都是为了充分理解用户说的内容，从而指导用户进行下一轮对话，区别在于其实现的技术手段。

Rule based grammar 即为人工定义，利用 voiceXML language 手动定义语法的 slots 和 filler。slots 即需要识别的内容，filler 用于帮助定位 slots。

//Example 1
.GETDESTINATION (?PREFILLER CITY ?POSTFILLER)
PREFILLER [ (I want to go to) (I am going to) (I need a flight to) (?I’m going to) ]
CITY [ (new york) (the big apple) (san francisco) ]
POSTFILLER

//Example 2
.GETCITIES (?PREFILLER
[(from CITY: orig to CITY: dest)
(to CITY: dest from CITY: orig)
] {<origin-city $orig> <destination-city $dest>}
?POSTFILLER
)

SLM 则是通过机器学习的算法，基于数据训练出来的自动识别语法。在大数据的背景下，可以实现自然语言理解的功能。其优点是可以允许用户按照自己的想法说出内容，不受限于 Rule based grammar 的有限识别范围。

可以理解为基于人工智能（AI）的语音识别技术。国内比较领先的两大技术提供商科大讯飞和 DuerOS. 其手机端的识别能力，笔者在第一次体验时深深感受到了人工智能震撼。

理解技术背景有助于设计师更好的与工程师进行合作，辅助工程师设计出更人性化的语音识别技术。

User testing

测试这一环节和 GUI 基本一致，可以内部先按功能流程测试，记录下不完善的地方。然后根据用例，小规模组织实际用户进行测试，记录下反馈。并在测试完成后进行 Group research 收集用户更多主观上的感受。

等产品上线后，有了大规模的产品数据后，采用 hotspot analysis，针对使用率高和退出率高的区域进行监听，然后分析其原因。

不同的地方是我们可以在 VUI 的早期测试环节使用 Wizard Demo——即通过环境设置让用户觉的语音是机器识别并进行反馈的。实际上是通过测试员在幕后模拟机器发出的。

Wizard Demo 开发时间短、成本低，同时又能很好的扮演实际产品的测试功能。可以运用在 Prototype 技术成本较高的项目中。

Tuning

润色。

好的产品都是不断迭代而来的，一口气不可能吃成个胖子。针对 User testing 中发现的问题：repeatedly iterate until the end。

Let’s check a sample application

Albert Einstein made the comment, “Example isn’t another way to teach, it is the only way to teach.”

So, 笔者本章用一个案例来说明上个章节的设计方法。

Requirements

车载系统的三大核心功能层面为导航，娱乐和通信。导航本身作为车辆出行的辅助性工具，其重要性犹胜。针对导航功能，其三大核心功能为：搜索、路线、和 LBS(Location based services)。

考虑到车辆的通勤属性，即上下班的使用场景**更为频繁。在此我选择『路线』功能作为 VUI 设计的范例。

功能定义：用户可以通过语音设置通勤地址（家和公司），支持语音唤起，导航至指定目的地。

Flow

Main flow v1

Step 1 语音唤起：可以使用方向** TTS Button 或语音唤起词技术，对语音识别系统进行唤起。比如：『奥迪奥迪』。
Step 2 设置家/公司地址：唤起成功后，此时应该有固定声音提示 earcon，如『叮』。告知系统已触发，请说出内容，可以结合 GUI 共同提示。用户发出设置地址指令，设置环境可能出现错误。
Step 3 语音输入地址：指令发出后，系统识别，然后告知用户语音输入目的地地址。此时需要考虑 prompt 设计，是让用户一次性说出全部地址，还是逐级引导用户输入地址。
Step 4 确认地址：可能存在识别错误，需要用户确认是否是该地址。
Step 5 导航至家/公司：成功设置后，语音提示用户是否要导航至该目的地，若**出 timeout，则用户需要再次唤起并发出导航指定。
Step 6 确认开启导航：系统告知用户大体路况信息，询问用户是否需要开启导航。
Step 7 结束：开始导航，流程结束。

根据以上分析，完善一下流程图：

main flow v2

Promp

Grammar

笔者认为：在技术条件允许的情况下，优先使用SLM进行语音识别，最大可能提升用户操作上的自由度。因此在地址识别上，用户即可以说目的地名称，如：奥迪中国楼；也可以说目的地地址，如：酒仙桥路4号。

但这并不意味着设计师就可以不构思语法部分了，尝试用 rule based grammar 来预判用户操作，对于理解整个交互流程和优化 prmpts 的用户体验都是大有裨益的，即使是用作日后测试 SLM 的样本也是极好的。

笔者写两个基本的案列：

//设置地址POI
.ADDPOI (?PREFILLER 名称 ?POSTFILLER)
PREFILLER [ (设置) (我要设置) (我想设置) (添加) (我要添加) (我想添加)]
名称 [ (家) (公司) ]
POSTFILLER [ (位置) (地址) ]

//输入地址
.GETDESTINATION (?PREFILLER 地址)
PREFILLER [ (地址是) (我想去) (目的地是) (位置是)]
地址 [ (地址名称) (地址详情) ]