體驗設計新挑戰 Conversational UX 系列 「03 Start First CUI Design<上>」
本文適合（1）初進入 UX 領域 1~3 年的 Designer（2）喜歡探索和了解新領域的 Geeker（2）近期對 CUI/VUI 有興趣的 Anybody
來到 Conversational UX 系列的第三篇，本系列的前兩篇文章著重在跟大家說明，語音設計崛起的背景跟目前的發展現狀。這次的文章會開始帶著大家試著了解該如何進行語音設計。
如果你還沒看過本系列的第一篇和第二篇，關於 CUI 入門內容，建議你可以先看完後再繼續閱讀本篇文章，會對 Conversational UX 有更完整的認識。
2017 年是語音設計開始展露頭角的一年，2018 年開始隨著類 A.I. 和 Voice Tech. 等相繼技術領域的數據累積。可以預見的，會有更具突破性和成熟的應用開始陸續進到商業環境中。
如果借鏡歷史的發展，可以知道每個商業體在不同的階段，都會藉由當時的介面去跟使用者產生交互，從 PC<Web> 到 Mobile<App>。因此隨著對應技術的成熟，向語音應用的變遷其實指日可待。
從今年的 Chatbot 應用的大量發展，其實可以部分說明了這個現象，雖然礙於數據和技術的限制，Chatbot 目前能達到的成效還算低，但這些都只是時間的問題。
同理 Voice App 也是如此，在 2018 年隨著各家的語音 ASR/ TTS 的 API 漸趨成熟，NLP/ NLU 開放訓練模型後，Nathan 個人是覺得，隨著這些基礎建設的成熟，可以預見的會帶來一波現象級爆發。
因此在早期就了解 How Design CUI Design，相信絕對不會是一件吃虧的事情，而由於本次的內容會比較龐大，因此會分為 <上> <下> 兩篇文章來介紹。
OKay, Anyway，趕緊進入正文吧！
What Product should using Voice User Interface
更準確的說是，在當前的技術條件下，什麼「產業」或「領域」適合優先採用語音交互界面。
語音體驗設計系列的文章刊出後，Nathan 收到許多私下的詢問，其中一個問題類型即是「該怎麼把語音交互能力加入現在的產品中」，再進一步的了解後，發現許多提出這類問題的人，大多犯了一個剛接觸語音設計的誤區。
Voice User Interface 雖然有著自然交互的優勢，但也並非萬靈丹，在當前的時間點為了語音而語音，帶來的可能反而是災難的使用體驗。
“ Design the Right Thing is better than Designing Things Right ”
因此在具體分享語音設計的方法論前，想優先說明不同語音技術的特性，以及不同技術當前所適合的應用。
如 體驗設計新挑戰 Conversational UX 系列 「01 Voice User Interface Designer」文中所提到的，語音「雙向」交互是基於語音技術的語音『拾』別（Automatic Speech Recognition, ASR）、語義理解（Natural Language Processing, NLP）和需要能回應使用者的語音生成（Text to Speech, TTS）三部分技術所組成。
三個語音技術所組成的交互應用，即是 2017 年末火熱的 buzzword，智能語音助手/智能語音音箱類型的產品，但於目前的時間點，相對仍是少數大型設計組織所能處理的議題。
因此在這個時間點，大部分的設計師應該更針對這三個語音技術的特型來思考如何應用。
01 語音拾別：主要適用於輸入場景，當在多層級或多類型的交互場景，如果用戶的路徑十分明確時，會比鍵盤輸入或點擊交互有更絕對的優勢性。
典型場景如留言、備忘、通話、搜索、選擇等類型的操作，研究報告指出應用外搜索如 Siri 已佔 iPhone 搜索的 75%，而應用內的語音搜索量也正逐步上升。當你的產品有高用戶輸入需求，且內容相對明確時，選擇語音輸入方式不失為一種選項。
02 語義理解：目前語音 A.I. 主要的瓶頸所在，主要的問題在於垂直服務領域模型和通用智能模型的的數據都不夠完善。
理論上依據使用場景，去細化垂直領域模型中的關鍵實體，並藉由足夠的使用數據來修正實體識別，有機會做出一定水準的垂直模型。但在通用模型會遇到更複雜的上下文理解和相似領域的實體判別問題。
典型垂直場景如智能客服、對話機器人（依行業）等，高重複性與問答場景明確的領域，都能基於此應用。雖然 Facebook Messenger Bot 的嘗試未盡理想，但如果能開放一定的模型訓練能力，有機會往更高一步的水準提升。
（進一步還有如目前使用者的心智教育不足，仍傾向尋求真人服務等問題）
03 語音生成：適合使用於多模態的反饋輔助，比如 GUI 時代的音效即是廣義的語音生成，通常搭配使用者的操作心智、當前場景和使用預期來進行正確的內容生成。
典型場景如互動遊戲、電子問答、操作指示等，基礎的問答型和播報型適合 TTS 的深度使用，但出現選項以及決策的場景時，搭配 GUI 會有更好的使用成效。
因此避免自己侷限在必須達成「語音雙向交互」的迷失，依據目前組織中的技術水平以及產品的使用場景和特性，才能真正地發揮語音交互的優勢。
How to Start Voice User Interface Design
初接觸 CUI/VUI 時可能會感到茫然無序，不知道該如何下手。
但其實在 UX 或是 HCI 領域，儘管有新的交互技術或新型態業務的產生，進行設計時的核心思想以及方式，其實差異不大。
以交互行為的設計來說，Jakob Nielsen 所提出的十大易用性原則 ，不管是在服務設計領域，還是在 GUI 的交互設計中，都仍適用來簡易的評估設計有效性。因此在 CUI/VUI 這種，同樣基於五感通道的人類交互系統中，一樣適用。
儘管 CUI/VUI 是別於以前的設計過程，但畢竟是屬於 UX 設計領域的一環。因此對「人」的需求定義過程，是差異不大的。甚至會相較於 GUI 和舊有互聯網產品，對於使用者的需求定義需要更精準與全面。
Find out and Define What User Real Needs
當你真正開始 CUI/VUI 的設計工作時，請謹記在心中並不斷的提問組織和自己。
“ 語音應用服務設計，始於為用戶提供什麼價值 ？”
不管是藉由在產品中加入語音交互能力，來讓使用者縮短接觸成本，還是於語音平台上搭建一個具業務屬性的應用（ex. Alexa Skills），關鍵即如前面所提到的，是要找到相比原有操作過程更易用、更便捷的用户訴求。
因此是藉由更大資源或週期的用戶研究工作，來確保對使用者的了解，還是透過更具可視化或描述性的定性工具，都能幫助整個設計團隊和設計師本身，更好地瞭解用戶在當前場景中確切會產生的痛點，以及使用語音交互能力可帶來的優勢。
上圖即是示意使用者在一個旅館房間內的場景中，可能產生的訴求。找出及定義觸點後，再透過行為輪的方式，來解構用戶在當前情境中可能體驗的過程，由此也能明確語音交互能力，在過程中須具備於什麼樣的幫助，並且需幫助用戶達成什麼目標。
當然，定義需求與描述場景的方式，完全不只有上面所示意的這種方式。比如透過「情境調研」，這種常見在前期挖掘用戶需求出現的方式，即是很好的定義場景的方法。
當我們再將定義問題的複雜度，降級到更具現實條件的限制下時，或許比如 Adrian Zumbrunnen 將自己的網路搭建成 Conversational bot 的方式一樣，即是一種輕量化的 CUI 設計嘗試。
01 訪問網站的人是誰？
02 他們來到這的目的是什麼？
03 他們會想知道什麼關於網站的信息？
04 他們對於想了解的信息有什麼期待？
05 我該怎麼回應這些訪問人的期待？
06 當我無法滿足訪問人的期待時，我該提供什麼幫助？
上述這些問題都是幫助我們在進行語音設計前，更了解我們所要設計的對象需要什麼能力，而不是一昧地用我們理所當然的想法，去設計給 TA 的語音服務。
當你所收集的用戶訴求越準確，越能做出真正具有意義的 CUI 設計。
這樣的思維也能運用在一些語音開放平台，所進行的語音技能設計上。如果你希望在一些目前的大型語音流量入口，比如 Alexa Skills 中提供一個新聞類或互動類的語音應用時，或許可以基於更精準的定義使用人群，以及這些人群所期待的能力，來做出差異化與精準服務。
Define the Conversation Scenario
如果我們再定義場景與用戶需求的階段越完整，我們當然也越了解用戶是從哪裡來、多少種可能行為，以及最終要往哪裡去。
進入具體的設計過程中，也就能越準確的編寫或設計所謂的 Chat Flow / Mapping Flow / Conversational Sheet 這類型的文檔。
一個完整的 CUI/VUI Mapping Flow ，可能會是個具十分複雜鏈路和許多邏輯判斷的架構文檔。
Mapping Flow 中是由 <Intent> 來區別和定義用戶的使用意圖，並依此來設計對應的服務能力，而 <Intent> 主要由三個要素組成：
01 Listen: 用戶進入此情境或發出語料時說了什麼，對應的即是語音技術 ASR 的部分。
結合其他兩個 <Reply> 和 <Action> 要素時，明確用戶說的語料中具有什麼關鍵實體詞時，能幫助算法、開發及測試團隊更準確還原情境。避免用戶真正進行使用時，產生不符合設計情境的狀況。
02 Action：也是基於接收到的 Listen 中對應關鍵詞時，系統該進行什麼樣的處理。
可能是進行回覆，也可能時播報內容，也或許是調取他端服務。不同的 Intent 需要設計不同對應的能力。也因為使用者所進行的任務差異性，產生<任務命令>、<內容播報>、<操作引導>等類型
03 Reply：依 Action 和對應接收到 Listen 中的對應關鍵詞時，進行特定的回覆。
一般來說，通用的語音設計做法會基於不同的 <實體關鍵詞> 組合，來對應設計不同的回覆內容，甚至當某些組合條件中有部分關鍵詞缺失時，也需要透過 Reply-Ask 來提醒或幫助使用者給出正確的關鍵詞，以便進入下一階段的流程。
語音技能的好壞，雖然與前期的需求掌握度有著密切的關係，但 Mapping Flow 承擔著轉化用戶需求情境，以及算法開發還原的重任。因此語音設計在這部分將會需要縝密的邏輯能力，來幫助細化許多特定場景。
What is Next Topic?
本次的 Start First CUI Design<上篇> 主要是說明該如何嘗試，與開始進行語音技能的設計。
Start First CUI Design <下篇>則預計說明該如何透過 ASR 中的關鍵實體詞，來確保落入正確的 <Intent> ，以及如何設計語音 TTS 回覆的部分，和該如何進行語音設計結果的易用性測試。
03 What User May Said to you
04 How to Reply your User
05 How to Test CUI/VUI Experience
Conversational UX 中不僅只有應用與服務技能的設計，還包含如語音 A.I. 相關等形象設計和體驗指標的數據體系，因此不僅是思考方式，許多 GUI 設計方法都會有所不同。
CUI 是理性感性共存，階段分明又相輔相成的領域
CUI 系列進入到第三篇，想跟大家聊聊如何更深入的去了解 CUI/VUI，因此希望透過一次較為完整的引導，讓大家對 CUI 有更全面和更貼近的認識。
由於在目前的階段，不管是 Amazon 和 Google 的語音設計團隊，都沒有太多對外公開的資料，僅有網路上少數的工作坊視頻。因此許多方法論和介紹，大多是 Nathan 在實戰過程中慢慢總結出的。
或許部分內容再過一陣子，就會證明並不完全如此，甚至技術突破了一定的瓶頸，讓基於當前限制的設計方法，會產生變化。因此在了解 CUI/VUI 的資訊時，也建議保持「強觀點弱堅持」的態度。
畢竟這是一個隨時都在變化，隨時都在進步的領域：）
如果你喜歡我的文章，請給我 1~4 個 Claps ，如果你想要看到更多 Nathan 分享更多關於 Conversational UX 的內容，請給我 5~以上的 Clpas，對這個領域有興趣的話，也可以隨時騷擾 Nathan 關於 CUI 的資訊囉～
See ya~
-Nathan
