酷播亮新聞
在什麼時候語言交互的效率更高，什麼時候更低？
“自然語言交互”，這個名詞似乎在去年已經長期佔據科技類新聞的頭條，各大巨頭們都想搶占這個據說是下一個互聯網入口的巨大機會。
然而，就跟歷史上每一次的交互變革一樣，目前我們離真正搞明白這個下一代的人機交互方式還有很長的一段路要走。 希望通過這一系列的文章，我能幫助自己理清思路，同時也能為大家提供一些想法。 同時希望，我真的能把這個系列堅持下去…
定義
跟一般“市面上”所說的“語音交互”不一樣，本文用到的是“語言交互”，或者叫所謂的“對話式交互（CUI）”，因為本文想討論的不只是語音交互，也 包括文字交互。
本文關注什麼
在閱讀後面的內容前，我們先來問兩個問題：
- 什麼情況下語言交互效率更高？
- 什麼情況下語言交互效率更低？
沒錯，在本文的語境下，我們暫時只討論交互效率。
舉一個例子
我想以我們做過的一個功能——日程提醒（實際上很多產品也做了這個）為例來展開下面的論述。 如果我們是在日常會話中想讓助理給我們設置一個提醒，我們也許會這麼說：
“下週一下午三點提醒我坐飛機”
“中秋節10點提醒我要回家吃飯”
……
上面所列的是比較自然的一些語言交互的問法。 由於本人所做的產品是面向PC端辦公的場景，所以這裡先比較純鍵盤輸入的文字交互和傳統的基於圖形交互界面（GUI）的鼠標+鍵盤的交互之間的優劣。 那接下來我們就看一個選擇時間的典型的GUI交互方式：
大家可以很容易地發現，第一種純文字交互的好處是整個交互體驗非常一致、流暢，用戶只需要通過鍵盤打出TA想要設置的提醒內容就可以了；而第二種交互，用戶必須通過 鼠標和鍵盤的來回切換才能完成整個動作（時間用鼠標選擇，事件內容要通過鍵盤輸入），非常地不流暢。
我不知道大家的操作習慣怎麼樣，對於我來說，我既討厭在鼠標和鍵盤間來回切換，也不太喜歡操作鼠標。
試想一下，你正單手托腮很慵懶地用一隻手在操作鼠標，或者你正用一隻手擺了個很帥的pose，另一隻手在操作鼠標，而這時候你被迫 要切換成兩隻手在鍵盤上面進行輸入，這種姿勢的切換是會給用戶帶來巨大的體驗成本的。
鼠標加鍵盤是PC時代不得已的交互方式，雖然現在我們也講所謂的“多模態交互”，但是鼠標加鍵盤的組合在很多場景下顯然不是最優解。
談談效率
說完交互的問題，讓我們回歸到文章的中心：效率。
GUI有一個很大的問題，就是在處理特別多的選項的時候，無論是顯示效率還是操作效率都不盡如人意，而時間選擇就是一個典型的例子。
為什麼？ 因為“日期”的選項是無窮多的，如果你提供未來一年的提醒功能，那麼你需要想辦法顯示365-366天。
而“時刻”的選項也是非常多的，如果你的功能是精確到分鐘的話，那麼你則需要想辦法顯示60 * 60 * 24 = 1440個選項。 當然一般的GUI都不會選擇把全部選項直接平鋪出來，因為這樣太“傻”。
一般的做法（如上圖Win10）都是以月為單位列出日期，然後提供翻頁（翻月）功能。 對於時刻的選擇來說，一般的做法可以是降低精度（如上圖Win10，以半小時為單位，降低了29倍的精度），或者是提供以滾輪滾動的方式來增減分鐘。
這些做法的本質都是一樣，就是只顯示部分選項，隱藏其他選項，然後提供一個切換選項的機制。 誠然這種做法裡也還是有一些提高選擇效率的方式，如最常見的“熱門”選項：
但是總體來說，這種GUI的選擇效率還是很低，因為用戶真正想選的選項很多時候都不出現在“首頁”，而且用戶體驗非常糟糕：我明明知道我要選的是什麼，但是你 居然要讓我經過辣麼多步驟才能選到我想選的。
另外大多數這些GUI的設定都有使用門檻，或者說預設了用戶的某種先驗知識，例如（如上圖）需要用戶學過普通話與拼音，或者需要用戶知道焦作在哪個省（那些要 先選省再選城市的GUI）等等，要知道，部分用戶是不具備這些先驗知識的。
改進GUI？
現在，我們要問一個問題，上述GUI的問題可以通過改善設計來解決嗎？ 在這裡，我想僅以“時刻”的選擇為例來說明：
（請原諒我用表格來畫UI……）
在上圖的第一種顯示方式中，我們把一天內的每一分鐘都顯示出來了，這樣的好處是點擊效率高，只需要點擊一次就完成選擇。 但是確定也很明顯，就是顯示效率和定位效率都太低。 在第二種顯示方式中，我們改善了一下，把“時”和“分”分開來選擇，這樣操作數雖然增加到了2，但是顯示效率大大提高。
在上圖的第三種顯示方式中，我們再進一步把“分”裡面的十位和個位進行了分離，這樣再進一步提升了顯示效率，但是操作數上升到了3。 當然3次的操作數是完全可以接受的，就算你用鍵盤輸入，也起碼要操作四次才能完成例如“8：00”這樣的輸入。
其實第三種GUI本質上來講就已經跟彈出個虛擬鍵盤差不多了，在這裡我們會發現對於這個例子來說，點擊操作最終會收斂於鍵盤操作。
但是改進到了這裡，是不是GUI就能和文字（鍵盤）交互抗衡了麼？ 不一定。
鼠標交互的問題
鼠標交互對於鍵盤交互來說，最大的缺陷就是，鼠標交互是 不直接的 。
為什麼不直接？ 大家可以試一下從屏幕左半部的某個指定的點迅速移動到屏幕右半部的某個指定的點（除屏幕的四個角外），你會發現你是幾乎不可能一步到位的， 你必須在快到那個點的時候不斷地做微調，最後才能讓鼠標準確地落到那個點上。
原因就在於人操作屏幕上的鼠標是通過手裡的鼠標硬件來進行的，而這個過程是鼠標這個硬件通過傳感器掃描鼠標底下的平面來測出用戶在這個平面上移動的距離，然後再通過一個 係數來轉換成屏幕上的鼠標移動距離的（像素值）。 這個過程是極其不直接的。
我曾經教過我爺爺使用鼠標，我不能忘記當時他小心地慢慢移動手中的鼠標，時刻觀察著屏幕上鼠標的移動，每一點的移動對於他來說都困難無比。 所以即使鼠標的操作數（其實上文是忽略了“移動鼠標”這種操作）跟鍵盤的操作數相當，鍵盤輸入也有著強大的交互優勢，因為鍵盤是“所見即所得”，敲什麼出 什麼。
選項比你想像中的要多
接下來，GUI將會面臨一個更加嚴峻的問題，那就是用戶的需求比你想像中的要多。 就如本文開頭所舉的兩個例子“下週一”和“中秋節”，你都無法在GUI下找到很好的解決辦法。
對於前者，用戶要先在日曆中定位“今天的位置”和日曆上“星期一”對應的那一列在哪，然後才能“艱難”地找到“下週一”在哪；而對於後者，更痛苦 ，用戶需要先百度一下“今年中秋是幾號”然後才能回來選擇。 你當然可以說，我們可以把“下週X”和“XX節”這些快捷按鈕列出來，但是試問你能列出多少呢？
在這裡，我們會看到，在面臨用戶的“表達自由度”非常高的場景，GUI是十分無力的。 當然語言交互也會面臨相同的問題，不過這個問題將會變成“語言表達自由度”的問題，例如用戶會說“下週一”、“下週1”、“下禮拜一”、“下星期 一”等等，不過這部分的問題暫時不在本文討論。
其實我作了個弊……
為什麼這麼說呢？ 因為事實上是存在更優化的GUI策略，能讓時間選擇的操作效率更高也更舒服的，只不過我以一個“作者”的身份讓大家掉入了某個邏輯陷阱中而忽略那些更好 的設計的存在而已。
而且本文主要針對的是（非觸摸型）PC端的辦公場景，實際上在移動端（或觸屏PC）使用觸摸交互代替鼠標交互就可以避免上文提到的鼠標交互與切換交互姿勢等的問題 。 而且，打字還存在打錯字、打字速度慢等等的問題……
但是，就算GUI贏得了文字（純鍵盤）交互，還是贏不了語音交互……假設在語音識別率接近100%的前提下，到目前為止，我還沒有見到過有任何GUI的時間輸入效率能 勝過語音輸入。
下一個問題
前文講了那麼多語言交互的好處，但是什麼時候CUI的效率比GUI低呢？ 請看一張圖片：
（請注意，這不是廣告，是百度然後隨機的）
如果你來到一家只有CUI而沒有GUI的餐廳，你一定會瘋掉，因為你只能通過服務員慢慢地給你報菜名來知道這家餐廳有哪些菜。 當然播報效率是一個問題，另外一個問題就是服務員播報完以後沒有留下任何東西，剩下的就靠用戶的記憶力了，所以很容易報到後面，用戶已經忘了前面有啥了。
所以你會發現所有電話自動語音回复都會有一個“重新收聽請按#”的選項，連一般客服點化的4、5個選項用戶都記不住，更別說一份完整的菜單了。 這樣的例子還有很多，例如某寶的商品詳情頁：
（對不起，這..應該是條廣告…吧..）
如果上圖中的所有信息都只通過語音展示給用戶，那效率肯定會比GUI低很多，因為人的閱讀速度是非常高的。 這裡我們可以看到，其實交互可以大致分為兩個部分：展示和輸入。
在本文的前半部分中主要討論了CUI如何在輸入方面擁有比GUI更高的效率，但在這兩個例子中，我們會發現，在絕大部分場合中，GUI的展示效率要比CUI高得 多。
作為最早推出智能音響的公司，Amazon早就意識到了這個問題，並在後續的產品升級中推出了“Echo Show”這個產品。 這個產品就是在原來的智能音響“Echo”的基礎上加了一塊顯示屏，必要的時候使用顯示屏來顯示信息，而拋棄原來的純語音交互模式：
初步的結論
於是我們得到了一個初步的結論：
- 圖形界面展示效率更高
- 語言交互輸入效率更高
展示效率不用說，無疑是GUI完胜。 而輸入的話，例如我們上某寶買衣服，如果我們想輸入“5件S碼”的話，說四個字就好了，如果用GUI進行輸入，則可能需要點擊“S碼”，然後可能要 點擊四下那個“+”按鈕，輸入效率明顯語音交互更優。
不那麼初步的結論
但是，下面讓我們來看一個反例：
我們可以很容易地發現，如果我是想買那個“HB+2H+2B+3B+4B+5B+6B+8B+10B+12”的話，我得說多久才能說得完這一長串文字。 但是如果用GUI的話，則只需要輕輕地點擊一下。 當然你可以說，我們可用“買最後那個”來代指那個選項，但是如果一個超長的選項是在各大選項中間呢？ 或者說所有選項的名字都辣麼長呢？ 那你就沒辦法了。 於是我們得到了一個不那麼初步的結論：
- 圖形界面展示效率更高
- 語言交互固定短輸入效率更高
- 圖形界面固定長輸入效率更高
GUI的尷尬
雖然說接下來我要講GUI的尷尬，但是這其實是所有“單模態”交互的尷尬。 從上文的分析中可以得出，GUI中的像素同時承擔著兩個任務：展示和輸入。 但是很多時候GUI裡的展示是多餘的，展示的唯一目的是為了輸入，因為你不把選項展示出來，用戶無法輸入。 讓我們來看兩個例子：
上圖左邊的展示是必要的，因為你不展示出來買家不會知道你有什麼套裝可以選擇；但是右邊的展示是非必要的，因為誰都知道一年有幾個月，每個月裡面有 哪幾天（連這個都不知道的用戶暫不考慮……），可是GUI裡又必須把這個展示出來，因為用戶需要點擊選擇TA想要的東西，所以很多時候GUI裡是有很多“冗餘 ”的信息的。
講到這裡，再結合上文中提到的結論，我們就可以推導出適合進行 純語音交互 的場景了：那就是選項已知且不變的適合使用純語音交互。
這種場景還是很多的，例如編輯文章後未保存狀態下返回上一級頁面，頁面就會彈出“文章未保存，是否確定要退出？”這樣的提示，這個情況下用戶會知道只有“是” 和“否”兩個選項，所以這裡也無需做GUI的展示考慮。
有那麼點意思的結論
於是我們又得到了另外一個結論：
- 圖形界面展示長文本效率更高
- 語言交互固定短輸入效率更高
- 圖形界面固定長輸入效率更高
- 選項已知且不變的適合純語言交互
值得注意的是，上述的四條結論都是有比較嚴格的前提條件的，至於具體前提條件是啥，其實本文沒有從邏輯上討論得非常充分，這裡就留給讀者一些想像和思考的空間。
有了前文的一些推理，然後再加上結合GUI和CUI兩種交互以後，我們會發現當多種交互方式並行的時候（所謂的多模態），“展示”和“輸入”是可以進行分離 的。 至於什麼時候選擇哪種交互方式來進行展示或者輸入，則需要根據實際情況來決定了。
還有更多值得探討的地方……
這裡就舉幾個例子，第一個是點菜。 你會發現一般情況下，人們來到餐廳進行點菜時都是會向服務員詢問菜單本子的，但是有些情況下你會發現，例如熟客，一坐下來開口就可以進行點菜；或者是點菜 老手，一坐下來就直接問“有什麼肉推薦”、“有什麼招牌菜”、“有什麼油菜”等等的。
本文通篇討論的基礎都是“效率至上”，但是實際生活中，很多時候用戶考慮最多的並不是效率，而是另外的東西，例如“社交地位”，或者俗稱的“裝X”。
第二個例子就是語音交互的另一個典型應用場景——駕駛。 人在駕駛的過程中註意力是需要高度集中在前方的道路狀況中的，所以這時候很多情況下GUI不是一個很好的選擇，因為會降低駕駛的安全性。 那麼在這種場景下，安全的優先級就是高於效率的，所以GUI是比CUI更好的選擇。
還有一個不那麼常見的例子，也是日期選擇：
我們可以看到這個日曆所展示的內容不是簡單的一個月裡有哪幾天的信息，而是還包含了“這個月裡有哪些天是可以住的”的這一層的信息，而後者是 用戶所不會默認知道的，所以這裡必須配合GUI，而不適宜用純CUI了。
除了上述的這些，其實還有很多很多很多……語言交互的場景的確還有很多值得我們去共同探討的地方。
作者：寸木木，微信公眾號：紐偕克斯
本文由 @ 寸木木 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自PEXELS，基於CC0協議