設計使用者體驗
適用于： SDK v4
您可以建立具有各種功能的 Bot，例如文字、按鈕、影像、以浮動切換或清單格式顯示的豐富卡片等等。 不過，Facebook、Slack 等每個通道最終都會控制其傳訊用戶端轉譯功能的方式。 即使多個通道支援某個功能，每個通道仍可能會以稍微不同的方式轉譯功能。 如果訊息包含通道原生不支援的功能，通道可能會嘗試將訊息內容向下轉譯為文字或靜態影像，這可能會影響訊息在用戶端上的外觀。 在某些情況下，通道可能完全不支援特定功能。 例如，GroupMe 用戶端無法顯示輸入指標。
豐富的使用者控制項
豐富的使用者控制項是常見的 UI 控制項 ，例如按鈕、影像、浮動切換，以及 Bot 向使用者呈現的功能表，以及使用者參與以傳達選擇和意圖。 Bot 可以使用 UI 控制項集合來模擬應用程式，或甚至可以在應用程式中內嵌執行。 當 Bot 內嵌在應用程式或網站內時，它幾乎可以使用裝載它的應用程式功能來代表任何 UI 控制項。
應用程式和網站開發人員依賴 UI 控制項，讓使用者能夠與其應用程式互動。 這些相同的 UI 控制項也可以在 Bot 中有效。 例如，按鈕是向使用者呈現簡單選擇的絕佳方式。 讓使用者能夠藉由選取標示 為 Hotels 的按鈕來傳達「旅館」比強制使用者輸入「旅館」更輕鬆、更快速。例如，在行動裝置上，選取通常比輸入更慣用。
卡片
卡片可讓您向使用者顯示各種視覺、音訊和/或可選取的訊息，並輔助對話流程。 如果使用者需要從固定專案集中選取，您可以顯示卡片的浮動切換，每個卡片都包含影像、文字描述和單一選取按鈕。 如果使用者有單一專案的一組選擇，您可以呈現較小的單一影像，以及具有各種選項的按鈕集合，以供您選擇。 他們是否要求有關主題的詳細資訊？ 卡片可以使用音訊或視訊輸出來提供深入資訊，或提供詳細購物體驗的收據。 卡片的使用範圍非常廣泛，可協助引導使用者與 Bot 之間的對話。 您使用的卡片類型將由應用程式的需求決定。 讓我們進一步瞭解卡片、其動作，以及一些建議的使用方式。
Azure AI Bot Service 卡片是可程式化的物件，其中包含可跨各種通道辨識的豐富使用者控制項標準化集合。 下表說明可用卡片的清單，以及每種卡片類型使用方式的最佳做法建議。
| 卡片類型 | 範例 | 描述 |
|---|---|---|
| AdaptiveCard | 
|
以 JSON 物件呈現的開放式卡片交換格式。 通常用於卡片的跨通道部署。 卡片會採用各個主機通道的風格外觀。 |
| AnimationCard | 
|
可播放動畫 GIF 或短片的卡片。 |
| AudioCard | 
|
可播放音訊檔案的卡片。 |
| HeroCard | 
|
包含單一大型影像、一或多個按鈕和文字的卡片。 通常用於在視覺上醒目提示可能的使用者選項。 |
| ThumbnailCard | 
|
包含單一縮圖影像、一或多個按鈕和文字的卡片。 通常用於在視覺上醒目提示可能的使用者選項按鈕。 |
| ReceiptCard | 
|
可讓 Bot 向使用者提供收據的卡片。 它通常包含要包含在收據、稅務和總計資訊和其他文字上的專案清單。 |
| SignInCard | 
|
讓使用者登入的卡片。 它通常包含文字和一或多個按鈕，使用者可以用來起始登入程式。 |
| SuggestedAction | 
|
向使用者呈現一組代表使用者選擇的 卡片動作 。 一旦選取任何建議的動作，按鈕就會消失。 |
| VideoCard | 
|
可以播放影片的卡片。 通常用於開啟 URL 和串流可用影片。 |
| CardCarousel | 
|
可水準捲動的卡片集合，可讓使用者輕鬆檢視一系列可能的使用者選擇。 |
卡片可讓您設計 Bot 一次，並讓其跨各種通道運作。 不過，並非所有卡片類型都完全支援所有可用的通道。
如需將卡片新增至 Bot 的詳細指示， 請參閱新增豐富的卡片媒體附件 和 將建議的動作新增至訊息 。
如需範例程式碼，請參閱 Bot Framework 範例 存放庫中的下列範例 Bot。
範例 名稱 描述 6 使用卡片 示範所有卡片類型的使用方式。 7 調適型卡片 示範調適型卡片的使用。 8 建議的動作 示範如何使用建議的動作。 15 附件 示範如何接受使用者提供的附件。
設計 Bot 時，請勿自動關閉常見的 UI 元素，因為不夠 聰明。 如對話式使用者體驗 中所 討論，您的 Bot 應設計成盡可能以最佳、最快且最簡單的方式解決使用者的問題。 避免從納入自然語言理解開始的誘惑，因為它通常是不必要的，並引入不合理的複雜度。
提示
首先，使用可讓 Bot 解決使用者問題的最小 UI 控制項，並在這些控制項不再足夠時稍後新增其他元素。
文字和自然語言理解
Bot 可以接受使用者的文字輸入，並嘗試使用正則運算式比對或自然語言理解 API 剖析該輸入。 視使用者提供的輸入類型而定，自然語言理解可能是或可能不是很好的解決方案。
在某些情況下，Bot 可能會詢問使用者特定問題。 例如，如果 Bot 詢問「您的名稱為何？」，則使用者可能會以只指定名稱 「John」 或句子 「My name is John」 的文字回答。
詢問特定問題可減少 Bot 可能合理接收的潛在回應範圍，進而降低剖析和瞭解回應所需的邏輯複雜度。 例如，請考慮下列廣泛的開放式問題：「您感覺如何？」。 瞭解這類問題潛在答案的許多可能排列是一項複雜的工作。
相比之下，具體問題，如「你感到痛苦嗎？是/否「和」你在哪裡感到痛苦？胸部/頭部/手臂/腿「可能會提示更具體的答案，Bot 可以剖析和理解，而不需要實作自然語言理解。
提示
盡可能詢問不需要自然語言理解功能的特定問題來剖析回應。 這會簡化 Bot，並增加 Bot 將瞭解使用者的成功。
在其他情況下，使用者可能會輸入特定命令。 例如，可讓開發人員管理虛擬機器的 DevOps Bot 可以設計成接受特定的命令，例如 「/STOP VM XYZ」 或 「/START VM XYZ」。 設計 Bot 以接受這類特定命令，會提供良好的使用者體驗，因為語法很容易學習，而且每個命令的預期結果都很清楚。 此外，Bot 不需要自然語言理解功能，因為可以使用正則運算式輕鬆地剖析使用者的輸入。
提示
將 Bot 設計為需要使用者的特定指令往往可提供更好的使用者體驗，同時消除自然語言理解能力的需求。
針對知識庫 或 問題和解答 Bot，使用者可能會詢問一般問題。 例如，假設 Bot 可以根據數千份檔的內容回答問題。 Azure AI 服務和 Azure 搜尋 服務都是專為這種類型的案例而設計的技術。 如需詳細資訊，請參閱 設計知識 Bot 和 語言理解 。
提示
如果您要設計 Bot，以根據資料庫、網頁或檔的結構化或非結構化資料回答問題，請考慮使用專為解決此案例而設計的技術，而不是嘗試使用自然語言理解來解決問題。
在其他案例中，使用者可能會根據自然語言輸入簡單的要求。 例如，使用者可能會輸入「我想要胡椒披薩」或「距離我家現在開門 3 英里以內是否有素食餐廳？」。 自然語言理解 API 非常適合這類案例。
使用 API，您的 Bot 可以擷取使用者文字的主要元件，以識別使用者的意圖。 在 Bot 中實作自然語言理解功能時，請設定使用者可能在其輸入中提供的詳細資料層級的實際預期。
提示
建置自然語言模型時，請勿假設使用者會在初始查詢中提供所有必要的資訊。 請設計 Bot 以具體要求其所需的資訊，並視需要詢問一系列問題以引導使用者提供該資訊。
Speech
Bot 可以使用 語音 輸入和輸出來與使用者通訊。 如果 Bot 的設計目的是支援沒有鍵盤或監視器的裝置，語音是與使用者通訊的唯一方法。
在豐富的使用者控制項、文字和自然語言和語音之間進行選擇
就像人們使用手勢、語音和符號的組合彼此通訊一樣，Bot 可以使用豐富的使用者控制項、文字（有時包括自然語言）和語音的組合來與使用者通訊。 這些通訊方法可以一起使用;您不需要選擇彼此。
例如，假設「烹飪 Bot」可協助使用者使用食譜，其中 Bot 可能會透過播放影片或顯示一系列圖片來提供指示，以說明需要執行的動作。 有些使用者在組合配方時，可能會偏好翻頁食譜，或使用語音詢問 Bot 問題。 其他人可能偏好觸碰裝置的螢幕，而不是透過語音與 Bot 互動。 設計 Bot 時，請納入支援使用者可能偏好與 Bot 互動方式的 UX 元素，因為特定使用案例是要支援。