日韩人妻无码中文字幕一区,欧洲熟妇色ⅩXXXX欧美老妇

搜索

APP

起點課堂會員權益

職業體系課特權

線下行業大會特權

個人IP打造特權

30+門專項技能課

1300+專題課程

12場職場軟技能直播

12場求職輔導直播

12場專業技能直播

會員專屬社群

榮耀標識

發布

注冊 | 登錄

駕駛場景下的語音交互

Aine

2018-05-13

3 評論 9395 瀏覽 76 收藏

21 分鐘

駕駛場景下，采用的具體的交互方式是什么呢？使用手，亦或是語音？您覺的哪一種更方便呢？

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：加入用戶操作再次失?。?/li>
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 [ (地址是) (我想去) (目的地是) (位置是)]
地址 [ (地址名稱) (地址詳情) ]