首頁 » 趨勢分享 » 一個人的聊天機器人設計衝刺 One-Person Chatbots Sprint

我如何只用 6 個步驟，一個人從 0 到 1 打造良好體驗的聊天機器人

在發布《如何設計客服聊天機器人 — 理論篇：探索顧客體驗導向的設計準則》之後，我收到了許多很好的迴響，也不斷思考在實務上一個良好體驗的 Chatbot 究竟是怎麼設計出來的。而這篇文章其實就是《如何設計客服聊天機器人—實務篇》，將以近期我設計的「BotBonnie 教學 Bot」(點擊可開啟 Bot) 舉例，如何將設計衝刺應用在 Chatbot 上。

因為中間會舉一些平台操作的例子，想試用 BotBonnie 的我們提供註冊後的 14 天內體驗完整功能，超過 14 天則調回免費版(無期限) >> 先註冊再回來看文章。

本文目錄・什麼是聊天機器人設計衝刺
・事前準備
・步驟一：定位宣告
・步驟二：顧客旅程地圖
・步驟三：最小可行資訊架構
・步驟四：情境故事板
・步驟五：腳本設計
・步驟六：設計評估
・結語

什麼是聊天機器人設計衝刺 Introduction to Chatbots Sprint

在新創公司裡，常常沒有太多的資源可以執行嚴謹且完整的使用者研究和共創，因此精實 UX 採用了精實創業「建立、量測、學習」的三步驟循環來重塑設計流程，強化了建立假設的重要性，並以快速迭代的試驗來蒐集回饋。Google Venture 的 Sprint (設計衝刺) 更具體地描述了精實 UX 在實踐時的每個步驟可以如何規劃與執行，以有效達成共識的方法解決複雜商業問題。

• 

聊天機器人設計衝刺 Chatbots Sprint 就是應用了設計衝刺的核心精神所提出的 Chatbot 設計流程，包含了 6 個步驟：定位宣告、顧客旅程地圖、最小可行資訊架構、情境故事板、腳本設計、設計評估。

Sprint 相較於 Design Thinking (設計思考)，我認為有以下兩點原因讓它更適合作為 Chatbot 的設計流程框架：

• Sprint 是一個以使用者測試為主要質性用研方法的流程。我自己觀察一些新創公司可能會較為偏好以此方式來取得質性資料而非在前期就進行質性調研，這是在用研成本與價值之間取得平衡的結果
• Sprint 強調一次只解決一個問題。Chatbot 作為一個設計標的，去掉訓練語意分析模型的部分 (也是設計師較難以介入的部分)，相對其他類型的介面產品不需要到很複雜即可滿足企業與使用者雙方的需求，以企業提出的需求而言，在一開始常常只會是一個簡單的概念 (如導流到官網、預約訂位、降低客服負荷等等)，因此適合這個框架

既然說是應用「核心精神」，就代表其實這個流程框架與傳統有所不同。許多公司由於人力資源的關係，從創意發想、腳本設計到機器人建立，很有可能都是同一個人負責的，所以若能有一個只要一個人就能遵從的設計流程，相信可以幫助許多公司開始考慮導入聊天機器人，也能讓承接任務的人更有信心能夠設計出好的聊天機器人。以往 Design Sprint 會有一個 Facilitator (引導師) 來引導工作坊中的共創活動，然而如果機器人設計師 ( Bot Designer ) 能夠依循本文所述進行設計，那麼就「暫時」不用先擔心 Facilitator 的問題。

• 

什麼類型的機器人適合 Chatbots Sprint？

我把機器人分成三種：(1)行銷型 (2)功能型 (3)客服型，而除了行銷型的機器人以外，功能型與客服型機器人都是希望能夠幫助使用者完成某些任務的機器人，因此後兩者較為適合應用 Chatbots Sprint 的框架。

BotBonnie 教學 Bot

首次使用 (Onbaording) 的體驗是 Chatbot 開發平台常見的弱項，在觀察註冊後「新增一隻機器人」以及「開始建立機器人流程」兩個 Activation 的指標數據時，往往會有很高的流失率。

常見的解決方式除了改善易用性、操作流程以外，也會搭配模板和引導教學，過去 BotBonnie 在引導教學上還沒有太多的著墨，因此此次的主要設計問題即為：

如何設計好的 Chatbot 引導流程，來讓使用者成功建立一隻機器人與其流程腳本

事前準備

定義長期目標與設計問題

本來定義設計問題應該是在工作坊中的第一步，但由於是一人團隊的設計流程，這就必須拉到流程外，先確認好了才進行設計。

以 BotBonnie 教學 Bot 為例，我們的長期目標是提升免費用戶轉換成付費用戶的比例，而設計問題就是如何透過初次使用的導引設計提升 Activation Rate。這些長期目標和設計問題就是在例行會議中確認的，因此在這邊我就不刻意規劃怎麼去定義這兩者。

我所用的方法一樣採取設計衝刺中「Map」的階段，列出顧客旅程來找體驗斷點，並共同討論出解決哪一個問題對當前對公司來說相對有效益，那就是接下來這一次 Sprint 要解決的問題。

• 

次級資料蒐集

在開始設計機器人之前，需要準備一些次級資料，以針對設計的議題與目標族群進行初步了解，以我設計的客服類型機器人而言，就包含了「顧客常見問題 FAQ」與「問題意圖/關鍵字 Intent or Keyword」。現在大部分的機器人設計平台在設計的機器人多為以 Rule-based 的關鍵字判斷來給予回覆，然而下一個世代的 Chatbot 勢必會往 AI bot 發展，因此也有公司不使用 Rule-based bot 而是直接建立 AI bot，此時就會需要蒐集大量的問題作為 Raw data，並分析並分類每個問題的「意圖 Intent」，以機器學習的方式建立能辨識問題意圖的模型，讓客服機器人串接語意分析模型的 API。

這份問題清單可以交由原本的客服先行整理，或者是由各個單位的同事進行發想。準備常見問題是為了能夠生成快速且精準的回覆，而了解問題的意圖和關鍵字，是為了更深入理解問題與自己產品/服務的關係，並給予客製化的回覆。

閱讀這篇文章

如果你是「一人團隊」，你沒讀完我還真的不知道怎麼運用這個流程。

如果是多人團隊，為了讓大家對活動內容都能夠有完整的理解和預期，建議參與成員閱讀完這篇文章，如果真的沒辦法，Facilitator 會肩負更重的責任。

正確的團隊

設計衝刺最重要的成功要素就是正確的團隊，團隊成員必須非常了解各自專業領域中的所能發揮的能力、限制與問題。

以聊天機器人設計衝刺而言，1~6 位團隊成員都是可接受範圍，但至少需要一位能對機器人成效負責的公司成員。

必須出席的成員
・Bot 設計師建議至少出席一位
・CEO
・行銷主管/總監
・產品設計主管/總監
・客服部門主管/總監

第一步：定位宣告 Position Statement

設計對話機器人的第一步，是必須找到機器人作為一個內容與資訊的傳遞管道，在眾多管道中的定位為何，而內容生態系地圖 (Content Ecosystem Map，CEM) 和架構定位圖能夠幫助我們釐清這件事。

• 

以 BotBonnie 為例，我畫了一個簡化版的 CEM，圓形代表的是內容傳遞管道，而長方形代表的是內部單位。管道與管道之間代表連結的關係；單位與管道之間代表的就是經營關係；而單位與單位之間代表的是管理關係。如果要詳細一點，可以在線條上標記關係，並且再加上各個管道會傳遞的內容形式包含什麼。

Medium 文章是我們最主要的內容形式，而幾乎所有的內容管道都會連結至 Medium，因此在規劃機器人時，就不能忘記把 Medium 考慮進去，並且可以好好思考如何運用 Medium 豐富的內容資源。

另外，官網架構常常是在設計機器人架構時被大量參考的對象，然而機器人不應該只是把官網複製到聊天視窗內，而是應在考量著重的目的後，找到架構涵蓋範圍的定位。此處應用了上篇的分析結果，把品牌機器人的目的列出來，並各自對應了適合的架構。

• 

在畫完這些地圖後，即可以根據地圖產出定位宣告，形式如下：

• 身為一個以【機器人的設計目的】為目的的機器人
• 機器人的架構應該從【擷取/補充】官網資訊出發
• 並以【內容生態系的主要內容來源】為主要的內容來源

以 BotBonnie 教學 Bot 來說，定位宣告如下：

做為一個以解決首次使用無法完成新增機器人問題為主，了解進階功能為輔的教學機器人，機器人的架構應從補充官網缺乏的資訊出發，並以 Medium 為主要的內容來源。

多人活動進行方法 (30min)
1. 每個人先各自安靜地畫出內容生態系地圖與架構定位圖
2. 貼出來之後 Facilitator 快速地讀過一遍大家的內容
3. 所有人安靜地閱讀彼此的地圖，記錄自己認同與喜歡的地圖，並寫下自己的定位宣告
4. 貼出各自的定位宣告，由 Facilitator 快速地讀過一遍大家的宣告
5. 在每個人決定自己偏好的宣告後，各自唸出並由 Facilitator 將投票結果記在白板上
6. 花5分鐘討論「目的」與「內容主要來源」
7. 由決定者投票選出最後的宣告

第二步：顧客旅程地圖 Customer Journey Map

透過畫出設計問題範圍下的顧客旅程地圖，可以找出可能的體驗斷點，並幫助思考機器人應該怎麼解決這些問題。

以 BotBonnie 教學 Bot 為例，從註冊完之後開始一直到新增機器人，再到發布機器人，中間還會經歷許多細節步驟，例如新增按鈕、設定群發訊息等等，不過這些我都已經在這個步驟之前就畫出來了，所以我在定位宣告之後重新檢視了顧客旅程地圖，此時就可以再拿出來看看在這個設計問題之下影響體驗的地方在哪。

在繪製顧客旅程地圖的時候不需要太過複雜，只要足以展現會影響體驗的步驟以及產品/服務與顧客互動的過程即可。

多人活動進行方法 (30min)
1. 每個人先花1分鐘各自安靜地列出任何想得到的顧客類型
2. 唸出來後由 Facilitator 列在白板上
3. 所有人安靜地閱讀全部的顧客類型，並寫下自認最重要的2個類型
4. 唸出來後由 Facilitator 將投票結果記在白板上
5. 花5分鐘討論
6. 由決定者投票選出前2重要的顧客類型
7. 每個人先各自安靜地寫下2個類型顧客會經過的10個步驟，一張便利貼一個步驟
8. 依顧客類型分類並依序貼出來，各自在覺得重要並會影響顧客體驗的步驟貼上貼紙
9. 拿掉沒有貼紙的便利貼
10. 聚合成一個大地圖，並在不同類型人物之間畫上可能的互動

第三步：最小可行資訊架構 Minimum Viable Information Architecture

在了解顧客在 Onboarding 上的需求後，便可以決定應該要在機器人內規劃哪些功能，以及可能的互動流程，此時便可以應用資訊架構的觀念來初步進行設計。

傳統在設計資訊架構時會使用卡片排列( Card Sorting ) 的方式，邀請 15 位以上的顧客進行認知研究，來決定架構的設計方向。然而在資源不足的條件下，僅能使用手中有的資訊來建立足夠好的假設。這些僅有的使用者資訊資訊可以來自產品本身或官網已經設計過的資訊架構，或是顧客旅程地圖等等。

簡單分類好任務情境之後，可能的型態會是如下圖：

• 

而如果對於結合流程有更多想法，可以利用類似心智圖 (我是用 Miro，比 Xmind 好看很多) 的方法長出更多的任務細節步驟：

• 

• 

什麼是「最小可行」資訊架構

先建立要達成目標的條件下所需的架構，其餘想法等下個 Sprint 再討論。簡單來說，就是一個排序、分版本的概念。

• 

在建立 BotBonnie 教學 Bot 的時候，我原本想把所有教學都在機器人內完成 (完全忘記前面的定位宣告了)，然而我只建了兩個流程就發現太耗時，會趕不上時程。

也是在這邊我就自己定義了一個準則：「如果引導教學要超過 3 步驟才能講完，就改為引導到 Medium」。這個準則能夠幫我避免過多的重工，並讓 Chatbot 和 Medium 發揮各自的優勢。不過這個準則不一定適用每一個機器人，每個機器人要追求的長期目標與設計問題以及所處的工作環境和參與的工作流程，都會影響排序的標準，因此在這邊我只提出一個概念，大家可以彈性的修改與應用。

多人活動進行方法 (30min)
1. 拿出一張 A4 白紙，各自安靜地在20分鐘內畫出資訊架構
2. 貼出來之後 Facilitator 快速地讀過一遍大家的內容
3. 所有人安靜地閱讀彼此的資訊架構，記錄自己認同與喜歡的方案
4. 唸出自己喜歡的方案，並由 Facilitator 將投票結果記在白板上
6. 花5分鐘討論
7. 由決定者投票選出初版資訊架構

第四步：情境故事板 Storyboard

還記得前面的顧客旅程地圖嗎？這邊要做一件非常類似的事：設計「未來的顧客旅程」。情境故事板是一個常見的原型設計方法，透過圖像或文字展現未來情境故事中的「人、物、環境、活動」，以幫助想像設計改善後的體驗產生了什麼變化。

到了這一步，團隊已經具備清楚的目標、Chatbot 的架構與流程，而情境故事板讓這一切具象化，目的就是「減少不必要的開放性討論」，開放性的討論包含了「討論未曾討論過的新想法」、「加入任何不必要的東西」。為了達成這個目的，情境故事板的活動規劃分成兩步驟：(1)測試流程規劃 (2)體驗情境設計。

測試流程規劃

由於已經有一個具體的設計問題「如何透過良好的導引設計，提升 Activation Rates？」那麼在最後的測試階段，就應該要量測每個會影響 Activation 的設計是否能成功達成目的。以 BotBonnie 教學 Bot 為例，可能的測試點如下：

1. 登入後找到客服機器人
2. 透過客服機器人找到教學入口
3. 在教學中找到新增機器人單元
4. 依據單元教學新增空白機器人
5. 依據剩餘單元教學完成建立第一隻機器人
6. 透過客服機器人理解操作介面中尚不理解的名詞

每一個測試點都應該被呈現在情境故事板當中，在設計體驗情境時才不會不小心忽略最重要的設計點。測試點的想法來源可以是顧客旅程地圖(提供步驟)或是設計問題等等已經整理好的資訊，每個測試點也都應該以「Action Step」的方式撰寫，也就是一定要有一個動詞來說明使用者的操作行為。

多人活動進行方法 (30min)
1. 每個人先安靜的在10分鐘內各自寫下6個測試點，一個測試點一張便利貼，先寫起始點，再寫終點，最後再填補中間的4個步驟
2. 貼出來之後 Facilitator 快速地讀過一遍大家的內容
3. 所有人安靜地閱讀彼此的測試流程，記錄自己認同與喜歡的方案
4. 唸出自己喜歡的方案，並由 Facilitator 將投票結果記在白板上
5. 花5分鐘討論
4. 由決定者投票選出測試流程主幹
5. 決定者可以根據討論結果決定是否於主幹再加入一張團隊認為值得加入的測試點

體驗情境設計

情境故事板在這裡會成為團隊對齊對未來產品/服務認知的階段，體驗情境設計讓一個粗略的想法轉化成足夠具體、包含細節的概念。在這一步，可以嘗試定義的項目包含價值、活動與互動規格，當情境故事板定案了，基本上就只剩下腳本的內容本身會影響體驗。如果是一人團隊，這也可以當作初步驗證的原型，了解各部門專家對此的想法，作為後續設計的參考。

• 

• 

多人活動進行方法 (30min)
1. 拿8張A4白紙，其中6~7張各自對應一個測試點便利貼並排序
2. 先於白紙上補齊測試點便利貼想傳達的內容
3. 從第1張開始畫，接著是第8張，最後才畫中間的2~7張tips. 盡量讓每個人都分配到工作，如找素材、分配每個人各自畫哪幾張等等

第五步：腳本設計 Script Design

撰寫工具

到了這一步就是開始認真推銷 BotBonnie 的時候了。腳本的設計方式並沒有一定，但根據我詢問各個團隊的結果，大致分成兩種形式：直敘式與樹狀式。

直敘式是指使用 Word、PowerPoint 等文件編輯軟體，直接線性撰寫文字與搭配圖像示意圖來呈現互動流程，缺點是非常耗時且難以呈現資訊架構。樹狀式是利用 Excel、心智圖等方式，以一目瞭然的資訊架構呈現腳本內容與互動關係，缺點是難以搭配圖片。

然而如果是在 BotBonnie 內編輯腳本，則能達成兩者的平衡。拖拉式的視覺化模組可以輕易呈現樹狀結構，而內容則可以任意搭配不同的訊息格式如文字、圖片、輪播訊息等等，透過良好的設計，Bot Designer 可以一邊編輯模組一邊體驗該模組最終呈現的樣貌。BotBonnie 亦提供了共編功能，也就是只要分配好撰寫的部分，每個團隊成員都可以同時開啟編輯後台撰寫腳本。

UX Writing

如果要說什麼介面最重視 UX Writing，我想大概就是 Chatbot 了。以下列出三點原因：

• 由於 Chatbot 的對話很難設計修復情境，因此必須力求每一句話都能被大部分人理解
• 由於人的認知資源有限，必須力求一個資訊能以最少的訊息數傳達清楚
• 由於 Chatbot 需要透過互動才能持續對話，因此每一句話都必須設計良好的行動呼籲 ( Call to Action，CTA )

從這三點出發，我個人有一些小建議：

• 從客服回饋了解使用者如何描述情境與問題，可以在訊息內同時置入官方用詞與通俗用詞，以輔助命名與任務目標在使用者腦中的配對
• 當訊息為圖片、影片或 gif 時，網路速度可能會成為影響體驗的因素，因為這些訊息類型需要較久的載入時間，如果把他們設為一堆訊息中的最後一個訊息，有可能會因為沒頭沒尾又沒有互動按鈕而導致用戶跳出，建議可以調整與圖片影片相關的文字說明訊息，把文字訊息移到圖片影片之後
• Chatbot 一次發出的訊息數盡量為 3±1。認知心理學當中有一個很有名的 Magic Number 7 理論，說明人的認知僅能一次處理 7±2 組 (chunk) 的訊息；然而隨著時間推演，這個數字變得越來越小，因此保險起見 2~4 是較好的選擇。但如果真的沒辦法在 4 則訊息內說明完畢呢？我的建議是嘗試使用「按鈕」或「快速回覆」讓使用者回覆一則訊息來切段落！如此一來不但能讓使用者喘一口氣，也能確保使用者有跟上機器人要傳遞的資訊
• 如果要進行引導教學，也盡量不要在 Chatbot 內放「超過 3 次互動」的教學流程，由於教學是資訊量很龐大的情境，相較其他流程，引導教學很容易在第 2 次互動就開始大量流失，若真的有太多東西要說明，可以引導至更適合長篇閱讀的環境如 Medium
• 功能型和客服型 Chatbot 不像行銷型很重視情境的營造，因此 CTA 除了做在按鈕上，更可以直接在訊息內文進行引導，同時一些用詞會因為介面改成對話式介面而有所差異；例如請使用者傳圖片，在網頁、表單中使用的是「上傳圖片」，然而在機器人中，則應該是「傳圖片給我」

對話式元件 ( Conversational Components )

這個名詞是我最近聽 HTC DeepQ 的互動設計師演講時聽到的，而我在上一篇理論篇內就有提到相近的概念。

• 

• 

• 

根據不同的機器人目的，可以再細分出不同情境，而每一個情境所要傳遞的資訊內容與呈現方式各自有所差異，因此如在設計 UI 的時候一般，UI 設計師會設計 Components 來讓設計更便利、更有一致性，而對話式介面也會需要 Conversational Components 來達到這樣的目的，因此規劃對話式元件有以下好處：

• 維持設計一致性：當時間一長，或者交由不同的 Bot Designer 設計腳本時，即使有相同的 Bot Persona，還是有可能設計出不同風格的語句和呈現方式，而利用 Conversational Components 就能減少這些問題
• 提升設計效率：當平台出現兩隻以上的 Chatbot，各自又擁有不同個性時，即可以使用 Coversational Components 建立流程再修改內文個性，就能快速完成一個新的 Chatbot，同時符合呈現方式的規範

• 

• 

• 

我已經應用上面的概念幫大家設計好一個智能客服機器人模板 (即將上線)，只要註冊 BotBonnie 帳號，就能夠使用我們提供的所有類型模板。看到這裡想嘗試看看的話記得可以免費註冊，另享 14 天進階功能全開哦！

• 

第六步：設計評估 Evaluation

所有的設計都要經過評估才能證實價值，即使過程中多次確認老闆、合作夥伴與使用者多方的目標與需求，多變的想法與市場讓設計其實很難一步到位，這也是講求快速建立、快速量測、快速學習的最主要原因。

內部評估：利害關係人的目標校準

1. 客服部門：請客服部門主管測試看看，以對方的專業判斷是否能幫助降低客服負荷，他能輕易點出規劃的客服問題是不是真正會被問的問題
2. 商業開發部門/產品設計部門：這兩個部門的主管會了解顧客與使用者最想使用的產品/服務功能有哪些，並檢視你的設計是否符合對方需求
3. CEO：這是最了解公司經營狀況的人，他能評估這支機器人是否真的有機會幫助公司成長，是否符合當初設定的長期目標與設計問題

使用者評估：使用者測試與放聲思考

還記得在第五步規劃的測試流程吧？這就是使用時機！嘗試找 2~3 個符合目標使用者條件的受試者，來試用看看設計好的機器人，可以讓你脫離設計者的角度來看機器人如何被使用。當進行使用者測試時，常搭配的一種技巧叫做「放聲思考 Think Aloud」，簡單來說就是請受測者一邊操作一邊把當下內心的任何想法說出來，如此一來可以蒐集更多的質性資料，以利後續深入了解行為背後的原因。 一次的使用者測試所需時間約 1 小時，以下簡單說明如何執行使用者測試：

1. 簡介自己、測試的目的與流程，確認受測者對於測試的認知與我方相符，並願意接受過程的記錄
2. 施測者示範放聲思考，並請受測者以放聲思考法操作另一個作為練習用的機器人，直至施測者覺得已熟練
3. 測試開始，一個測試點對應一個任務，一次給予一個任務，請使用者在自認完成任務時說「完成了」，在自認無法完成任務時說「需要協助」，並安靜觀察與記錄使用者如何完成任務
4. 每個任務結束後針對剛剛的過程進行短訪
5. 全部任務結束後，針對當次的測試進行訪談
6. 測試結束，給受測者受測費，並等受測者離開後再討論與整理當次發現

使用者評估：行為標籤與流失率

聊天機器人之所以會成為熱門工具，最重要的一個原因就是因為能夠針對單一互動在使用者身上貼上標籤，進而進行分眾行銷與顧客關係管理 (CRM)。

在此的實務用法，即為針對測試點的關鍵互動下標籤，如此一來就可以觀察哪一個使用者進行了什麼互動，進而推測哪一個步驟或議題是使用者感興趣的，之後可以即可向對方推播補充或者相關資訊如：「Hi Daniel，上次有關腳本設計的基礎教學你看完了嗎？在此奉上 Medium 上的詳細教學，相信能幫助你更多！」

BotBonnie 的另一個特色功能就是「互動分析」，透過這個功能，就能看見每一個模組有多少個人看過，並了解在哪裡產生了較多的用戶流失，以量化數據幫助 Bot 設計師了解下次設計時，可以改進的地方在哪裡 >> 註冊看看怎麼使用。

• 

結語

這一次我嘗試提出一個可執行的設計框架，來幫助一人團隊設計一個良好體驗的聊天機器人，也提供一些個人的 Chatbot UX 準則給大家參考。必須注意的是，設計衝刺本身有許多的限制來自於「團隊成員」，要打造良好的體驗就必須對使用者有深刻的理解，而此流程對於使用者的了解來自於主管、專家和其餘已知的資訊，當團隊成員越少，Bot 設計師就肩負越多建立良好假設的責任。不過反過來說，此流程的優點便在於即使是一人團隊也能快速的建立初版的機器人，並且立刻上線蒐集回饋。

感謝大家花時間讀到這裡，對於此流程有任何想法、提問、想討論的地方，歡迎留言或私訊討論！