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