前面幾篇文章中講了語音産品的一些認知，産品的實作原理和VUI設計原理。本篇梳理設計對話産品的流程。
關聯文章：
1.解構語音互動産品–認知篇
2.解構語音互動産品–人工智能AI技術
3.解構語音互動産品–VUI設計原則
目錄
- 一、VUI設計流程
- 二、業務需求分析
-
- 1.目标與功能
- 2.定義機器人角色Persona
- 3.早期測試：Wizard of Oz（綠野仙蹤方法）
- 三、撰寫對話
-
- 1.考慮對話場景
- 2.梳理對話邏輯（流程概覽）
- 3.意圖&實體映射
- 4.撰寫對話
- 5.早期測試：模拟朗讀
- 四、原型設計
-
- 1.使用WOz方法
- 2.使用工具建立
- 五、使用者測試
-
- 1.早期測試
- 2.可用性測試
- 六、建構聊天機器人
-
- 1.使用現有Bot平台實作
- 2.自主研發
- 參考材料
一、VUI設計流程
VUI設計流程可梳理為以下幾點：
1.業務需求分析
2.撰寫對話
3.原型設計
4.使用者測試
5.開發實作：建構機器人
6.資料分析與疊代
二、業務需求分析
1.目标與功能
設計目标
語音産品要考慮使用者場景，進行調研分析，進而設定産品目标。
例如：基于酒店服務場景的語音助手，目标是盡可能優化使用者在酒店内的體驗; 基于旅行場景的機票預訂助手，目标是規避使用者繁瑣的規劃和預訂流程，讓使用者高效完成機票預訂; 基于人力資源場景的招聘助手，目标是輔助HR高效地完成整個招聘流程。
所需功能
為達到産品目标，需要分析應該做哪些功能，哪些不應該做。以訂火車票的場景為例：
1）應該做：
- 訂票、退票、改簽、查詢業務。
- 火車票業務中一些常見問題解答
- 簡單的問候和答謝
- 與出行相關的天氣查詢功能
2）不應該做：
- 漫無目的的閑聊
定義了所需功能後，對功能做優先級排序，建立最小可行性功能，并持續優化和疊代。
2.定義機器人角色Persona
VUI設計原則中提到建立角色畫像的重要性，在火車票助手的例子中，機器人角色為：
- 服務品牌：專業、高效
- 派生個性：認真負責，友善，不會太随意。像私人助理。
- 語音特質：語調平緩，語氣溫和
3.早期測試：Wizard of Oz（綠野仙蹤方法）
為了探索使用者行為，在開始撰寫對話前，可以通過一些早期測試方法，來得到一些決策分析。這裡提到一個概念：Wizard of Oz方法，國内翻譯成“綠野仙蹤”方法，Wizard的中文意思是“魔法師/巫師”，是以直譯是奧茲魔法師。這種方法描述的是一種測試或者疊代設計方法論，直白的說，就是由真人（“巫師”）來模拟計算機，與使用者進行互動。
WOz方法用于系統設計早期，通常在開發之前。具體怎麼操作呢？比如在釘釘上或者其他消息應用上，注冊一個賬号，換上機器人的logo和名字。然後假裝自己是機器人，向目标使用者介紹自己，并發起對話引導。在與使用者對話中，可以提前發現一些問題。比如：發送推薦的連結時，是否搭配上一句話更自然？哪些地方更适合用按鈕？發現使用者回複問題的不同方式，以及一些沒有料想到的對話等等。
除了WOz方法，還可以用“面對面”與目标使用者交談的方法。
三、撰寫對話
1.考慮對話場景
撰寫對話之前，要考慮對話的場景。正如谷歌VUI設計原則中提到的核心要點之一：突破架構去思考。
1）新手引導示例對話，如問候語，引導語。
2）業務的正常對話，即最優路徑。
3）異常情況的修複對話，比如系統沒有聽到或者沒有了解使用者的話的示例、使用者訂票時變更、使用者取消意圖等。
4）幫助流程的對話。使用者請求幫助。
5）回報流程的對話。系統向使用者收集意見/服務回報。
2.梳理對話邏輯（流程概覽）
梳理上述場景中的邏輯的各個流程：新手引導流程、主流程、異常對話流程、幫助流程、回報流程等。
比如訂火車票的“訂票”功能異常對話的資訊變更邏輯流程，如下圖：
異常對話除了資訊變更的情況，還包括：意圖變更、取消訂票、語音無法識别、語義無法了解、糾錯等情況。
3.意圖&實體映射
1）意圖即我們說的功能，比如訂票意圖、幫助意圖、回報意圖。
将使用者表達意圖的關鍵字表述出來，這些關鍵字将啟動意圖。例如訂票意圖的關鍵字：我想訂，你好，到北京，明天的票，幫我買/訂…
2）實體是從使用者處收集的變量，比如“訂票”意圖的實體有：
- 出發時間{時間}
- 出發站點{城市名稱}
- 到達站點{城市名稱}
- 火車類型{G高鐵、D動車…}
- 車次{一段字元串}
- 座位類型{特等座、一等座…}
對話的目的是達成這些實體的互相了解。可以通過使用者輸入實體資訊或者以富控件（如按鈕）的形式收集。
意圖和實體的映射會在建立機器人相關技能時使用。
4.撰寫對話
完成上述事項後，就可以開始撰寫示例對話腳本了。比如訂票的最優路徑的對話可能是：
使用者：幫我訂一張從上海到南京的火車票
BOT：好的，你想幾時出發？
使用者：明天下班後的時間段吧
BOT：收到，對座位有要求嗎？
使用者：沒要求
BOT：為您找到的車次和資訊如下，确認下單嗎？
使用者：好
BOT：已為您訂好11月13日晚上7點到南京的票。
5.早期測試：模拟朗讀
建立了示例對話後，進行模拟朗讀。谷歌在其指南中介紹了工具：actions on google模拟器）
除了使用工具，也可以與其他人一起對劇本進行朗讀，一個人扮演機器人，一個人按演使用者。這個測試可以感覺對話是否自然，有重複嗎，同詞與角色形象是否比對等。
四、原型設計
現在大多數的語音産品，都會有螢幕顯示。比如APP中的語音互動功能，車載機器人的螢幕，音箱的螢幕等。此類對話産品的設計，除了CUI設計，還有GUI設計（GUI除了展示資訊，還有引導使用者對話的作用。）
是以需要定義從Bot接收使用者輸入到輸出結果的整個運作過程中，涉及所有流程的GUI、對話UI設計。
原型設計可以使用Wizard of Oz方法，也可以使用工具建立。
1.使用WOz方法
以真人假扮機器人模拟對話腳本的執行，能提供低保真原型。比如不能顯示按鈕等控件。
2.使用工具建立
一些可視化制作工具，通常是無需寫代碼的Chatbot平台，內建了AI功能（NLP和語音技術），還可以托管機器人。 比如botsociety工具，用于建立原型，将對語音體驗的關注差別開來，主要關注非語音的富互動。以下是我使用工具建立的旅遊助手的景點推薦用例。
操作界面如下：
BOT SAYS 是機器人的輸出，類型有文本、圖檔、輪播圖、快捷回複、網絡視圖、清單、按鈕。USER SAYS是使用者的輸入，類型有文字、圖檔、位址上傳、語音（暫時未開放）。
效果圖如下：
支援将對話Export為GIF、MP4或AVI格式，目前免費版隻能一次機會，通過更新版本（付費）和邀請好友才可獲得更多機會。
五、使用者測試
1.早期測試
使用者測試越早越好，前面提到的一些方法均屬于低保真的測試方法。比如：
- 撰寫示例對話，并模拟朗誦。
- APP原型測試。在VUI完成前就進行GUI原型測試。即讓使用者在原型上進行測試，比如滑動頁面、按下按鈕、及操作部分功能。
- 綠野仙蹤方法：在VUI測試時，巫師必須做一些實時動态的解讀，并判斷使用者的這句話在真實的語音識别引擎下能否被識别。
2.可用性測試
可用性測試是通過觀察使用者使用産品完成典型任務，發現産品中存在的效率與滿意度相關問題的方法。
在《點石成金》一書中講“應該什麼時候測試”時指出，可用性測試是需要在整個開發過程中持續進行，比如讓使用者測試同類競品、現有産品、手繪的草圖、原型圖等都是可用性測試的方式。是以在上述的早期測試中，隻要能收集真實使用者的資料的測試都屬于可用性測試。
除了建立一個模拟機器人的模型，還可以開始建構真正的機器人（建構方法下文會提及）讓真實使用者進行内測，這是抵達生産階段最快的路徑，使用者用真實的資料測試真正的機器人，開發者可以獲得實時和準确的回報。
可用性測試的步驟一般為：
1）定義任務
選擇核心功能、對話的主流程、高風險區域作為任務，并為使用者設定場景。
在撰寫任務内容時要注意：隻要描述任務目标即可，避免提及相關的指令和操作步驟。
2）招募測試參與者
在目标使用者中抽取測試使用者，可選擇有同類産品使用經驗、完全沒有同類産品使用經驗的使用者。
參與者人數：5名以内。可用性專家Jakob Nielsen推薦選擇五名使用者進行測試（關注成本投入，5名以上投入産出比ROI會下降）
3）設定環境
準備安裝了可測試運作的機器人的APP或者電腦
4）觀察和訪談
觀察并記錄使用者在執行任務中做了什麼，說了什麼，遇到了什麼問題。
- 開始測試前，向使用者說明測試是讓他們幫助改善系統功能，任務失敗也不會有什麼問題。
- 測試過程中，不要幹擾和誘導使用者執行任務。使用者在執行過程中遇到困難也先讓他們自己解決。 要求使用者在執行任務時，說出自己的想法。
- 重點觀察和記錄使用者在什麼界面說了什麼做什麼了。
- 在每項任務完成後，向使用者進行提問
VUI可用性測試時還要重點關注以下事項：
- 如果使用者知道可以與系統對話，那麼使用者知道他們什麼時候該說話，什麼時候不該說話嗎？
- 在語音識别功能就緒之前，他們會說什麼？系統如何捕捉現實語音？
5）資料分析
測試完成後，統計使用者的任務完成率、完成任務時長、錯誤資料和類型、使用者對産品的滿意度的評分。根據統計的資訊，對問題進行描述，找到使用者痛點和分析使用者問題的影響程度。
6）改進和疊代
- 按照問題發生的頻率、嚴重程度、修複成本進行排序，同時給出相應的解決方案建議。
- 給出問題修複的優先級，制定修複計劃。即哪些問題在這個版本要修複，哪些問題可以在下個版本解決。
- 問題修複後，需要再次進行回歸測試。
六、建構聊天機器人
建構機器人的方法，簡單可分為兩種：
- 使用現有Bot平台實作
- 自主研發
1.使用現有Bot平台實作
1）可視化制作工具和內建開發環境IDE
- 無需寫代碼
- 內建了AI功能
- 可以托管你的機器人
此類非編碼Chatbot平台有：Flow XO、 PullString、Chatflow、Chatfuel、Botsify、Pandorabots、Automat、Recast.AI、Imperson、KITT.AI等。
2）人工智能AI服務
- 可以使用文本或可視化的方式處理對話，讓AI來管理和處理與使用者的對話
- 可以托管你的機器人
- 可以調用API提供AI處理服務
此類編碼Chatbot平台有：Google API.AI、IBM Watson、微軟Azure Bot、Facebook Wit.ai、 Microsoft LUIS、Msg.ai、Semantic Machines、Reply.ai、ManyChat 等
3）SDK和機器人架構
例如：Botkit、Microsoft Framework、Slapp、Twilio SDK
除了國外的Bot工具，國内也有很多Bot平台可以建構機器人。
1）沒有NLP基礎，工程能力、機器學習能力和KG能力也能搭建的聊天機器人。比如海知智能-ruyi.ai
2）對NLP有了解，要搭建任務型對話，實作多輪對話等，可以使用百度UNIT、騰訊雲小微等。
如何在這類平台建構對話技能，百度UNIT的文檔中也有很詳細的描述了，并且也有實用範例。簡單來講有5個步驟：
1）建立技能
2）配置意圖及實體
3）配置訓練資料
4）訓練模型
5）驗證效果
具體可以檢視以下連結：
https://ai.baidu.com/docs#/UNIT-v2-guide/top
https://ai.baidu.com/docs#/UNIT-v2-sample/top
也可檢視 人機對話系統全面了解中對機對話開放平台體驗（百度DuerOS）
使用這類平台的自然語言處理能力（技能平台），再結合其提供的語音技術，就可以實作語音的互動了。
2.自主研發
如果要自主研發，一個執行簡單問答任務的聊天機器人，需要搭建一個資訊檢索IR架構。一個能執行任務和複雜問答的聊天機器人，需要完整的語音互動架構，包含ASR、TTS、NLU、對話管理、NLG、知識圖譜等功能，要考慮多輪對話的話，還需要一個多輪架構。
自主研發優點在于靈活，可根據自身業務控制機器人和流程。缺點在于學習難度大，機器人要更長時間上市，開發時間長，對工程資源有依賴性。
最後，機器人上市後，需要進行資料分析和持續疊代。
參考材料
《聊天機器人：對話式體驗産品設計》by Amir Shevat
《語音使用者界面設計》by Cathy Pearl》
《點石成金》by Steve Krug
從0到1建構聊天機器人
十大聊天機器人平台推薦
實操平台：百度UNIT平台、騰訊雲小微、海知智能-ruyi、Bibotsociety