アプリ UI ではなく会話 UI
RBM エージェントは、会話型ユーザー インターフェースを使用して効率的で具体的なタスクをユーザーに提供する場合に適しています。最適な設計のエージェントは、自然な会話のようにインタラクションに焦点を当て、理解しやすく、構造化されています。
エージェントは、アプリやウェブページの視覚的な UI に依存しないでください。また、UI を模倣しないようにする必要があります。代わりに、エージェントは、口頭による手がかり、提案、適切なエラー処理でユーザーをガイドし、ユーザーのニーズを慎重に考慮して会話する必要があります。
また、エージェントは、特定のアクションを表す数字で応答するユーザーツリーまたはインターフェースを電話ツリーのように模倣しないでください。ユーザーは、会話で他の人とやり取りする場合と同様に、エージェントと自然にコミュニケーションができなければなりません。
会話型 UI の詳細については、会話型 UI とその重要性をご覧ください。
デバイスの機能を確認する
ユーザーとの会話を開始する前に、ユーザーのデバイスが RCS メッセージを受信できることを確認します。ケーパビリティ リクエストを送信してデバイスの機能を識別し、それに応じてエージェントの操作を調整します。デバイスに対応する方法でのみユーザーとやり取りする。ユーザーのデバイスが RCS に対応していない場合は、SMS などの別の技術と通信する代替方法を設定します。
会話を開始する
会話の始まりは、エージェントが実行できる操作に対するユーザーの期待値を設定するものです。つまり、エージェントの性格や、ユーザーが関心を寄せている情報をフロントライン ワーカーに伝え、エージェントの能力を共有していきましょう。ユーザーがエージェントとやり取りして会話を続行するための明確なオプションを提供する。
良いリズムを維持
会話でさまざまな種類の情報を使用することで、ユーザーのエンゲージメントとエージェントの関与が保たれますが、ユーザーに負担を与えないように注意してください。メッセージは、ユーザーが興味を引くわかりやすい長さに収め、メッセージ全体を画面に一度に表示します。画像とリッチカードは多くの画面スペースを占有するため、ユーザーがメッセージ全体を読むにはどれくらいのスクロールが必要かに注意してください。
メールを整理する
複数のメッセージを順番に送信する場合、ユーザーがそれらのメッセージを順番に受信することが重要です。メディアを含む一部のメッセージ（テキストのみのメッセージなど）は、他のメッセージよりも処理に時間がかかります。送信された順にユーザーがメッセージを受信できるようにするには、メッセージの 200 OK レスポンスを受信してから、次のメッセージを順番に送信します。
200 OK レスポンスは、RBM プラットフォームがメッセージを受信したことと、ユーザーがメッセージを正しい順序で受信する必要があることを確認したものです。200 OK レスポンスを待たずに別のメッセージを送信した場合、ユーザーは順不同でメッセージを受信します。
受信メッセージの重複を確認する
ユーザーからの受信メールを確認して返信するときは、messageId をチェックして、まだメッセージを受信して返信していないことを確認します。
分散システムの場合、メッセージを送信する方法は 2 つあります。多くても 1 回、少なくとも 1 回です。
- 「最大 1 回」のシステムでは、メッセージは 1 回送信されますが、途中でネットワーク エラーや通信エラーが発生した場合、メッセージは受信されません。
- 「少なくとも 1 回」のシステムでは、システムがメッセージを複数回送信することがありますが、ネットワーク エラーや通信エラーが発生した場合でもメッセージを受信できます。
Google Cloud Pub/Sub は「少なくとも 1 回」を使用します。これは受信メッセージの重複につながる可能性がありますが、messageId 文字列をトラッキングすることでメッセージの重複を除去するのは簡単です。すでにメッセージを受信している場合は、同じ messageId で受け取った他のメッセージを無視しても問題ありません。
明確で一貫性のあるメッセージを作成する
ユーザーの興味を引くわかりやすいメッセージを送信します。優れたメッセージ テキストはユーザーにレスポンスを促し、テキストのスタイル、書式、ペースの一貫性がユーザーとの信頼関係を築くことができます。
メッセージ テキストを作成する際は、次のおすすめの方法も念頭に置いてください。
- 行き止まりは作成しないでください。返信の候補はそれぞれ、ユーザーとの有意義な会話スレッドに誘導される必要があります。
- 必要に応じて、お客様の名前を「me」ではなく「you」とします。
- タイトルとラベルでは、語頭を大文字にせず、文頭のみを大文字にします。たとえば、「アカウント ステートメント」ではなく、「アカウント ステートメント」のように指定します。
- 文を短くするよう心がけてください。「It's」は「it is」よりも会話的。
- 感嘆符はできるだけ使用しないでください。
- シリアルカンマを使用してください。たとえば、「A、B、C」ではなく「A、B、C」とします。
- 数字を数字で入力します。例: 「one、two、three」ではなく「1、2、3」。
ユーザーがメッセージを望まない場合を尊重する
ユーザーがエージェントからのメッセージの受信を停止することを示した場合、その選択を尊重する必要があります。エージェントは、ユーザーが「STOP」と応答して適切に対応するタイミングを理解する必要があります。エージェントは、メッセージの受信を望まないユーザーに伝えるさまざまな方法を理解する必要があります。たとえば、ユーザーが希望の状況を伝えるために使用する可能性のあるあらゆる言語などです。
STOP などの必須コマンドへの対応方法については、お住まいの国の法律とおすすめの方法をご確認ください。たとえば、CTIA のベスト プラクティスをご覧ください。
お客様をサポートする
エージェントは、ユーザーからの HELP メッセージに応答し、エージェントの機能をユーザーに周知する必要があります。エージェントの機能に対応する返信候補のリストのような単純なものは、ユーザー エクスペリエンスの低下を有用なものに変えることができます。
指数バックオフによる再試行を実装する
API を呼び出すときに、インフラストラクチャの問題、サービスの過負荷、QPS の制限などのエラーが原因で呼び出しが失敗する可能性があります。失敗した API 呼び出しから適切に回復するには、指数バックオフを含む再試行を実装します。
指数バックオフで再試行を使用する場合、インフラストラクチャは自動的に次の処理を行います。
- 失敗した API 呼び出しを指定します。
- 初期待機時間と再試行の最大回数を設定します。
- 待機時間の間、一時停止します。
- API 呼び出しを再試行します。
API 呼び出しのレスポンスを評価します。
- 成功すると、ワークフローの次のステップに進みます。
- 失敗した場合は、待機時間を増やしてステップ 3 に戻ります。
- 最大再試行回数後に失敗すると、失敗状態になります。
理想的な待機時間と理想的な最大再試行回数は、ユースケースによって異なります。この値は、インフラストラクチャとワークフローのレイテンシ要件に基づいて決定します。
リッチカード
リッチカードを使用すると、1 つのメッセージでメディア、テキスト、候補を組み合わせることができます。そのため、リッチメディアの唯一の要素をメディアにしないでください。また、単体のリッチカードには常に、返信の候補やアクションの候補を表示する必要があります。
縦長のリッチカード
縦長のリッチメディアの場合は、カードの上部に横方向のメディアが表示されます。横向きのメディアのアスペクト比は 2:1、16:9、7:3 にする必要があります。
ユーザーにメディアを送信する際は、ユーザーのリソースを尊重する必要があります。 アスペクト比が 2:1 の横向きのメディアの最適な解像度は 1, 440x720 ピクセルです。推奨の最大ファイルサイズは、画像の場合は 2 MB、動画の場合は 10 MB です。メディアのサムネイルに最適な解像度は 770x335 ピクセルです。推奨ファイルサイズは 40 KB、最大サイズは 100 KB です。
横長のリッチカード
横長のリッチカードでは、カードの左側または右側に縦方向のメディアが表示されます。縦長のメディアのアスペクト比は 3:4 にしてください。
ユーザーにメディアを送信する際は、ユーザーのリソースを尊重する必要があります。 縦長のメディアのアスペクト比が 3:4 の場合、推奨されるメディアの最大サイズは 768x1024 ピクセルです。画像の最大サイズは 2 MB、動画の場合は 10 MB です。メディアのサムネイルに最適な解像度は 250x330 ピクセルです。推奨ファイルサイズは 40 KB、最大サイズは 100 KB です。
リッチカード カルーセル
リッチカード カルーセルは、コンテンツの閲覧やさまざまなオプションに最適ですが、データプランやデバイスなど、読み取りや比較の対象になる項目が複数ある場合にのみ使用してください。カルーセルの最初の項目は、どのような状況でも最適な選択肢であり、最適な選択肢である理由をユーザーに伝える必要があります。
カルーセルの下にある候補ワードは、会話を進めるか、方向転換する必要があります。候補ワードは、カルーセル内にリストされているオプションを繰り返さないでください。また、カルーセルに表示されるアイテムの選択ツールではありません。
リッチカード カルーセル内のメディア
リッチカード カルーセルは、リッチカードの上部に横向きのメディアを表示します。カルーセルの横向きメディアのアスペクト比は 4:3 にしてください。
ユーザーにメディアを送信する際は、ユーザーのリソースを尊重する必要があります。 メディアのアスペクト比が 4:3 の場合、メディアの最適な解像度は 960x720 ピクセルで、最大ファイルサイズは画像で 1 MB、動画で 5 MB です。メディアのサムネイルに最適な解像度は 605x452 ピクセルです。推奨ファイルサイズは 40 KB、最大サイズは 100 KB です。
返信の候補と操作
リッチカード内で返信の候補やアクションを提案する場合は、そのカード内のコンテンツに直接関連するようにします。
チップリスト内で提案される返信とアクションは、会話を進めるまたは方向転換する手段です。
返信文の候補
返信文の候補を使用すると、ユーザーが簡単にエージェントに応答できるようになります。自由形式のレスポンスが必要な場合を除き、返信の候補を使用してください。自由形式のテキストよりも処理が簡単で、エージェントが最適なパスに沿って会話を誘導できます。
推奨される措置
推奨アクションを使用すると、エージェントはネイティブ デバイスのアクションに接続し、緊密に統合されたエクスペリエンスを提供できます。関連するアクションにより、カスタマー サポートへの電話や地図上の場所の検索が簡単になります。
ただし、選択肢が多すぎてユーザーが混乱しないようにしましょう。最新のメッセージに関連するアクションのみを提供し、必要なアクションのみを提供します。アクションと提案する返信の件数は、そのコンテキストでユーザーにとって有用なもののみに制限されます。
デザインのまとめ
エージェントを作成する際には、会話、ユーザビリティ、効率性を考慮して設計することが重要です。エージェントは会話型 UI に重点を置き、返信とアクションの候補を採用した最適なワークフローにユーザーを誘導する必要があります。画像やリッチカードを使用する場合、エージェントは、ユーザーがコンテキストを簡単に維持でき、メッセージを簡単に読み取れるリズムを維持する必要があります。
ユーザー エクスペリエンスを考慮することで、エージェントの設計時に会話のデッドを避けることで、優れたユーザー エクスペリエンスを提供し、ユーザーが今後エージェントを引き続き使用する可能性を高めることができます。