語音交互界面的聲音標記

原作者：Kathryn Whitenton ／ 原文章：Audio Signifiers for Voice Interaction ／ 發布時間： 09-10-2017／ 翻譯：小球娘

幾句話概述：語音交互界面需要給用戶提供明確，恰當和非語言性的聲音記號以便讓他們明確所有備選項。

好的語音交互系統要求不僅要對自然語言有優秀的理解，而且應從策略上幫助用戶理解在語音交互中無數的動作和命令分別是什麼。換句話說，我們需要填補執行的鴻溝。這類交互界面的設計挑戰存在於各個領域，但對於語音交互系統來說尤為困難。

執行的鴻溝

如果想成功的跟任何系統打交道，那就必須要（1）了解為了達到具體目的需要做什麼事情 （2）需要理解做了這些事情之後的結果。在Don Norman的書《The Design of Everyday Things》中已經詳盡的描述過這些需求，他把它們定義為執行的鴻溝和衡量判斷的鴻溝。這兩者都很重要，但本篇文章集中討論執行的鴻溝，和語音操作界面系統如何幫助用戶理解有哪些可執行的操作選項。

在一個圖形界面交互系統（GUI）里，設計師可以通過提供視覺線索來填補執行的鴻溝。比如，把可點擊的鏈接換成別的顏色。當處理的好的時候，這些方法可以讓用戶在瞟一眼之後就明白哪些是可執行的操作。相反，研究表明如果不重視這些圖形界面標記的作用，則可能導致執行任務的時間拉長，並且造成界面的不明確和模糊性。

在沒有視覺標記的情況下，用戶需要想像，或試圖記憶所有可選的命令——這兩種情況都會增加認知負擔，並且增加使用界面的難度。設計語音交互系統的設計師有可能幫助用戶最小化這些問題，方法就是，為最重要的信息命令提供一些聲音記號。

概念：一個聲音交互標記指的是系統提供給用戶的交互線索，幫助他們明白可以發出什麼命令的聲音線索。

無論聲音或視覺元素都可以用來標註聲音指令選項。當有顯示屏時，一般來說最好使用視覺標記，但並非所有界面都有顯示屏。本篇文章集中討論聲音標記，比如在智能手機平台上裝載的個人助手——Siri，Google Now，Cortana；還有單獨系統——如Amazon的Echo，谷歌的Home等。

聲音標記的類型

有三種類型的聲音標記／線索可以用來祈使用戶發出命令或告知當前可用命令：

1. 非語言類聲響，或叫作聲標（聲音的圖標）指系統產生的特殊音效，一般伴隨著某些特殊操作或狀態。比如，Siri會在被激活後發出2聲「嗶嗶」，提示它開始「聆聽」指令了。

2. 明確的語言標記，指的是當系統把一個可選命令讀出來讓用戶知曉的方式。比如，如果你對谷歌「Home」說「設置一個倒計時鬧鐘」，它會回復「好的，需要設置多久？」

3. 含蓄性語言線索，指的是系統不使用鄭重其事的方式，而是給出含蓄的線索來提示用戶某項操作可執行。比如，當Amazon的Echo正在播音的同時探測到了一個喚醒辭彙，它會通過暫停自己的播音進程讓用戶知道它進入了可「聆聽」新指令的狀態。這個行為是對人類會話行為的模仿，因為人們會通過暫停說話的方式來告知對方他們願意開始聆聽對方意見。

非語言類聲響

聲標，或者稱交互界面的聲音線索，就類似於圖形交互界面中的視覺圖標——因為兩者都試圖在不使用辭彙的情況下與用戶進行有效率的溝通。就像一個垃圾桶圖標比一個帶有「刪除」二字標籤的按鈕所佔的屏幕面積小一樣，「嗶」的一聲響比完整的一句話「你有一條新消息」所用的時間更少。

然而聲標或圖標帶來的效率都建立在用戶真正理解它們所要傳達的意義之上。由於圖像表意的模糊性，視覺圖標經常會帶來使用性問題；而聲音圖標就更難懂了，因為它們不能使用辭彙或圖像來傳達意思。當你試圖根據視覺圖標創造相應的聲音圖標的時候，這個問題會快速顯現出來。

例如，視覺圖標可以分為象形、通感、或賦義幾類，取決於圖形如何跟其代表的操作相聯繫。象形圖標看起來就是它們所進行的操作：一個垃圾桶的形象跟實際生活中裝垃圾的容器外表相同。一個代表「刪除」動作的象形聲標可以是一聲「咣」，用來模擬把東西扔進鐵罐里的響聲。但是，「咣」的一聲聽起來也可以像很多其它噪音——如兩個物品相撞，或把一個物件放到擱架上。

當使用聲標來通感一個概念時，它會變得更加模稜兩可。比如，牛「moo」的叫聲可以用來代表「牛奶」的概念，（在這裡用「moo」的牛叫聲來代表跟牛的某種聯繫，而非代表牛本身。）但如果讓用戶單單基於「moo」的牛叫聲來猜測其相應的操作，那麼這種處理可能對遊戲界面來說比對網上購物界面更合適。

由於這種非語言類聲音的模糊性，大多數聲標都被用作聲音賦義的用途，即便它是在試圖描摹一個特定操作。賦義類的聲音可以吸引注意力，但只能在特定條件下傳達特定意思：

• 在一個任務情形當中：當聲標緊接著用戶的某個操作產生，用戶便會慣性的認為它跟這個命令相聯繫。比如，播放「咣」的聲音可以作為用戶確認一個項目已被刪除的確認標誌。
• 重複出現：隨著時間推移，用戶可以認識到某個聲音被賦義表示一個來電，而另一個聲音的意思是有一條新簡訊。

然而，即使在反覆出現的情況下也不能保證用戶可以認出不同的賦義聲音。就像我們絕大部分人都數以千次的聽過電話撥號時各個數字相對應的聲音，但讓你說出哪個聲音相對應的是哪個數字是極為困難的。

聲音標誌也是一種單方向溝通：系統可以播放「咣」或「嗶」的聲音給用戶，但用戶沒法發出相應準確的聲音作為指令回復。

由於以上這些限制條件，聲標主要在範圍狹窄和高重複性的情境中使用（例如，作為經常性指令的確認信號）或用於一般性的吸引注意力。但是，在大多數情況下，它們沒法傳達足夠多的信息，必須跟語言性標記配合使用（或被其替代）。

語言記號：平衡使用詳述性和含蓄性線索

詳述性線索是最易懂的聲音標記，它以具體問題或建議的形式存在。但是在詳述性標記讀出所有可選項時可能變得非常啰嗦——問問聽讀屏幕的用戶就知道了。除了被叨擾以外，冗長的語言性列表效率十分低下，因為人們沒法記住所有選項。（試想電話菜單里列出了10個部門名稱，當你聽到第5個時還記不記得第1個是什麼）

詳述性聲音標記在像購物過程這種不可逆的操作中非常重要，但是在其它很多環境下，對這類強勢的詳述性標記的使用和對效率的要求可以通過一些特殊技巧來達成平衡：

• 猜測和確認用戶意圖
• 提供含蓄性線索而不是詳述性描述
• 將詳述性線索劃分成連續而清晰的短對話
• 逐層開啟的線索，並只在用戶需要的時候進行描述

猜測和確認

猜測用戶的意圖可以得出最有效率的交互方式——但只在系統具備足夠的信息來做高質量的猜測時才行。比如，當你命令Echo打開音樂播放軟體Pandora的時候，系統直接播放最近播放站點，而非先問用戶播放哪個站點。因為站點信息是用戶之前選擇過的，那麼有很大概率這個選擇仍然適用。

另一方面，不準確的猜測會讓交互過程變慢，因為在一個不準確的猜測之後，用戶還要額外考慮如何糾正系統的假設。

例如，試想一個場景下，用戶需要通過語音交互系統來「預約一個九點的會議。」 這個看似簡單的任務需要若干個不同的後續問題和命令，比如確定人員名單，日期，早9點還是晚9點，包括調節以上這些項目的值，最後存儲這個預約。下面描述了四種不同的語音交互系統如何完成這個任務，其中系統發出的陳述標為粗體：

各個語音系統對用戶「設定一個9點的預約」的回復：

• 谷歌

預約名稱是什麼？

理髮

好的，明天上午9點理髮。你想存儲這個預約嗎？

好

好的，預約已存儲。

• Echo

是早9點還是晚9點？

早上

哪天？

周四

預約的名稱是？

理髮

那麼預約8月24日周四的上午9點去理髮，好嗎？

好

好的，已存。

• Cortana

你想把預約叫什麼？

理髮

我把今晚9點理髮加進你的日曆中，好嗎？

不，改到明天早上9點

對不起，我是否應該把預約加進你的日曆？

不

你想改變預約的名稱還是時間？

時間

什麼時候？

明早9點

好的，我會把明早9點理髮加進你的日曆，好嗎？

好

沒問題。

• Siri

好的，我把會議安排在今晚9點，可以嗎？

不，改到明早9點

繼續下一步，你可以確認，取消，改時間或改預約的名稱。

改時間

你預約的時間是？

明早9點

好的，我把會議安排在明早9點，可以嗎？

改名稱

好的，會議的新名稱是？

理髮

好的，我把會議定在明天，可以嗎？

好

已在你日曆上確認明早9點。

對這項預約名稱的猜測會失敗是在所難免的，只有一個系統對此中招：就是Siri, 它把這個預約直接命名為「會議」。其它系統都使用了問題形式的詳述性標記來引導用戶填充預約的名稱。對於日期和時間，4個系統中的3個都做出了猜測。Siri和Cortana都使用了離得最近的將來時日期和時間，但谷歌把這個猜測定在第二天。雖然這些都是說得通的猜測，但它們都很容易可能是錯的，然後就需要用戶來想辦法編輯這些信息。看起來，谷歌在這次測試的事情上猜對了，於是它的交互流程成為最短的，但它也極有可能是錯的，那麼之後就會引出更多的對話。（考慮基於巨量會議安排數據之上的機器學習的話，可能會在不同情形中帶來更高的猜對可能性）

不幸的是，無論是Siri還是谷歌都沒能給出任何修改預約的標記，而是直接跳到詳述性引導來存儲這個預約的細節。這個問題的出現是因為「我可以預約嗎？」和「你想存儲嗎？」這兩個問題都可以用是／否來回答，而不含有可以編輯事件信息的可能性。兩個系統都允許修改編輯命令，但都得依賴用戶去自主發現這個選項。其實編輯命令的信號可以用多問一個問題來表示——比如「你想修改這個預約嗎？」 —— 但這當然也會給任務增加額外的步驟。

含蓄性標記

使用含蓄性標記來代替詳述性標記可以在不增加交互時長的基礎上有效的驅使人們進行編輯。含蓄性標記通過模擬人類發展出來的更加有效的信息交換方式來建議命令，在陳述的最後加上一個疑問詞就屬於這類模式。例如，Cortana和Echo都在確認指令的最後加上了疑問詞：

將疑問詞用作含蓄性標記

Cortana：我把今晚9點理髮加進你的日曆中，可以嗎？

Echo：預約8月24日周四的上午9點去理髮，好嗎？

在系統產生的語言最後加上含蓄性疑問標記來讓用戶明白他們可以更改預約。

這些陳述會在存儲事件時發出詢問，但含蓄性標記的確認辭彙（「可以嗎？」， 「好嗎？」）是附加在同一條陳述的最後，緊接著對事件細則的描述。這個位置，加之其寬泛的語義，感覺像是系統不僅僅在詢問是否要存儲，也在詢問整條敘述的準確性。（不幸的是，針對這個詢問Cortana只接受是或否的回答。只有在回答「不」以後，用戶才能等待下一條詳述性標記的信號出現來更改信息。）

邏輯性的詳述性標記

從理論上來說，把若干個祈使命令合成一個單獨命令可以節約信息交換的時間，例如使用詢問語句：「事件的名稱，時間和日期是什麼？」。但是，這類祈使問句增加了用戶的認知負擔，因為他們要記住三個不同的問題，並一次性給予回答。在實際應用中，這類由於增加認知負擔而帶來的錯誤和糾錯的時間，差不多跟對三個問題分別進行詢問所用的時間對等或更多。

Echo在上面提到的對話中示範了一種有邏輯的詳述性標記的解決方案：關於事件名稱，時間，日期的三個問題分別有三個對應回答。正像舉例中提到的，可能使用這種策略最後得出的結果比把問題揉在一起問而造成誤猜和修正來的更有效率——特別是對於萬一由於遺漏祈使標記而造成錯誤的情況。

另外，記住並非所有用戶都會被詢問所有問題。那些提供的指令里含有更多細節的人，如「周四上午9點預約一個叫作理髮的會議」，就可以在以上任意系統里僅僅確認一次就成功的完成任務：

含有細節的命令=更少的步驟

用戶：Alexa，周四上午9點預約一個叫理髮的會議。

Echo：就是說周四8月31日上午9點理髮，對嗎？

用戶：對。

Echo：好的，已經預約。

如果用戶在初始命令里提供所有的必要信息，Echo的事件預約對話就不包含後續問題。

逐層開啟的線索

逐層開啟的方式是只有在用戶的行為顯示出他們需要某些命令的時候，才提供出那些不常用的選項。例如，Siri首先用詳述性提示來讓用戶存儲事件，只有在用戶表示否定後，Siri才提出若干其它命令，她說：「繼續下一步，你可以確認，取消，更改時間，或者更改名稱。」

分清主次關係對於好的逐層開啟方式來說至關重要，並據此選擇哪個功能應當作為主要功能而首先顯示或應當隱藏作為次要功能。分清主次對語音交互界面系統比對圖形界面交互系統更加重要，因為它要求人們聆聽大聲播出的語音選項，由於缺失了明顯的「查看更多」提示符，那些推遲出現的選項會顯得更加隱蔽。（若有達成共識的「查看更多」聲標存在的話，對語音界面系統來說將非常方便，可惜還沒有。）

考慮到Siri在關於創建事件的對話中，只能基於非常少量的數據信息來猜測其名稱，日期和時間，大多數用戶都需要針對這一任務進行更多編輯。因此，在這種情況下把一個常用命令作為次級選項並且連含蓄標記也不予提供，那將會反而導致增加交互時長。

對於那些包含支線的複雜任務來說，逐層開啟的線索可以幫助用戶把精力集中在跟當前步驟最為相關的事情上。谷歌的Home就使用這個技術來提供一步接一步的烹飪說明。在這裡，系統會詢問：「你想開始準備食材，還是直接開始烹飪？」如果用戶要求準備食材，他們將聽到另一條更進一步的關於準備食材的具體選項：「共有7種食材，我們按照三個一組進行解釋，還是一個一個的解釋？」 但是，這一選項只對選擇了「準備食材」任務的用戶播出，因為對於想跳過這部分直接到烹飪說明的人來說，這些問題都是不相關的。

結論

語音交互界面想要好用，必須將完成一個操作的時間最小化。主要是因為聆聽語音選項比掃視菜單花費的時間更長，用嘴說出有聲指令也比直接按動按鈕花費時間更長。然而，若要為了節省時間而跳過重要的聲音標記則更加事倍功半：如果一項任務最終失敗，那麼它的用時再短也沒有意義。

猜測，含蓄性標記，邏輯性標記，逐層開啟的標記對語音指令來說都是讓其加速的策略——特別是對次要的或是可逆轉的指令來說。這些方法有時候可以變得非常高效從而正好填補執行的鴻溝。但是，設計這些指令必須非常小心，確保它們是縮減了交互時間，而不是由於造成各種錯誤而延誤了時間。

——————————————————————————

小球娘的話

最近有點忙，手上的項目是有關於手機端sms推送的內容，最近要找些相關文章做做研究，遇見好的話會陸續推薦給大家。