在上一篇的文章（從「框架語意模型FSR」到「多模態設計」）最後，我們提到了抽取用戶在旅程中的意圖，這一篇則是開始更深的撰寫對應每個意圖中的LAR細節，以及CUI該用什麼樣的方法被測試。
前情提要完，以下為正文開始為逐字稿正文，如果你能看到這邊，那請收下筆者的膝蓋，你對CUI真的很有愛RRRR。
第一階段的工作坊，我們主要是找出場景不同的流程，不同的維度，用戶可能會產生的一些需求點。第二個是我們去思考在這個場景下用戶可能會需要的硬件能力去跟用戶產生交互。剛剛工作坊的部分感謝所有參與者都把用戶可能的「意圖」都抽取出來了。
最基本的事情，除了抽取「意圖」外。在撰寫LAR表時也要注意以下四大點，分別是「1.多任務」、「2.一致性」、「3.語境意圖」、「4.非核心插入」
1.「多任務」即是在同一個流程節點中，用戶可能需要同時做的行為，例如在導航的時候用戶可能要使用「問詢」也需要「操作觸屏」去看所在的地理位置。
2.「一致性」則是語音回覆的形式是否有一致，不會一下子很有禮貌，一下子又給人感覺很粗魯。
3.「語境意圖」則是在語音交互的時候會有一些上下文的關係，這樣的上下文關係我們如何幫助用戶完成需求。
4.「非核心插入」在GUI的領域大家比較不常碰到，但是在VUI中可以說是天天出現，用戶在主線上產生的支線意圖，我們就叫做「非核心插入」。比如用戶進入肯德基POS的一個問詢機，用戶說「我今天想點一個炸雞」、但今天如有一個用戶中間說「我想要麥當勞的炸雞」或是「我不想點炸雞了」，這樣子搗亂的情況是成立的。在語音交互的狀況下，會有很多干擾的意圖會產生，這些狀況設計師要考慮進去。
第一，先來講「多任務」，為什麼我們會說「多任務」很重要。在多任務下我們目前分了三個類別分別是一問一答的「問答操作」，像是「天貓精靈你今年幾歲？」、「你現在心情開心嗎？」「我現在心情很不好」之類的，想必大家都很能理解。
第二是「內容查詢」這個東西跟問答有點像，李白是誰？杜甫是誰？周杰倫是誰？這邊要特別注意，當我們把資料送給用戶的時候要注意長度。根據阿里巴巴自己的研究，用戶聽了大概十三秒就沒有注意力了。
故此，內容查詢最大的重點就是，如何在13–18秒裡用精華的訊息放在很簡短的文字約20–30字的訊息裡面給用戶。當超過30字以上的內容，用戶的心智負荷就會往上飆了。也就是說當天貓精靈在做新聞內容的時候，大家都以為只是把網路上的文字播放出來，其實阿里巴巴會有兩個人員專門為每日頭條的新聞內容做濃縮編輯，去把他做成適合語音播放的內容。。
第三則是服務應用，服務應用是最難且最有價值的一個東西。比如說我今天要訂餐點，服務應用不是一問一答，而是把時間的維度加進去進行有意義的交互。從需求產生到需求完成，他會需要不間斷的跟機器進行交互，所以機器就必須要在下一階段帶給用戶下一步驟的信息。
你可能需要音箱的播放、IOT家電的操作。這就是LAR中的ACTION所要作的事情。當用戶的操作是錯誤的時候，你必須在ACTION的地方把用戶拉回來正常的邊界上。設計師必須很明確的跟用戶說「第一你無法做什麼？」「第二你可以做什麼？」透過這個方式你才可以把用戶往下一個步驟帶。如果你不這樣子引導用戶的話，用戶就會開始產生「非核心插入」，故此他的需求就沒辦法完成。
在語意語境下，又會繞回來講到設計語言的INTENT，身為設計師的我們必須先行判斷。ACTION方面，則是基於這個意圖我們要如何回覆？我們在ACTION步驟的判斷上，需要去判斷他是在流程的前還是流程的後？在REPLAY這個步驟，設計師才能回覆用戶，到底要讓用戶進行下一步驟的引導還是附加能力的引導。所以LAR其實可以很好的將設計師的邏輯發揮出來。
LAR只是意圖的小小點，MAPPING FLOW其實就是把LAR組成更大張的流程圖。他對應到GUI就像是我們服務設計常常在講的UJM，只是我們把UJM邏輯化了，技術表達式化了。
另一個要特別注意的是，在常人對談的範例中不會出現不可分的狀態，在一般人類的交談過程中，我們不會出現系統錯誤。
不可分的狀態用GUI的例子來舉例就是不會出現404的狀態。這件事情會在GUI上成立，但是在CUI上面不成立，這到底是為什麼？
因為在CUI上用戶並沒有看到你所提供的服務內容，所以他所操作的任何事情都是成立的。可是我們可以讓用戶在超出我們設計邊界的時候提供其他操作把他引導回來，例如「你說的這個服務我目前不了解」、「你說的這個服務我目前不支持」、「我目前支持哪些服務」，用簡單的語料把讓用戶拉回來。所以在語音交互裡面沒有所謂錯誤，如果錯誤那就代表設計師沒有做很好。如果當你因為硬體、軟體的問題發生錯誤，你可以透過回覆、用戶意圖的理解去讓用戶完成他要想做的事情。
接著語音交互還有另外一個重點是「非核心插入議題」，這些又牽扯到場景輔助資訊。我們又拿高鐵的例子來說明，語音交互畢竟他「不可視」，再沒有屏幕的狀況下，用戶會想要有「我剛剛買了幾張票」。
再者用戶覺得語音真是太傻了想要找「人工櫃台時」，這就是我們俗稱「逃脫」的非核心插入。這時候用戶想要離開該交互時，我們是否能把他導入到其他功能，讓用戶做自己想要做的服務。
工作坊現在要接近尾聲，去年我們阿里巴巴在跟大家分享什麼是語音交互，今年我們更多在著眼努力「如何將語音交互達到擬人化的過程」。
目前為止阿里正朝向讓語音更有人格，讓用戶產生更多的情感價值連結。例如在不同場景中，我會需要一位很聰明的女性助手，我們要如何把女助手的特徵給抽取出來，做成一塊回應模版，去加入到我們的硬體設備中。
所以今年我們將做更多關於語音行為模式的設計，「讓語音聽起來像誰？」甚至是把GUI中的「個性化」導入到語音交互來，隨著你使用次數用來愈多，利用演算的方式去越來越符合你的內容跟需求。像是在淘寶APP中，我們會隨著你查詢的商品種類，進而在APP首頁中的商品資訊中去算出推薦適合你的產品。
最後有人在問，CUI到底要怎麼測試？其實CUI發展至今有非常多的測試方式，但傳統在GUI上所用的放聲思考法（Think-Aloud）是行不通的。業內最常用的有巫師觀察（Wizard of OZ, 綠野仙蹤法）、CUI 評估啟示（CRT）、可用性測試。
其中Table Reading是成本最低的一種檢查方式，他能達到二種效果分別是檢查設計師自己撰寫的內容是否有通順？是否有過多的贅字？另外則是語句是否言不及義？在知識結構的邏輯上是否有不合理的地方？
另外一個業內最通用的方式則是巫師觀察，他其實有點像GUI中的眼動儀，觀察者與受測者分別坐在不同的房間，觀察者使用電腦監控受測者去捕捉用戶的表情狀態遲疑，當用戶說了一聲「ㄟˊ」的時候。這就算是語音交互體驗不好的一個訊號。只是很可惜今天因為時間的關係沒辦法講太多，希望大家都能收穫滿滿的回家，謝謝。
在撰寫的過程中，冠芠還跑過來跟我們說要小心「非核心插入意圖」，因為這件事情是新手很常犯的錯誤之一，但沒想到我們也毫無意外的踩了新手的坑XD。
最後的測試部分，主持人請台下其他組別成員上來踢館進行TABLE READING的測試，我們組內沒三句話就GG了(淚)。
（以上三篇文章系列的照片CREDIT(Miguel Wu、Justin Six、Vivienne、若羚、VIK提供）
CUI領域的東西真的頗多，整場聽下來腦子都會熱熱的。但我們組內成員感覺都玩的很開心，希望這次工作坊結束之後大家在UX領域也能經常見面。
— — — — — 全篇整理完畢，真是累死我了QQ — — — — —
若想要再燒腦溫習一次可以連結下列文章前往：
