互動之路-基本設計原則(上)
2.1 移動裝置與IVR系統設計
讓使用者知道自己是在用機器為自己服務可以是他們放心大膽的詢問業務問題,不用擔心如果詢問次數過多,是否會使人工不耐煩,長期以往,就會習慣這種解決問題的模式,一旦取消,人們會不適應
增加語音識別率除了在技術上做文章,也可以透過推測使用者可能意圖,在問題中做詢問,減少使用者需要回應的字數,在機率上可以增加識別效果,也就是將前期工作(分類,聚類,預測)做好,對於第一次使用的使用者,對所有相應次數的使用者的意圖做統計分析,對長時間使用產品的老使用者,對使用者自身的生活習慣統計分析輔助詢問,最好讓軟體(使用者專屬雲端)在各種硬體上互通,這樣對收集資料更有利
移動手機助手有兩個挑戰:一個是是否需要虛擬角色,一個是如何界定什麼時候允許使用者說話。而且對於多個選項展示的複雜結果,需要介面配合更有助於使用者獲取資訊,如果沒有見面,對於這種情況,最好詢問使用者是否需要將多個結果(較長答案依次讀出),有時候讓使用者對機器行為多一些控制,比讓他們感覺服務不周,有迷茫感更好
雖然有一些產品用語音解決問題,但是也會設計一個配套的APP,這樣一方面有助於瞭解及其對自己的生活情況瞭解到什麼程度,甚至可以自己新增一些資訊,另一方面用多模態的服務方式,更有助於互動的流暢性,使用者也會更從容,因為在純語音的交流中,使用者必須不斷的與系統進行互動,很少有機會暫停系統,所以如何解決主動詢問與沉默尷尬的界限也很重要。而且對於垂直場景的應用,APP可以讓任務完成更有完整性,不要為了應用AI而應用,而要和業務需求緊密結合,從需求出發
視覺與語音要協同設計,如果兩種互動方式都要應用,那麼從一開始就要配合設計
2.2對話式設計
要設計一輪以上的互動,就要思考使用者接下來可能會做什麼(或者透過資料訓練,對使用者常見行為踐行分類預測),不要強迫使用者展開新一輪對話,而是去嘗試瞭解使用者的意圖並允許使用者繼續交談,此外有必要對使用者近期所說的話保留歷史記錄,否則,與一個永遠不能記住上一輪或者上幾輪資訊內容的機器交談,是疲憊且無益的
對於上下文理解中,指代是很重要的,對於特殊命令詞語要深度剖析,比如:“去北京坐什麼比較便宜”“火車,價格XXX”,“那裡的天氣怎麼樣”,那裡就要知道是在指代北京,而如果沒有代詞,則要有記憶功能,明確主語在指誰,比如:“北京哪裡比較好玩”,“故宮”,“現在人多麼”沒有代詞,但是要自行補充主語,是指前文的故宮。
讓使用者決定一次對話要持續多久,主動權會使他們聊起來更舒服,減小壓力和防備心
2.3設定使用者期望
“如果你不能理解答案,就不要提問”
意思是,如果你提出的問題可能得到的回答,機器會理解不了,或者使用者回答的答案是不可控的,不能窮盡的,那麼就不要輕易提問
必須早期就設定使用者期望,讓使用者知道自己已經完成了什麼,就會獲得一次成就感和滿足感,要利用好使用者在使用過程中增加教學點的機會,比如:使用者完成了某一件事,你可以說:“太棒了,要不要試試這個”(對待孩子也許更適合)
工程師認為,有時候為了減少延遲,機器會對使用者的請求做快速恢復,但是可能事情還並沒有完成,比如設定鬧鐘,提醒,傳送訊息,購買商品等,要在真正完成後告訴使用者“好了,XXX已成功”讓使用者更確認目前的狀況
如果你設定了可以完成某項任務的預期,請務必考慮與之相關的任務,比如:幫助使用者設定了鬧鐘,那就要想到使用者可能會取消鬧鐘,改變時間,換鈴聲等等(還是要從場景本身出發,考慮會更全面)
可發現性也是設計使用者預期的手段之一,比如:使用者使用手機可能會說,“一二三”,“茄子”,等等,相機就會自動拍照,又或者有一天突然對音響說:“XXX,你在執行麼”,“一切正常”用語音的方式檢查故障,會比其他方式對使用者來說更方便(還有什麼例子)
當詢問使用者的個人資訊時,要給出示例,不是說明,比如:“請說出你的出生日期,類似:xxx年xx月xx日”,而不是年月日
2.4 (在交付一個專案時,應該準備的,還包括後來的提示列表)
1 示例對話:對於常見場景,寫出各場景下的示例對話,並寫出異常情況下的示例對話,完成後,和另一個人大聲朗讀出來,(也可用TTS將設計的對話用機器讀出來,成本會更高,但更好用)知道設計效果如何,對於使用者可能的問題,不要只設計一個答案,會顯得呆板
2 視覺原型,讓對話流程視覺化,讓使用者體驗的設計更完整
3 流程圖,展示可能發生的路徑,要包括使用者在使用系統中所有可能存在的分支,在圖表中不用列出使用者肯能說的每一個短語,但是要把他們適當的分組,如:聽音樂的,洗澡,剛起床,剛回家,要睡覺等等
2.5 確認策略
如果過於確認剛才使用者恢復了什麼,會使使用者反感,所以適當把握好使用者能感覺到自己是被理解的,也讓他們知道機器什麼時候沒能理解他們說的話的尺度,比如:使用者說“是的”,“你說了是的,對嗎”,在或者使用者用語音預訂飲料,機器:“請仔細聽,如果有你想要喝的,請打斷我,我們有:美年達,雪碧,康師傅礦泉水... ...”,“雪碧”,“再跟你確認一遍,你要了雪碧,對嗎”,這就讓使用者覺得我為什麼不直接在手機介面點選一下,問題早就解決了,除非是,使用者實在不能將手騰出來的場景,(所以不要急於向使用者推送都有什麼,先問他們需要什麼,如果得到明確結果,直接預定,如果沒有,比如:“你這裡都有什麼?”“都可以”,再向他們推薦銷量靠前的幾種商品,還要注意的是,最好告訴他們推薦給他們的理由,有助於讓他們做出購買決策,同時也要考慮使用者可能會回覆的可能情況:“有便宜的麼”“有含糖量低的麼”)
再決定VUI的確認策略時,可以參考以下幾點:
錯誤的結果是什麼(轉錯賬,治錯病,這都是不能接受的)
系統將以什麼形式反饋(音訊提示?視覺提示?如亮燈)
會有一小塊螢幕麼?(手錶,手機)
以什麼形式來確認是最符合當下場景和硬體的
(根據智慧手錶,耳機,語音助手,音響,自行設計在各種情況下的確認策略)
智慧硬體其實一直在聽,你要做的是讓他知道你想和他對話,還有讓使用者知道機器已經在聽,比如 :提示音,介面,語句,震動等等,本質還是在讓彼此知道自己處於什麼狀況
語音是單通道的,所以機器和人在表達上讓對方明白與否很明顯的就顯現出來,要根據置信度閾值將對錶達的理解情況分為顯性確認“你要設定一個下午兩點的鬧鐘,是嗎”和隱性確認“以為你設定好下午兩點的鬧鐘,到時會叫你”,根據不同的置信度閾值設定不同的回覆,一般為45%~80%,如果大於80%,回覆“好的,以為您XXX”,如果45%~79%,“你是希望XXX是麼”,如果小於45%,“對不起,沒有聽清,請再說一遍”
對於搜尋類,如果置信度較高,可直接說答案,如果不超過80%,還是用隱性回答,這種錯誤後果較低,“獵豹是陸地最快的動物”,對於服務類,至少還是用隱性回答,更為保險,對於指令類,像“開啟燈”如果中間有延遲,用回覆先讓使用者知道自己的語音被識別了,對於這種讓使用者知道自己已經完成了什麼,處於什麼樣的狀況時,可以用簡短的,有識別度的聲音,比如在購買完成,預定完成,設定完成,正在傾聽,即將關機等,或者在智慧駕駛中,遇到紅燈,前方障礙等都可加以短暫提示音
在開放域的聊天中,通用確認是很好的方式,對於使用者回覆的程度,正負面做分類,給予相應的回覆,以確認你聽明白了他們再說什麼,“聽到這個訊息真為你開心”,或適當加入,嗯,然後呢,也很符合人們對話的語言習慣,這樣會使對話更豐富(對於每一種可能的情況,都要設定一組回覆與之對應)
視覺確認如果可以,要好好利用,一是可以讓使用者直觀地知道自己和機器所處的狀況,比如:自己剛做的選擇是否被機器聽懂,也有助於他們記住機器表達的資訊,日後也可再次確認,回顧,特別是回覆較長的資訊
2.6 命令-控制模式和對話模式
對於命令-控制模式,讓機器和人彼此知道對方和自己都處於什麼狀態是最重要的,即要讓機器知道人要對他發出指令,人知道機器已經開始聽自己的指令,機器要知道什麼時候人已經發出指令完畢,要讓人知道機器是否識別,是否理解,是否開始執行,要多久執行完畢等。
使用者必須給出明確的指示,告訴系統自己要開始說話,比如,喚醒詞,按鍵,圖示等,這和對一個人說話一樣,你要對誰說話,先要叫名字,或者眼神,或者動作,或者一個語氣詞等等,但是如果你的機器在感知能力上“有障礙”,那麼頻繁的按鍵和喚醒會使召喚它的人感覺不自然,特別是對使用者的命令不識別或者不理解時,反覆喚醒帶來的麻煩會更為突出。可以理解之所以要每一次都有這樣一個流程,而不是機器在說完之後等待使用者接著說下文,是因為擔心將使用者的非指令談話識別成了指令,所以對於不同的場景要用不同的關閉系統閾值,不能一概而論,比如在購物訂票等場景,等流程完成之後,再關閉系統,對於媒體類場景,完成指令,可關閉系統,對於控制家電,軟體等現在可以做到任務執行完再關閉,對於沒能識別和沒能理解的場景,要給使用者重複一遍的機會,不要直接關掉,同時對於識別不出來,要在增加識別率和麥克風質量上做文章,也可以在使用者的表達方式上做引導,對於總是不理解使用者的話,要增加使用者的表達方式(口音,說法),也要在表達上做引導。還有給使用者多種方式結合的喚醒方式,防止多次喚醒失敗的失望感。還有一種,為了使使用者發出指令更加自然,也可以將指令和喚醒詞同時說出,這樣過程更流暢,也更接近人與人之間的交流方式。
讓人知道機器已經透過某種方式準備聽自己的指令了,也是有必要的,現有的方法,比如最常見的還是用語言詢問:“怎麼了”,“什麼事”,也有非語言類語音,“bi”“bo”等等,或者用視覺反饋(光亮,螢幕,虛擬人物動作等),個人認為用語言最為回應更自然一些。
當使用者輸出指令輸出指令完畢,也要讓機器知道此刻的狀況,為了避免使用者因為猶豫產生的靜音,使得機器等待時間太短而搶話,和人已經說完有一段時間,還沒有等到機器執行,而讓他們不知道自己說的機器是否聽見,或者聽到不想對機器說的話,所以時間的把握很重要,一般為10S(一般人在思考該如何表達下一句時,要思考幾秒的時間,如果在5S左右,還是容易造成使用者剛要說話,機器開始執行的情況,所以要更長一些),但是機器等待使用者回覆資訊和發出指令時,只要還沒說話,就會一直等待,要區分開兩種情況。
對於對話模式,不要強迫機器每次都告訴使用者自己準備要開始說話了,應該是自然的對話技巧進行話輪轉換,常見的話輪轉換提示有四種:問一個問題,“我想看電影”“不如你直接告訴我你想看的電影的名字吧”,在可以的情況下,儘量掌握話語的主動權,讓使用者發過來回答你的問題,減少答案讓使用者不滿意的機率,當然也要視情況而定
不要再不合適的情況下進行話輪轉換,比如,使用者已經提出需求,在沒有問題詢問的情況下,就不要開啟麥克風強迫使用者進行下一輪說話
人們在話輪轉換時,有時不容易識別,比如像“嗯嗯... ...”,有時代表著需要對方接著說下文,有時只是代表認同你說的觀點,或者說我在聽,中間隨意的插入一下而已,所以要想辦法處理這種類似情況,可以從場景出發,規避一些場景,可以從互動出發,規避這種回覆,或者根據上下文判斷,或者隨時允許使用者打斷
可以加入一些微妙的回覆,無論是在特定領域還是通用領域,都可能發生一些不經意的使用者表達“謝謝”“你真厲害”“原來是這樣”,對於這些表達如果也能配好相應的回覆,會給使用者以適當的驚喜(可以在設計中建立一個針對所有這些表達的回覆場景)
不要可以模仿人們交流而加入一些反問句,“你覺得呢”“聽聽你的看法”“真的麼”,一方面使用者不一定會接受這種回覆方式,讓他覺得尷尬,不自然,另一方面,機器對對話的結果也不好掌握,使用者可能會回覆各種想法,機器很容易沒有理解而造成談話不順利,要保證這個空間是在掌控下的,所有的回覆反饋的訊息都是可控的,所有的問題得到的回覆也是可控的。
使用者很有可能在系統回覆完成之間就進行了提問或回答,且回覆情況超出了系統設計,為了避免使用者將設計好的流程打斷,令機器不知如何執行,要麼儘量回覆主要資訊或指令,將內容縮短,要麼將可回覆範圍放在前面
對於命令-控制模式和對話模式的轉換也是很常見的,“幫我查一下最近的去北京的火車”“今天下午兩點發車,從長春站到北京西站,票價260元,需要為您預訂麼”“明天的呢”“明天最早的是上午七點,從長春站到北京西站,票價500元,接著是XXXX”
2.7 對話式標識
讓人知道自己是在和機器進行對話,自己的回覆是被機器感知到的,而不是處於固定的流程之中,這在系統在對話中使用一些基本對話禮儀時,人的參與度會更高,並且以同樣的方式回覆,(這在引導孩子說話方式時也有一定必要性)包括:
時間線:首先,完成一半了,最後
接收回執:謝謝,知道了,好的,我很抱歉
積極反饋:幹得好,聽到這個訊息真替你開心
而要做到這些插入,比較合理的方法是“劇本朗讀”,能指導你加在哪個部分
有一些人認為機器就是機器,不應該刻意模仿人類的表達方式,反而感到不自然,要注意使用適合於系統角色設定的對話式標識,你對機器的定位使得為它塑造了相應的形象,那麼隨之配套的表達方式,回覆方式,都應該不同,這樣角色會在人們的相應領域中更加立體。
作者:李洺宇
連結:
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/3209/viewspace-2811950/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 互動設計原則分析
- 互動設計法則
- SOLID 原則:軟體設計的基本原則Solid
- 物件導向的基本設計原則物件
- UI設計師必學教程:互動設計心理學的古騰堡原則UI
- 設計原則
- 互動多媒體展廳空間設計的人性化原則
- 設計原則:開閉原則(OCP)
- 設計原則 設計模式設計模式
- 【設計模式】設計原則設計模式
- 設計模式 - 設計原則設計模式
- 接地設計基本規則
- SOLID 設計原則Solid
- URI設計原則
- 安全設計原則
- Hbase 設計原則
- 設計原則-依賴反轉原則
- 設計原則之【介面隔離原則】
- 設計原則:介面隔離原則(ISP)
- 設計模式的設計原則設計模式
- 軟體設計原則—介面隔離原則
- 軟體設計原則—合成複用原則
- 設計原則之【單一職責原則】
- 設計原則之【開放封閉原則】
- 設計原則之【依賴反轉原則】
- 設計原則之【裡式替換原則】
- 設計模式 基本規範與基本原則設計模式
- 研究:基於遙控器互動方式的電視遊戲機制設計原則遊戲
- loc框架設計原則框架
- mysql 索引設計原則MySql索引
- DDD聚合設計原則
- 軟體設計原則
- 元件/框架設計原則元件框架
- 系統設計原則
- 設計原則總結
- JavaScript設計模式(一)設計原則JavaScript設計模式
- Javascript 設計模式之設計原則JavaScript設計模式
- 設計模式(06)——設計原則(1)設計模式