體驗設計新挑戰 Conversational UX 系列 「04 Start First CUI Design<中>」
本文適合（1）初進入 UX 領域 1~3 年的 Designer（2）喜歡探索和了解新領域的 Geeker（2）近期對 CUI/VUI 有興趣的 Anybody
本篇是 Conversational UX 系列的第四篇，是延續上次 Start First CUI Design 的續集，如果你尚未閱讀過上集的話，建議妳先閱讀後在了解本篇內容。
如果你還沒看過本系列的第一篇和第二篇，關於 CUI 入門內容，也建議你可以先看完後再繼續閱讀後續的文章，會對 Conversational UX 有更完整的認識。
上次的文章中，Nathan 跟大家聊了在當前的技術背景與商業環境下，如何去釐清自己的產品是否需要語音交互的能力，以及如果想要開始進行語音設計時，該怎麼樣以更明確的步驟和設計流程進行。
由於在目前的階段，不管是 Amazon 和 Google 的語音設計團隊，都沒有太多對外公開的資料，僅有網路上少數的工作坊視頻，與零碎的流出資料。
以 Nathan 個人的了解，即便連中國一級互聯網巨頭中，負責設計智能語音產品的相關團隊，大多都仍停留在傳統設計模式的延伸，更多仍在進行「電商導購」、「移動應用」等，屬於 GUI 的舊設計工作，對於 CUI 設計系統的研究仍在少數。
但仔細觀察，語音交互技術其實已經漸趨成熟，除了去年底至今大熱的智能音箱外，其實在許多的行業和服務中都慢慢的浮上檯面。Nathan 在上個月去中國的 KTV 時，甚至已經有使用「喚醒詞」的語音點歌服務，只要說出歌名就能點歌。
因此可預見的，接下來的設計工作很大一部分，會開始包含多模態、語音的相關內容，對設計師的挑戰會越來越高。本篇將會快速帶著大家了解，在進行語音設計時，可能會遇到的問題，以及該如何正確的執行語音設計師的職責與工作。
上篇中，提到了「 語音應用服務設計，始於為用戶提供什麼價值 ？」，在開始進行語音設計的項目前，需要深入的進入到場景中，了解用戶可能產生的意圖，以及如何藉由環境中的元素，引導用戶學習如何使用帶語音交互的產品。
雖然語音設計的好壞，與前期的需求掌握度有著密切的關係。但語音交互設計師很重要的工作，也包含在了解用戶的需求後，適當的轉變為技術與算法所需要的資訊。
透過正確的編寫 Conversational Scenario（Mapping Flow），才能確保用戶進行語音交互的體驗。
What User May Said to you
一個完整的 CUI/VUI Mapping Flow Document，可能會是個具十分複雜鏈路和許多邏輯判斷的架構文檔。而 <Intent> 則是扮演著這份文檔中，最重要的角色。
“ INTENT 是語音設計和算法開發中，最重要的溝通要素”
站在用戶體驗側的 CUI Designer，大多時候都是使用 Intent 來與開發團隊溝通，確保用戶的輸入與輸出都依照設計師所設計的情境。
Intent 中，用設計語言的方式來表達，其實可以概略分為 Listen(ASR)、Action(Execution)、Reply(“NLG”) 三種組成元素。
與 NLU、NLP 所表達的 Intent，雖然是相同名稱，但其實是兩個不同的概念。這部份牽涉到人工智能的自然語言理解（NLU）實現，所以在說明前，需要簡單的科譜一下技術背景與實現方式。
這邊以智能語音交互中，最為常見的框架語義表示模型（Frame Semantics Representation Model）為例子。
在 NLU 模型中， Intent 其實單純指意用戶意圖，在複雜的理解模型實現中，相同 Intent 可以聚類為 Domain。
而通用智能與垂直智能的差別，最簡單即在於 Domain 的多寡，其中涉及到的理解與開發複雜度，牽涉到「上下文依賴」，並不只是單純的倍數關係。
舉個例子來說：
User：買張火車票
Bot：請問你要去哪裡？
User：寧夏User：放首音樂
Bot：請問你想聽什麼歌？
User：寧夏
其中最直接表示意圖的用戶輸入語料「寧夏」，在不同的場景、不同的上下文關係中，指的是完全不同的意圖。
而從設計語言的角度出發， 以 L-A-R 三要素組成的 Intent 表達，會更加貼近用戶進行語音交互的場景，如此也能幫助設計師與項目成員，更加沈浸的對用戶情境進行還原。
Collect what user may said about same intent
對當前的語音交互技術而言，其實會依賴兩個主要問題，如果沒有一個好的解決方案的話，導致的就是可怕的使用體驗。
01 ASR 的識別結果
02 NLU 理解模型的數據標注
兩個問題，其實都是圍繞著 Intent 而產生的，一個在前，一個在後。
其實在業界有句玩笑話，「01 ASR 識別結果」決定了語音 A.I. 的成敗。做再好的 NLU 模型，遇到了糟糕的拾別結果，最終也是變成語音智障。
更不用說，NLU 模型的優化和語音智能的成長，其實也是依賴於這些優質的輸入語料。撇開因為技術或硬件所導致的錯誤，從人類語言學的角度來說，對話行爲的多樣性，其實也是造成 NLU 理解錯誤的一大原因。
由於語音交互不像界面交互，可以明確的透過圖像告訴用戶操作路徑，並根據當前情境反饋是否錯誤，限制了用戶的操作選擇。
語音交互的好處雖然是釋放了用戶的操作限制，但帶來的就是由於沒有邊界，也因此無法明確的讓用戶知道，當前操作是否會有錯誤的可能。
因此 CUI Designer 在使用 L-A-R Intent 來與算法開發溝通時，藉由挖掘多用戶在當前場景＋相同意圖下，可能進行的語料輸入。掌握語言的表達多樣性和范化語料都是幫助語音交互體驗提昇的一大重點
舉 Nathan 在上海的地鐵購票項目中的例子來說，下面這種 ASR-Intent-TTS 的 Mapping Flow Design Document ，其實就是根據上面所提到的 L-A-R Intent 結構所設計的。
針對不同的 Intent 給出不同的泛話語料和對話結構，幫助 NLU 模型開發進行完善的 Schema 設計。
目前 Nathan 團隊中的語言學博士『超級大正妹～～～』，主要工作正是基於自然語言理解與語言交互模型，製作 NLU Schema，所以 CUI Deisgner 也需要瞭解相關的實現機制。
針對語音的輸入，其實還有許多在實際設計時可能會遇到的問題，但是簡單而言，Nathan 會想要花這麼大的篇幅跟大家詳細解釋的原因，也正在於進行 CUI Design 時需要正確的認知到，語音輸入的結果對語音交互的體驗，也會起到很大一部分的作用。
“ 對用戶情境的了解程度，決定了語音交互的成敗 “
總的來說，Conversational User Interface Design 是一種
01 需要深入挖掘場景和模擬情境的設計角色 ,
02 以敘事類型和意圖驅動的設計方法 ,
03 基於規則且模版化的工作流程。
如果對劇本編寫有所涉獵的同學，其實可以注意到，設計中需要注意許多情境模擬的部分，就像是採取了上帝視角對角色的行為進行設計。
當然，在 CUI Designer 的設計工作中，其實這類型的語音交互設計只是其中一部分，牽涉語音交互產品時，其實也有服務設計、硬件設計、界面設計等，與傳統 GUI Designer 的設計職責相同的工作。
可以說 CUI Designer 是由原本的設計師角色，更加的往工程實現方向靠近。是一個理性與感性共存，要懂開發又要懂體驗的設計角色。
“ CUI is not Change the World, it just Make it Better ”
本篇是 CUI 設計系列的第四篇，結合系列文的第三篇，透過更為實際的技術說明與案例介紹，希望能幫助大家對 CUI 這個領域有更全面和更貼近的認識。
系列文的後面，Nathan 目前預計還有幾個想跟大家聊聊的話題：
05 How to Reply your User
06 How to Test CUI/VUI Experience
07 How to Design CUI UX
希望透過這系列文，幫助大家在語音交互的革新中，也能及早做好準備。
如果你對於 CUI 設計也有不同的看法，或者發現 Nathan 的文章中有錯誤的部分，也歡迎你隨時讓我知道。有些名詞與定義，可能都是目前這個領域中還屬於比較模糊的部分，部分比較敏感的內容，也礙於保密協議問題無法公開。
或許部分內容再過一陣子，就會證明並不完全如此，甚至技術突破了一定的瓶頸，讓基於當前限制的設計方法，會產生變化。
這是一個隨時都在變化，隨時都在進步的領域：）
如果你喜歡我的文章，請給我 1~4 個 Claps ，如果你想要看到更多 Nathan 分享更多關於 Conversational UX 的內容，請給我 5~以上的 Clpas，對這個領域有興趣的話，也可以隨時騷擾 Nathan 關於 CUI 的資訊囉～
See ya~
-Nathan
