各家品牌的聊天機器人開始浮上檯面，而介面設計該如何因應這波科技趨勢做調整呢？就讓筆者來分享這幾個月實踐「聊天介面」的心得筆記，希望更多有興趣的朋友一起發想， 如何應用新科技來轉化更好的使用體驗。
為了討論方便，以下就將「圖像介面」（Graphical user interface）簡稱為「GUI」; 「聊天介面」（Conversational user interface）簡稱為CUI。
GUI與CUI的使用時機
GUI圖像介面：應用於呈現「圖勝於文」的內容
如包含各式圖表、照片、數據、地圖、色彩標示、控制項等等的資訊視覺圖表，不需太多文字說明就能一目瞭然；這個大家應該都很熟悉，我就不多說啦！
[caption id=”attachment_75589" align=”alignnone” width=”1800"]
Source: http://garfieldduck.me/tag/exploratory-data-visualization/[/caption]
CUI聊天介面：適合用來觸發繁多且瑣碎的項目
如繁複的導航路徑、或是眾多獨立的服務諮詢。CUI中又分為以文字（Message UI，MUI）及語音（Voice UI，VUI）為主的介面；MUI的優點是非即時的，不需馬上接收或回應，但必須透過鍵盤登打，對於小螢幕的手機端使用性相對較低，可適當採用預設按鍵供使用者快速選擇，省去打字的時間。
VUI的優點是即時，但必須立即回應，而且輸入容易受外界聲音影響導致不夠精準；可在不吵雜的開放式公共環境，且不干擾他人的狀況下使用。
[caption id=”attachment_75590" align=”alignnone” width=”970"]
Source: http://www.marketingfacts.nl/berichten/conversational-commerce[/caption]
GUI與CUI各有優缺點，堅持只使用某種形式的介面，可能會讓結果更糟；我曾經犯的錯，就是視GUI為舊時代的產物，強硬地把服務以盡可能多的CUI來取代，反而適得其反。適當的結合CUI和GUI的優勢，才能創造更好的體驗。
以搜尋「台北市大安區和平東路的小吃」為例，在GUI中的做法可能是：
- 選擇縣市
- 選擇區域
- 選擇路段
- 選擇餐廳形式
- 呈現搜尋結果
使用者要像剝洋蔥一樣，經過層層選擇之後，才能達到搜尋目標；對CUI來說，只需要告訴系統「台北市大安區和平東路的小吃」，系統後端便會根據關鍵字判讀使用者想要的目標，直接跳到呈現搜尋結果：
- 「台北市大安區和平東路的小吃」
- 呈現搜尋結果
又或者，當服務項目過多時，也是使用CUI的好時機。以上設計成CUI的前提是，要讓使用者在一開始就瞭解系統能提供哪些服務項目，以免面對CUI介面時，因為沒有足夠的提示而手足無措。相關設計規範可參考〈Conversational UI設計規範〉一文。
反過來說，當使用者可以輕易記憶介面操作路徑，比方查詢火車時刻表時，GUI便可提供簡單的選單或按鍵，在少許點按後就能訂好車票；使用者可以一覽在允許時段內的班次，並依自身狀況來選擇車次（例如台鐵訂票通）。來試試看：
- 選擇出發地
- 選擇目的地
- 查看班次
- 訂票
這些動作，說不定熟練的用戶閉著眼睛都能做到。若這些任務發生在CUI上，就會變成：
使用者：我要從台北出發到台中，今天下午1:00之後有哪些班次可以搭？我最晚要在22:00前抵達。
機器人：這個時段有1:30–3:30、3:30–5:30–7:00、7:30-……（略）。
使用者：我要訂1:30出發這一班。
機器人：好，訂票成功。
……光看打字就覺得累了，越少的介面若觸發越多的互動頻率，反而累積更多操作負荷。將CUI和GUI擺在適當的應用上，的確不是一件容易的事，我也做了不少嘗試，暫且下個結論：
以CUI觸發項目、提供精準篩選結果；以GUI呈現資訊、提供模糊參考範圍。
舉個明顯的例子，CUI（聊天環境）與GUI（詳細資訊頁）交互呈現，簡單的語句觸發功能讓展開後的圖表資訊更能一目瞭然，如下圖：
在妥善應用聊天介面的前提下，我們可以獲得這些好處：
- 人機互動更接近真實人類，學習成本降低，能快速上手；
- 一次輸入包含各種條件詞彙，由後端判讀作出相應動作，加快任務完成；
- 簡化前端頁面，縮減程序，加快使用者操作速度；
- 隨著後端功能擴充，介面依舊保持簡單；
- 語句資料庫能無限擴充，機器人將會隨學習次數增加，就越來越機靈。
機器人的聊天環境規劃
這是我目前推敲出來聊天機器人的前端設計流程，各位可試試能否再優化。
[caption id=”attachment_75592" align=”alignnone” width=”1000"]
對談機器人的溝通流程設計[/caption]
在對談流程中，機器端呈現有先後順序的內容、或是可以群組化的資訊；使用者端提供有結構式（有明確制式的選項，可用清單形式呈現）與非結構式（無範圍的條件要求，通常讓使用者自行登打）的輸入方式。
在規劃溝通流程時，需考慮是否過多的互動頻率；過多的操作步驟會延遲任務達成的時間，至於：
- 哪些步驟需要有先後順序？
- 哪些是要群組化一次呈現的資訊？
- 哪些回應可提供快速選單？
- 哪些可提供使用者自由輸入？
- 哪些過程需要顯示進度提示？
- 哪些異常狀況會發生，發生時該如何告知使用者，並提供解決選項？
……等等。依服務主題有不同的狀況劇，就需要設計者自行去探索了。
[caption id=”attachment_75593" align=”alignnone” width=”819"]
溝通流程設計[/caption]
建構良好的人機溝通體驗
機器人回應的精準度，是聊天體驗中最重要也最困難的部分。
當機器人還未聰明到可解讀大部份來自使用者的語句型態時，可藉由限定回應自由度來提高精準率；有幾個方式可試試：
- 輸入框：若聊天介面提供使用者採用鍵盤（或語音）自由回答，那麼後端系統就要有把握能解讀來自使用者各種語句拼湊方式、且多種語句結構可能都指向同一種意圖，系統要能判斷出來；否則機器人與使用者會開始雞同鴨講，這將會是個自己挖坑、降低使用體驗的快速捷徑。
- 清單：若系統還未能判別大部份的人類語句，比較安全的方法是限縮使用者回答範圍，目前常見的方式如下；這些快速選單的好處，除了限縮回答範圍外，也省下使用者輸入需求的時間：
- 提供快速選單
- 提供可輸入的文字提示
- 為項目編號供選擇。
[caption id=”attachment_75594" align=”alignnone” width=”1782"]
設計示意簡圖[/caption]
機器人的個性化設計
CUI可讓使用者產生與真實人類交談的錯覺。為了強化沈浸體驗，需要在一些設計細節上多加著墨：
- 模擬人類的行為模式：依服務主題設定機器人原型為該領域的專家，如廚師、醫生、老師等等；藉專家訪談來了解原型人物的生活、專業、興趣，為機器人建造屬於該領域專家會有的行為模式，並理解專家遇到狀況時會執行的步驟或行為；研究結果可作為設定Bot Persona（機器人性格）與Bot Flow（機器人溝通流程）的依據。
- 模擬人類的情緒反應：視服務想提供的是具專業感的顧問機器人，或是充滿親和力的陪伴機器人。真實的人類偶爾會感到不耐、憤怒，有時也會開心大笑，並非機械化的一個口令一個動作。若要讓使用者誤把機器人當成真實人類，加點情緒觸發到溝通流程裡來調味，會讓機器人更有人性溫度。
- 模擬人類的交友過程：依使用次數（熟悉程度）設計不同的觸發內容。隨著與使用者交談次數越多，蒐集到的使用習慣和喜好也越精確，此時機器人就像閨蜜一樣，在你還沒提出需求之前，就已經懂你了！
- 模擬人類的感受能力：表達對人類的理解、共鳴、同理心，及幽默感，營造使用者對機器人的情感依賴。
設計端與工程端的銜接
AI ⇄ UX；Chat Bot ⇄ Conversational UI
（人工智慧 ⇄ 使用體驗；聊天機器人 ⇄ 聊天介面）
聊天介面在視覺設計方面的工作量已不這麼繁重（但不代表不重要）；介面型態大致由「聊天環境」與「詳細資訊頁」構成。雖然介面數量減少，但更多功夫會落在規劃溝通流程（conversational flow）上；這裡也是與工程端交流最多的區塊，影響著操作的流暢度、以及整個服務的使用體驗。
當擁有人工智慧的聊天機器人被開發時，創造機器人的性格與行為反應就成為體驗設計的核心──你不會創造一個顧人怨的機器人，除非這個服務是拿來激怒人類用的。
待續……
並非每種服務都適合以CUI呈現，而且GUI也不會因為CUI的興起而失去價值、也不會因科技發展而消失。人類在許多時候，還是需要靠圖像來理解和控制。
我們應該把重點放在「如何提供更好的解決方案」，畢竟為使用者創造良好的體驗，才是設計的最終目標。這塊領域還有許多嘗試創意的空間，我一個人的力量很小，需要大家一起參與，先就自己瞭解的部份拋磚引玉。如果有對聊天機器人的互動設計有興趣的朋友，也歡迎一起討論！
