語音交互產品的設計原則

在上一篇文章中，我們簡單了解了一下“語音交互”的相關發展歷程，以及實現原理等，那么此次我們落實到產品本身，來談談“語音交互產品”在設計、制作時的相關原則。

語音交互所滿足的需求

語音交互能滿足用戶怎樣的需求？或者說，我們在設計一款“語音交互類產品”時，應著重考慮哪些方面的“痛點”？

1. 快捷性

以定鬧鐘為例，目前我用的是IPhone7，我如果想通過傳統方式定鬧鐘，我的流程是：亮屏-上劃打開控制欄-點擊圖標-選擇鬧鐘-定鬧鐘-結束（因為我的控制中心沒有添加鬧鐘，而是秒表，所以需要多一步驟）。而如果通過語音助手，我只需要：嘿，Siri（啟動Siri）-幫我訂一個明早8點的鬧鐘-結束。

因此“語音交互”所需要滿足的很重要一點就是操作便捷性，能動動嘴皮子就解決的事，往往會比動手來的輕松很多。若是一款語音交互產品，給用戶的感覺就是我說了半天都解決不了我的需求，還不如我直接點手機來得快，那無疑它是失敗的。

2. 安全性

最直接的場景——開車。雖然明文規定開車的時候不許接打電話，但實際生活中仍有很多人還是會在駕駛途中接電話。即使有耳機，在有電話接進來的時候往往也需要我們再按一下相應的按鍵，才能接聽。但在有“語音助手”的情況下，我們也許只需要說一聲“接聽”就可以了。包括我們臨時有急事想要撥打電話給別人時，同樣可以滿足對應需求。

因此在很多時候，如果產品的語音交互功能完善，就可以為用戶解決很多煩惱，同樣也可以避免很多安全事故的發生，因為這個時候人的注意力不需要再集中在操作設備身上，只需要簡單說幾句話就可以解決一切。

3. 差異性

“語音交互產品”更可以解決不同設備之間的信息流轉問題，這就是未來的智能家居概念，通過語音來控制所有的家具設備。因為不同的設備在輸入方式的選擇上可能會存在差異，比如：有些是按鍵，有些是觸摸等，但如果所有家具都能利用“語音交互”來完成相應的控制，那一切就會隨心所欲很多，而需求往往同樣對應著合適的場景。

適合語音交互的場景

目前很多的現有場景其實都適合添加“語音交互”的元素進去，所以我們簡單地將其概括為三方面。

1. 追求高效

高效性適用于很多場景，比如辦公場景：給XXX發送一封郵件，郵件內容是***；比如生活場景：我要去某地，請從我當前所在位置為我找一種時間最短的出行方式。諸如此類還有很多，用戶追求的就是足夠的快速，足夠的方便。講一句話需要多久呢？

2. 偏向執行

結果導向，用戶關注的是事情或者命令執行的結果，并不關心過程。比如：用戶想要查詢他買的股票是漲了還是跌了，對他來說也許關心的只是最后呈現的這么一個結果，那他只需要通過語音助手詢問即可獲知。因為本身通過“語音交互”執行命令時，用戶就已經放棄了操作的過程，設備已經把所有的過程通過用戶的一句話給省略了。

有些時候我們在進行網上購物的時候，也許用戶就不會選擇用“語音助手”來做推薦，因為大部分的用戶樂于享受瀏覽琳瑯滿目的商品的過程。但同樣也有很多時候用戶只想快點結束過程，好達到目的，比如獲知天氣、定鬧鐘、查路線等。此種場景也多見于“工具型”產品中。

但基于目前的一個技術限制，“語音交互”功能本身也是偏向結果的，即用戶較難從一次語音交互過程中獲得什么享受。

3. 設備優勢

即可以通過語音來實現遠程控制設備，我們不需要去觸摸設備，不需要有其他操作，只需說一聲，設備就能運轉起來。也許是簡單的讓放在桌上的手機設置一個鬧鐘，也許是讓家中的電器開始運作。通過“語音交互”，我們確實能消除很多由于空間而帶來的限制。

那基于此，有適合“語音交互”發揮其功能的場景，同樣會有不適合語音交互的場景。

不適合語音交互的場景

場景大致也分為三種：

1. 嘈雜環境

在這個時候，影響的主要就是ASR（語音識別）與TTS（文本到語音）這兩個環節，一個是人對設備說話，還有一個是設備反饋給用戶聲音。如果環境很吵鬧，首先就會影響機器聽取用戶的聲音，在將語音轉文字這一環節就容易產生偏差，直接導致后續的“自然語言環節”出錯，從而毀壞接下來所有的流程。

而同樣，周圍聲音吵，機器有反饋用戶也可能聽不清，從而也容易對機器發出的聲音產生誤解。

其實這點在日常生活中就能明白，如果周圍很吵，一般不會有人還會去使用“語音助手”。

2. 交流發散

這個主要是考慮到目前的一個“語音交互”技術發展的程度，現在我們絕大多數時候使用相關的語音助手，目的一般都是很明確的。解決一個問題或者制定一個任務，往往是結果導向，只要設備實現了我的這么一個要求，那么這次“語音交互”就可以算是成功的。

而“交流發散”指的是什么呢？

它主要說的是用戶與設備如兩人閑聊一般聊天，即交流沒有目的性，這樣子的對話產生的內容是呈發散性的，生活中的例子，比如：“調戲Siri”，很多用戶用各種話來測試Siri，期待一個回答。但由于目前的技術限制，語音交互還遠遠無法實現“交流”，即如果用戶注重過程，那么其實是沒那么理想的。

3. 過長流程

這一點上其實與“交流發散”都有點類似，即追求結果，那么勢必過程就會變得其次。因此如果用戶在使用“語音交互”時流程過長，往往會得到不好的體驗；或者說，本身這個指令的過程就是比較冗長的，以目前的技術也許根本不適合采用“語音交互”技術。

其他不適合的場景其實還有很多，比如：重視視覺效果的場景。“點外賣”，雖然我們之前經常會用這個來舉例，但就現在來說，如果使用語音助手點外賣，稍稍顯得有點沒必要。

因為我們點外賣，包括購物，其實很看重視覺體驗，你總不能光靠聽聲音就知道這個商品的成色等，而且同時本身它的流程也比較長，可能還包括手動確定訂單、支付金額（也許會有聲紋認證）等步驟，還無法完全依靠“語音交互”來實現。

之前我們一直說，就目前的“語音交互”的應用來說，往往能實現的功能都是偏結果型的，因此一段語音交互對話，其實是帶著目的性的（與設備產生互動其實也是帶著“消遣時間”的目的），或者說，設備是帶著任務來與用戶產生此次對話的。

任務型對話的概念

任務型對話：其目標是為了達成用戶所希望完成的任務，滿足用戶有直接目的的需求。（如：定鬧鐘、查路線等）

在這里，可以將這么一段“任務型對話”簡單分成三個部分：

1. 意圖定義

設備需要分析用戶想要干嘛，也就是理解用戶需求。只有在充分理解用戶需求的基礎上，才能設計出一款成功的產品。基于這個道理，同樣要建立在理解用戶想法上來去開展接下來的對話流程。

2. 槽位定義

“槽位”是什么？

在“語音交互”中，它可以被理解為“關鍵字”，設備想要完成執行用戶所下達的任務，它必須清楚地知道這個任務究竟是什么，這就涉及到對一段話中槽位的匹配。

我們舉兩個例子：

（1）定鬧鐘——“我要定個鬧鐘”

很顯然，這是不完整的，給你定什么時候的？幾點的？

在這里，時間的槽位就是缺失的，導致設備無法執行命令。

好，那這個時候，用戶說“給我定個八點的鬧鐘”。這時候完整了嗎？其實還是沒有完整，因為不知道是早上八點還是晚上八點，時間的槽位依然沒有明確定義，這次的任務依然無法執行。

最后用戶說“給我定一個明天早上八點的鬧鐘”，這個時候，相應的槽位就補充完整，可以正常執行。

（2）打電話——這也是我們很常用的的“語音交互”功能。

用戶說“我要打個電話”，同樣，打電話給誰？電話對象這個槽位缺失。

接下來，是“給李四打個電話”，這么一看貌似已經沒錯了，對象也有了，具體指令也有了，但其實還是存在隱患，萬一用戶的手機是雙卡的呢？其實任務依然無法執行，因為設備不知道用戶會選擇哪張卡來進行撥號，也許可以提前設置默認號碼，但同樣這也是槽位之一。

而且很多用戶也許會給自己的聯系人設置備注，或者出現同名的情況，比如：用戶手機里有兩個叫李四的聯系人，這時候設備還應該去詢問“要撥打給哪個李四”。

因此在設計這么一款語音交互產品時，就槽位判斷的準確性是很重要的，一旦產生誤解，或者對槽位未精確定位，相關操作就無法執行。

3. 流程分支

這個就和槽位定義相互關聯，因為在一場“語音交互”過程中，順利的話也許用戶一開始就把所有槽位都說到了，那么設備就可以直接執行命令。如果出現槽位缺失，那么設備這時候就應該提示用戶補充相應的槽位。

但流程分支，不光包括“槽位缺失”這一情況，還會存在“增加指令”（如用戶還需要在定一個鬧鐘）、“放棄指令”（用戶操作到一半，突然選擇放棄）、“刪除任務”（如刪除此前設置好的鬧鐘）、“修改指令”（用戶一開始定的早上8點的鬧鐘，操作中突然說要把這個鬧鐘改到9點）等等，這里就不一一列舉。

任務型對話的流程設計

與做APP一樣，在設計“任務型對話”的流程時，我們同樣需要考慮盡可能多的操作與情景。

1. 槽位完整表達時

以定鬧鐘為例，“設置一個明早八點的鬧鈴”：設置鬧鈴是相應需要執行的操作，明早是日期，八點是具體時間。因此這樣一段對話其槽位都是完整的，流程也是最簡單的，因為用戶已經把所有的信息都說完整了，設備只需要執行就可以了。

2. 槽位部分表達時

“明天叫我起床”，顯然缺少具體時間的槽位，雖然相應的執行操作內容是完整的，但因為缺失信息，依然導致任務無法完成，所以設備會發起新一輪的對話，要求用戶補充對應確實的槽位。

這種情況相對也常見，很多用戶會先說：“給我定個鬧鐘”，等到機器響應之后，再說“定到明天早上八點”。

3. 含有分支流程時

即在一輪對話中，即使用戶槽位表達完整，但因為出現了分支情況，導致任務依然無法立刻執行。比如：用戶說“打電話給張三”，但也許用戶不止有一張卡，這個時候就產生了“用哪張卡撥號”的分支；也許用戶通訊錄中不止有一位聯系人叫張三的，那這個時候的分支流程又變成了“呼叫哪個張三”的情況。

類似這種，在一輪“任務對話”過程中，出現了分支流程時，對應的操作又應該怎么設計，這就要求產品經理能充分考慮到用戶在不同情況下的一個需求，從而進一步完善相對應的功能。

4. 主動或意外退出時

也許是設備還沒有執行完成任務時，突然退出的情況，在這里包括：用戶關閉相關功能、用戶放棄操作等情況。如果是用戶直接強行退出程序，自然也沒有后續進程可言，但也許可以考慮到，當用戶重新啟動該功能時，設備是否可以自動詢問：“上次我們還有一個任務沒有完成，是XXX，是否將其繼續完成”。

但如果是用戶停止了任務，比如用戶說“給我定個鬧鐘”，但就在設備詢問“要定幾點？”的時候，用戶說“算了，不用了”，那這個時候，設備應該如何回復。

因此在這一環節主要考慮的就是當一場“任務型對話”結束時，設備可以執行怎樣的一個操作，來反饋給用戶。

總結

以上就是關于“語音交互產品設計原則”的簡單贅述，最重要的一點是：當我們在設計語音交互的功能時，我們應該結合實際問題，從實際出發，把語音交互作為一種更高效的生產力，從而給用戶帶來更好的體驗，帶來更高的效益，而不是作為一種噱頭添加到我們的產品中去。

 

本文由 @二十一弦 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議