[思考]對話式設計漫談
你是不是也有被滿螢幕的表單和輸入框弄的無所適從的時候?
我們在網路生活中,頻繁的點選按鈕,在對話方塊中輸入文字,提交,去與裝置/系統發生互動,這一系列的操作行為,都是在網路時代培養出來的互動習慣,讓裝置/系統明白我們的意圖,並照著去執行。這些互動方式都是在基礎層面上,為了減少人與裝置的摩擦而設計的。早期的裝置受限於技術和使用場景,顯得笨拙和呆板。
但現在,有些不一樣了,隨著語音技術和語義理解的發展,機器比之前稍微智慧了一些,可以通過我們一般的描述來做出回應,就像在生活中我們與服務員、教練、醫生等各種角色對話一樣,在這樣的發展潮流下,很自然地就衍生出了一種與之前不同設計形式:
對話式設計
對話式設計與以往的一些元件堆砌式設計不同,它在與使用者的交流上更加的人性,自然。
在這裡我會通過三類對話式設計的實踐來談談自己的理解:
1.智慧裝置(Google Home & Amazon Echo)
2.對話式介面 (Ada & Zova)
3.Chatbot(Operator & 淘寶小蜜)
智慧裝置中的對話式設計
Amazon和Google都有推出自己的家庭智慧裝置,Amazon Echo和Google Home。
在家裡,你只需要喚起你的Google Home,就可以檢視天氣,聽音樂,得到問題的答案,不需要開啟app,也無需用手指敲出內容,你所需要做的就是,很自然的與它對話。通過TTS ( text-to-speach )和NLP( natural language processing ) 兩項技術,這也是搭載在硬體上的智慧助手實現的基礎。
在喚起方式上,兩款產品雖然都是熱詞喚醒,Google新增了一些更加生活化的助詞,類似於“hey~”,“ok~”。也許只是語氣上一些微小的改變,卻定義了你與Google Home之間的關係,不是向裝置發號命令,而是像與生活中的助手一樣交談,在裝置表現不是很好的時候,使用者會更寬容地對待。
利用生活化的語氣有助於建立與使用者之間的和諧關係,並且能讓使用者更自然地進入到一種對話互動的模式之中。(生活中我們也很少用命令式的語氣去請求別人的幫助是吧?)
而這種家庭裝置的自然語音互動也面臨著很多的挑戰,暫且把它們歸為兩類:識別和反饋。家庭裝置擺放的位置較為固定,使用者的口音,使用者的音量(遠距離或小聲音),還有家庭環境中的干擾(音樂、對話,和其它聲響)都會影響到對輸入語音資訊的識別效果。如何設計出一個有效的輸入模式,可以讓使用者更好的輸入資訊?而不需要再三宣告和做出解釋;自然條件下的語音互動行為是開放的,使用者會問出很多問題,這種開放性對輸入內容的處理形成了挑戰,如果你是Google,有足夠的內容和資源,或許可以應對90%的情景,但如果你的技術不夠成熟,或者遇到了10%的場景,應該如何處理呢?或許這就是我們應該在設計中考慮到的邊界問題,在出現脫離處理能力的情況下,通過引導和暗示將使用者遷移到一個更為可控的互動環境下,在設計過程中,通過預設場景劇本,讓使用者可以迴歸到一個安全的環境。
這樣的開放式對話互動形式,可能會在未來很長一段時間內得以延續,但是硬體形式可能會得到更大的改變,不論是 Amazon Echo,Google Home ,繼承的都是自然對話的語音層面,也可能會在未來提供更多的互動形式。人與人之間的對話不僅是交談,還會有眼神,表情,語氣這樣更富有情感的細微表現。
Jibo在與使用者的互動上表現得更為主動,與使用者的對視和身體的動作,更為活潑和有靈氣。(但是這個語氣實在是乾澀)
2.對話式介面
對話這一種自然的交流方式,也被設計者在移動端app上進行了實踐嘗試,在介面中對資訊進行對話的形式呈現,例如 Zova 和 Ada 就是兩款,在運動健身和健康服務兩個領域的優秀實踐。
在對話式介面中,仍然保留裝置上的互動習慣,但是在資訊的展現形式上靠近對話形式的設計,例如聊天對話的氣泡,語氣助詞的使用,正在回覆時等待載入的省略號,都是將使用者安置在一個交流的環境中,第一次接觸的時候確實給人帶來驚喜,對話式介面讓你的app更有溫度,想想那些冰冷的“錯誤”“警告”“失敗”,它們扔給了你一個糟糕的結果;它也可以很好的開啟使用者的防線,讓你更輕鬆地去請求許可權和收集使用者的資訊,現在很多app在你第一次開啟時,都會一窩蜂地開啟一串許可權申請,亦或者填寫個人資料時扔出一個表格,交給使用者完成,這都是設計的結果,但可能存在更友好的方法。對話式的介面會引入感情,潛藏的個性,和表述方式能過讓使用者的情感波動,你可以引導使用者做出一些積極的行動。對話式介面也有它的設計優勢:對話帶來的親和力,互動習慣的繼承,對資訊更清晰的分步組織。
-親和力
親和力可以消除產品和使用者之間的隔閡,增加信任感,快速建立與使用者的關係十分重要,能夠輕鬆地讓使用者開啟許可權,而不是警惕。而這樣在對話中的互動關係,也可以讓使用者更為活躍。
-習慣繼承
這種繼承能夠很好的符合使用者預期,就像是在IM上和朋友聊天一樣。引用了更多的日常用語和交流習慣,而這些都在可控的範圍內,相較於 Amazon Echo 和 Google Home 的自然語音互動,不會出現像Google Home 和 Amazon Echo 面對那麼多寬泛的問題。
-資訊有效的組織
這點十分重要,就像我們在對話的時候,也不太會一口氣問出好幾個問題,我們會明確問題的先後關係,然後按照一定的邏輯丟擲我們的問題。
這點看起來有點道理是不是?但是很多產品卻是一股腦的扔出輸入框,扔出許可權請求,這樣實在是打擾到使用者了。
在對話式介面中可以通過對預期對話場景的指令碼進行梳理,對使用者需要的操作進行組織,避免大量的資訊帶來的壓迫感。
所以在對話式介面中,對臺詞的設計顯得十分重要,想象你這是一幕話劇,你需要為所有的角色設計對話,包括它們在臺詞中表現的性格,使用者是一個主角,你要通過他與其他角色的交流,一步步推動劇情,而你所能引導的,就是所有角色之間的對話互動。
語言活潑,生動,簡短而且表意明確,可以稍帶一些暗示性或者傾向性,這樣更能給幫助使用者做出反應。
例如:
“下午好,您現在是要喝點什麼?”
“下午好,您現在要不要喝些果汁或者咖啡?”
第一個問題得到的回答會有很多,有可能是是你無法提供的酸奶,如果使用者得不到想要的結果,只會是徒增對產品的不滿。第二個問句就會帶有一些暗示性和傾向性,將使用者思考的方向指向了果汁和咖啡,將使用者留在一個可以控制的範圍內,更大可能的去滿足需求。
這樣的對話式介面最近開始普及了不少,有興趣的話去搜搜看,會有很多有意思的東西。
3.Chatbot(Operator & 淘寶小蜜)
聊天機器人已經很熟悉了,各樣的客服或者自助服務都會選擇聊天機器人來進行輔助操作,它們在設計上都會有一個很具象的形象,XX助手或機器人。
具像化的形象是chatbot的特點之一,但是給人的感覺可能並不是足夠好,因為面對著一個機器人,下意識的就會認為是機械式的回覆, 不太會願意去進行更多的互動,而且會認為自己做出的行動並沒有真正的得到反饋。
為了延續操作上的流暢,chatbot會將一些操作更加細化的放置到對話氣泡中,而且關於是否要放置一個真人的頭像,這一點也有做過一些嘗試,不過最後好像都沒有應用,大概是會看起來更假?
chatbot背後有一個巨大的問答內容庫,根據這些內容來應對使用者發起的請求。這也是一個半智慧的產品,注重聊天中的氛圍就十分重要,雖然我們都希望使用者能夠很快的在這裡得到答案然後離開,但是誰又知道使用者帶著哪些問題開始聊天呢?
半開放式的問答,帶來了不確定性,應對場景建立的劇本和氛圍是一件十分複雜的工作,即使AI能夠分擔一些任務,但是仍有很多的細分的個性化場景需要去思考。
從去年的下半年開始大家開始聊更多的人工智慧,希望它能成為下一個技術的爆點,其實chatbot也算是人工智慧的實際應用,只是它離我們所暢想的狀態遠了一些。而對話這一種形式會成為與機器人互動的主要互動形式之一,想想看,你不太會用手指去戳機器人,來讓它理解你的意思對吧?
現在的對話式設計,就是在這樣的一個過渡的程式之中,你的產品開始會帶有一些情感色彩和個性,不再是生硬的反饋和應答,更多的與產品互動,而不是一個人在產品中探索。(導購類的機器人就是扮演這樣的角色)
也在這裡分享一些早期的對話式設計文章,這幾篇讓我接觸,並開始意識到這是一種設計形式。
(譯文:對話介面的起點)
原文:Conversational Interfaces: Where Are We Today? Where Are We Heading?
(譯文:對話式介面的現在與未來)
原文:Design Framework for Chatbots
(譯文:為chatbot設計框架)
相關文章
- 漫談對大資料的思考大資料
- 漫談響應式網頁設計網頁
- 漫談程式設計師系列:請區別對待女程式設計師程式設計師
- 【話題討論】漫談生產系統升級的一點思考
- 漫談哲學與程式設計程式設計
- 設計模式漫談之策略模式設計模式
- 設計模式漫談之命令模式設計模式
- 設計模式漫談之代理模式設計模式
- 設計模式漫談之模板方法設計模式
- 漫談iOS AOP程式設計之路iOS程式設計
- 設計模式漫談之狀態模式設計模式
- 設計模式漫談之組合模式設計模式
- IBM對話設計指南:對話聊天框設計挑戰IBM
- 設計模式漫談之備忘錄模式設計模式
- 設計模式系列1--開篇漫談設計模式
- PHP設計模式漫談之迭代器模式PHP設計模式
- 漫談程式設計師系列:程式設計師零門檻?程式設計師
- 設計漫談:傳說任務的曲折道路
- 漫談 JS 函數語言程式設計(一)JS函數程式設計
- 漫談程式設計師系列:無BUG不生活程式設計師
- PHP設計模式漫談之調解者模式PHP設計模式
- 【大話設計模式】——淺談設計模式基礎設計模式
- 針對小手指的設計思考
- 談談對程式設計師的管理程式設計師
- 漫談程式設計師系列:那些害死程式設計師的細節程式設計師
- 獨家對話RadonDB設計者 暢談開源背後的初心
- 漫談世界觀敘事設計中的工具鏈
- 【iOS印象】漫談 iOS App 架構與設計模式iOSAPP架構設計模式
- 漫談程式設計師系列:任性,春節前辭職程式設計師
- 漫談前端體系建設前端
- 漫談計算機編碼計算機
- 漫談計算機架構計算機架構
- 談談對IOC及DI的理解與思考
- 漫談“資料拆分層次對比”
- 漫談程式設計師系列:程式設計師的生活就這樣嗎程式設計師
- 漫談程式設計師系列:一張圖道盡程式設計師的出路程式設計師
- 漫談程式設計師系列:程式設計師到底是什麼角色程式設計師
- 漫談程式設計師系列:千奇百怪的程式設計師程式設計師