駕駛場景下的語音交互

Why is voice user interface?

先拋出一個問題，試著回憶一下，您在開車時是如何操作導航的？

30s 。

答案大類上兩種：

1. 與手機交互

2. 與車載導航交互

那麼，具體的交互方式呢？

使用手，亦或是語音？您覺的哪一種更方便呢？

孰優孰劣暫不下定論，我們試著分析一下語音交互出現的原因。

筆者曾聽一位百度雲的副總裁說：『人機交互方式由傳統的滑鼠，鍵盤轉移到了今天的 Touch 交互。而下一個交互方式的重大變革便是語音交互』。

Assume『人終究是喜歡懶的吧』。暫把這條設為定理一。

基於該法則可以推出定理二: 能讓人懶的方法可以獲得喜歡。

那麼，怎麼能讓人懶？

1. 降低人的學習成本

2. 提高人的操作效率

此時再看 VUI (Voice user interface)。 語音交互具有學習成本極低的特點。只要能清楚的用語言表達目的即可。

但是 VUI 並不能完全保證提高人的操作效率。因此，筆者認為：VUI 最高效的應用場景是『用戶明確知道任務目標，且語音交互的速度要快於接觸式交互』。

以上，我們再回到駕駛場景中。

人有五感 — 形，聲，聞，味，觸。從安全駕駛的角度考慮，視線需要長時間觀察路況，不宜頻繁打野。信息輸入層面上，耳『聽』更具有優勢。

大腦處理信息後，需要進行信息輸出。由於雙手『觸』受限於方向盤，再從安全的角度考慮，口『說』的優勢又體現出來了。

綜上，筆者理解的駕駛場景下的語音交互的適用功能為：

司機對任務目標很明確，如：播放某某歌曲，且該任務通過語音操作的效率高於接觸式操作。

How to do VUI design?

General Interaction Flow: 語音獲取 -> 語音處理 -> 信息呈現。

類似於 GUI 設計，設計師需要考慮信息的收集，處理，呈現。只是多了語音這個信息載體。

設計流程如下：

1. Requirements: 明確商業上的需求和用戶的需求，進而確定產品的需求
2. Flow: 從需求出發，梳理出交互流程
3. Prompts: 針對每一個流程，設計語音提示
4. Grammar: 針對語音提示，設計語法收集語音反饋
5. User testing: 完成設計後，通過用戶測試手機反饋
6. 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

1. 清晰的告知用戶該做什麼
2. 保持簡潔
3. 避免過多選項
4. 提供幫助選項
5. 只詢問必要問題
6. 有選擇的讓用戶確認
7. 一次只處理一條信息
8. 讓用戶知道所處上下文
9. 一次不要呈現過多的信息
10. 信息可聽度
11. 避免使用專業術語
12. 錯誤時再次提示給用戶指導
13. 錯誤時提供幫助入口
14. 錯誤時不要責怪用戶
15. 提前預測錯誤

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

筆者這裡主要強調 10.信息可聽度 和 12.錯誤時再次提示給用戶引導。

信息可聽度

VUI designer 寫的文字最後會通過 TTS (text to speech) 的技術讀出來。因此，看上去沒有問題的書面用語有時在讀出來時會變得不那麼自然。所以，建議設計師把對話大聲多朗讀幾遍，這會非常有助於你感知真實的用戶場景。

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

錯誤時再次提示給用戶引導

在 Voice: user interface design 一書中，作者提到了兩種錯誤提示的方式。一種是完整提示，另一種是快速提示。

區別如下：

//完整提示System: 請輸入密碼？User: 假如用戶輸錯了或不知道密碼，此步驟失敗System: 密碼錯誤，請再次輸入？如果您忘記密碼，請登陸 APP 個人界面重新設置密碼。//快速提示System: 請輸入密碼？User: 假如用戶輸錯了或不知道密碼，此步驟失敗System: 密碼錯誤，請再次輸入？User: 加入用戶操作再次失敗System: 密碼錯誤，請再次輸入？如果您忘記密碼，請登陸 APP 個人界面重新設置密碼。結束操作請說『結束』

筆者認為，完整提示更傾向於 Memory load 比較大的操作，用戶很容易忘記的內容。很大概率上，用戶需要完整的提示在指導其進行操作。

反之，快速提示則更適用於 Memory load 比較小的操作，用戶誤操的可能比較大，因此首次錯誤提示應該更加簡潔，以高效為首要目的。

可針對具體應用場景進行選擇。

Grammar

語法層面設計到一些複雜的技術，筆者根據技術識別流程簡單介紹下。

Recognition flow:

1. 判斷結束點
2. 提取有效信息
3. 識別
4. 自然語言理解
5. 對話管理

判斷結束點

從發出聲音到結束聲音，截取聲音片段。

提取有效信息

通過處理技術，將聲波識別成為一個個發音單元。

識別

根據 Dictionary 中的發音單元和單詞的匹配，將發音單元識別成特定的文字。

自然語言理解

通過演算法對文字就行處理，理解其想表達的含義。

對話管理

針對此輪對話的含義，從而進一步設計下一輪對話。

其中最核心的部分是在識別模型這一塊。

目前主要有兩大識別模型: 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.

Sample Application

Albert Einstein made the comment, "Example isnt another way to teach, it is the only way to teach."

So, Lets check a sample application.

Requirements

車載系統的三大核心功能層面為導航，娛樂和通信。

導航本身作為車輛出行的輔助性工具，其重要性猶勝。

針對導航功能，其三大核心功能為搜索，路線，和 LBS(Location based services)。

考慮到車輛的通勤屬性，即上下班的使用場景會更為頻繁。在此我選擇『路線』功能作為 VUI 設計的範例。

功能定義：用戶可以通過語音設置通勤地址（家和公司），支持語音喚起，導航至指定目的地。

Flow

• Step 1 語音喚起：可以使用方向盤 TTS Button 或語音喚起詞技術，對語音識別系統進行喚起。比如：『奧迪奧迪』。
• Step 2 設置家/公司地址：喚起成功後，此時應該有固定聲音提示 earcon，如『叮』。告知系統已觸發，請說出內容，可以結合 GUI 共同提示。用戶發出設置地址指令。設置環境可能出現錯誤。
• Step 3 語音輸入地址：指令發出後，系統識別。然後告知用戶語音輸入目的地地址。此時需要考慮 prompt 設計。是讓用戶一次性說出全部地址，還是逐級引導用戶輸入地址。
• Step 4 確認地址：可能存在識別錯誤。需要用戶確認是否是該地址。
• Step 5 導航至家/公司：成功設置後。語音提示用戶是否要導航至該目的地。若超出 timeout, 則用戶需要再次喚起並發出導航指定。
• Step 6 確認開啟導航：系統告知用戶大體路況信息。詢問用戶是否需要開啟導航。
• Step 7 結束：開始導航，流程結束。

根據以上分析，完善一下流程圖。

Prompts

針對 flow 的每一環節，設計相應的對話提示，注意運用 Amazon Alexa 總結出的法則。

提示編號 | 提示目的 | 提示內容

--- | --- | ---

001 | 地址識別提示| 您好，請說出您家/公司的地址

002 | 地址識別錯誤 | 抱歉，請說出您家/公司的地址

003 | 提示 help | 您可以說『幫助』查閱使用手冊

004 | 結束 help | 結束操作，請說『結束』

005 | 地址確認提示 | 您家/公司的地址是『名稱』，位於『詳細地址』

006 | 導航確認提示 | 距離家/公司『多少公里』，預計行駛時間『行駛時間』，是否開始導航

007 | 導航開始提示 | 導航已開始

Grammar

筆者認為在技術條件允許的情況下，優先使用 SLM 進行語音識別，最大可能提升用戶操作上的自由度。因此在地址識別上，用戶即可以說目的地名稱，如奧迪中國樓。也可以說目的地地址，如酒仙橋路4號。

但這並不意味著設計師就可以不構思語法部分了，嘗試用 rule based grammar 來預判用戶操作，對於理解整個交互流程和優化 prmpts 的用戶體驗都是大有裨益的。即使是用作日後測試 SLM 的樣本也是極好的。

筆者舉兩個基本的例子。

//設置地址POI.ADDPOI (?PREFILLER 名稱 ?POSTFILLER)PREFILLER [ (設置) (我要設置) (我想設置) (添加) (我要添加) (我想添加)]名稱 [ (家) (公司) ]POSTFILLER [ (位置) (地址) ]//輸入地址.GETDESTINATION (?PREFILLER 地址)PREFILLER [ (地址是) (我想去) (目的地是) (位置是)]地址 [ (地址名稱) (地址詳情) ]

User testing

筆者找了幾位朋友對語音對話流程和語音提示進行了簡單的測試，重點是大聲讀出來，反饋如下。

反饋編號 | 反饋內容 | 修改

--- | --- | ---

001 | 『說出』讀起來怪怪的 | 您好，您『家』/『公司』的地址是

002 | 『說出』讀起來怪怪的 | 抱歉，您『家』/『公司』的地址是

004 | 結束 help 格式和幫助 help 不一致 | 您可以說『結束』終止操作

006 | 應該是距離當前位置更符合語境 | 距當前位置『多少公里』，預計行駛時間『行駛時間』，是否開始導航

Tuning

結合 user testing 的結果，結合 GUI 的輔助，第一版完整的流程如下。

1. 路線場景下喚起系統：Eercon "叮"

2. 用戶語音指令輸入：設置公司的地址

3. 系統反饋：您好，您『公司』的地址是

4. 用戶語音指令輸入：奧迪中國樓

5. 系統識別錯誤：抱歉，您的公司地址是

6. 用戶再次語音指令輸入：奧迪中國樓

7. 系統識別正確：您公司的地址是奧迪中國樓，位於798酒仙橋路2號，是否確認

8. 用戶確認公司地址：是

9. 用戶語音指令輸入：導航去公司

10. 系統識別，開啟導航：公司距當前位置3公里，預計行駛時間20分鐘，是否開啟導航

11. 識別錯誤2次以上是，顯示幫助信息：您可以說『幫助』查閱使用手冊，『結束』終止操作

To be continued

想要設計一個優秀的語音交互功能，以上筆者所述只是最基本的入門知識。每一個模塊都還有大量的知識需要學習。

尤其考慮品牌建設，類似於 GUI, 你的 VUI 的設計理念和設計特色是什麼？如何讓用戶『一耳就聽出』這是你設計的？地圖導航中名人語音包就是一個好的嘗試。

因此，針對目標用戶群體，產品聲音的 persona definition 是必不可少的。若最終想提供用戶一種和真人對話場景感，這個說話的人是誰就需要好好琢磨了。年齡，性別，職業，口音，語速，用詞...

當用戶有一天分不清真人語音和機器語音的那天，除了人工智慧帶來的細思極恐外，陪聊產業的紅紅火火，恍恍惚惚似乎也是冥冥註定的吧。

Reference

• Voice: user interface design
• Alexa skills kit

2017年10月23日分割線

Iteration

VUI 和 GUI 一樣，需要不斷反覆的迭代。因此筆者使用 Origami 和 AE 模擬一個完整的交互流程，在做高保真原型的過程中發現2點可以進一步優化的地方。

1. 狀態的變化：監聽中，識別中，處理時。三者分別對應不同的狀態，需要在 VUI 頁面中提現出來。
2. 確認的使用：由於 VUI 的指令明確性，當處理結果唯一，且結果僅對操作發生影響時，直接觸發操作，無需用戶確認。

https://www.zhihu.com/video/906648148338966528

2017年10月26日分割線

Reiteration

在給小夥伴看過 Demo 後，有以下幾點反饋：

1. 語音對話上下文不足，設置公司地址語音改為『好的，您要設置在哪裡』
2. 公司地址設置成功的反饋不夠明顯，語音改為『已將公司地址設置為』
3. 不看屏幕，純語音交互的 Earcon 提示不足，在關鍵位置補加 Earcon

Demo 修訂版