このセクションで説明する準備手順については、会話デザイン体験(CDX)ワークショップに参加することを検討してください。CDXワークショップでは、プロジェクト・チームと目的のユーザー・グループの人々をまとめて、ユースケースとデジタル・アシスタントが人格、音声、言語および態度の観点からどのようにすべきかについて話し合います。

CDXワークショップは、デジタル・アシスタント・プロジェクトの次の基本的な側面に役立ちます。

• デジタル・アシスタントおよび対応するユース・ケースで解決する問題を識別します。
• ターゲット・オーディエンスを特定し、音声、トーン、教育および文化の背景でそのオーディエンスに適したボット・ペルソナを開発します。
• 既存のユーザー・ジャーニーを体験し、デジタル・アシスタントで改善できる場所と方法を特定します。
• ユーザーにリーチするための最適なチャネルを特定し、異なるチャネルの機能にも留意してください。
• ボットとユーザーの間のダイアログをモデル化します。
• 会話をサポートするために必要なデータがあるバックエンド・システムを識別します。

このようなワークショップは、自分で実行することも、Oracleの連絡先の助けを借りて実行することもできます。

デジタル・アシスタントは、Webアプリケーションやモバイル・アプリケーションを補完するものではありません。デジタル・アシスタントの構築を開始する前に、「なぜ?」と自問します。デジタル・アシスタントを構築する理由とそのメリットデジタル・アシスタントを構築すべきではないと言っているわけではありません。むしろ、ユース・ケースがあるデジタル・アシスタントをスイート・スポット内に構築していることを確認したいと考えています。

デジタル・アシスタントの特徴は、使いやすさにあります。アプリケーション・インタフェースとのユーザー・インタラクションに自然言語の会話を使用すること、およびユーザー・メッセージから情報を抽出する機能です。これにより、ユーザーに表示されるプロンプトの数が全体的に減少します。

数年前、モバイル・アプリケーション開発が学習すべき新しいスキルであったとき、Oracleユーザー・エクスペリエンス・チームは、モバイル・タスクにかかる時間を3分以下にすることをお薦めします。デジタル・アシスタントに対応する推奨はありません。しかし、私たちの経験に基づいて、おそらく60秒の近所では、それはそれよりはるかに低いはずです。

そのため、デジタル・アシスタントのユース・ケースを定義する際には、タスクの完了に必要なユーザー・インタラクションの量に注意してください。インタラクションが非常に長いことが判明した場合、ユース・ケースはデジタル・アシスタントに適していないか、構造化データ入力フォームを会話に組み込むなどしてインタラクションを短縮することを検討する必要があります。

一般的な推奨事項として、大きすぎたり複雑すぎたりしないユース・ケースを見つけます(さらに大きいユース・ケースを小さいユース・ケースに分類します)。特に、作成するデジタル・アシスタントが最初である場合、「単純」は複雑すぎる可能性があります。

達成したいことと同じように、目標を立てる必要があります。デジタル・アシスタントにとって、企業にも利益をもたらす現実的な目標を設定することが重要です。たとえば、Webアプリケーションを会話型チャネルに移動することは、Webアプリケーションを現実的なデジタル・アシスタントのユース・ケースに分類でき、デジタル・アシスタントがWebアプリケーションより適切に機能しないかぎり、よい目標ではない場合があります。ほとんどの場合、ユーザーと開発チームは、移動先のアプリケーションの機能と外観をコピーするだけで、プロジェクトを「...から...へ」に移動することは失敗します。

成功は計測されなければならない。たとえば、デジタル・アシスタントはセルフサービスを自動化するスマートな方法であるため、真のメリットを得ることができます。ただし、メリットがあるかどうかを適切に評価するには、各デジタル・アシスタントのユース・ケースで成功の意味と測定方法を定義する必要があります。条件の例を次に示します。

• 「図書館からの本の入学依頼の60%をデジタル・アシスタントが解決して、図書館員の作業負荷を軽減したいと考えています。」

• 「パスワードのリセットやアクセスや認可リクエストなどの現在のIT業務の70%は、デジタル・アシスタントが処理する必要があります。」

• 「新しい不動産を購入するためのすべての顧客からの問い合わせは、デジタル・アシスタントによって事前認定および転送されるため、不動産エージェントはオンサイト訪問数を30%増やすことができます。」

• "経費デジタル・アシスタントは、従業員による経費精算書の提出から会社による経費の払戻までの時間を3日に短縮する必要があります。"

会話のユースケースでは、ボットが処理する必要があるタスクを定義します。ただし、ドメイン内に妥当で関連するユース・ケースがあり、デジタル・アシスタントでは処理しないが、認識する必要がある場合があります。

会話は人間にとってネイティブなスキルであり、会話を進めるために特別なトレーニングは必要ありません。デジタル・アシスタントの場合、適切な会話の原則(そうでなければ当然と考えられる)を特定し、ボット会話設計に組み込む必要があります。会話型マインドセットを形作らない場合は、デジタル・アシスタントをコマンドラインまたはWebアプリケーションとして偽装して作成し、デジタル・アシスタントを非常に優れたものにする会話機能を使用しないリスクがあります。

では、どのように会話の考え方を変えるのでしょうか。次に、オプションをいくつか示します:

• デジタル・アシスタントの定義に役立つ会話デザイン・エクスペリエンス(CDX)ワークショップに参加してください。

  ワークショップで試してみる練習の1つは、2人が椅子に腰掛けることです。(逆に言うと、非言語的な手がかりを排除するため、デジタル・アシスタントの会話をシミュレートすることをお薦めします。)一方の個人はデジタル・アシスタントとして機能し、もう一方はユーザーとして機能します。ユースケースを提供し、会話がどのように発展し、どのように進行し、どこに停滞するかを確認します。会話が中断された場合は、会話を再開できる状態に2人がどのように解決するかを確認します。会話のメモを取り、粘着性のあるメモに置き、それらを壁に追加してグループと話し合います。

• パブやレストランに行って、一緒にいる人や友人を観察しましょう。Don't stalk them. Just watch them order food and drinks.彼らに食べ物や飲み物を注文するのを見なさい。

  • 食事の数をメニューに書いて食べ物を注文する人は何人ですか?メニューに書かれているように、食事の名前を言う人は何人ですか?食事の食材に言及して注文する人は何人ですか?前の人の命令を「私にも同じ」と言って参照する人は何人ですか?

  • バーテンダーまたはウェイターは、どのようにあなたの注文を確認または確認しますか? (それらがまったく行う場合)

  • バーテンダーやウェイターが騒々しい環境のために注文を理解しなかった場合、何をしますか?

  • バーテンダーやウェイターはもっと注文することを勧めますか?もしそうなら、彼はどうやってそれをするのですか。

  • バーテンダーまたはウェイターはあなたの注文をどのようにサポートしますか?

  • バーテンダーやウェイターは、食べ物や飲み物を楽しんでいるときにどのように行っているか尋ねますか?もしそうなら、なぜそう思うのでしょうか。

詳細に注意し、メモを取ることもできます。注意点や注意点は、会話スタイルと実践です。

レストランの従業員はレストラン自体を表し、通常、レストランが作る最初の印象です。レストランのスタッフが専門性が高いほど、顧客対応のトレーニングを受けている可能性が高くなります。彼らはやるべきことやしないこと、そして困難な顧客に対処する方法を学びました。心理学は飲食販売と顧客返品とどう関係があると思いますか?

デジタル・アシスタントとの類似点を見ると、会話設計が重要な理由がわかります。

デジタル・アシスタント・ペルソナは、会話デザイナおよびボット・メッセージ・ライターに、一貫したユーザー・ボット・エクスペリエンスを構築するためのより具体的で表現的なフレームワークを提供します。デジタル・アシスタントとユーザー間のエンゲージメントの作成では、「<DIGITAL_ASSISTANT_NAME>がこの状況をどのように処理するか」を尋ねる場合があります。

デジタルアシスタントは人間ではありませんが、人間の特徴を与えることができます。そのため、デジタル・アシスタントのペルソナを定義すると、アバターとブランドまたは会社を表す名前を作成するのみでなく、開発チームがユーザー・インタラクションやメッセージを設計する際に使用できる手すりとして機能するバックストーリーも作成されます。背景には、デジタルアシスタントが本当の人だったら知りたいかもしれないすべてのものを含める必要があります: 名前、年齢、訪問した学校、人が生まれた地域、現在住んでいる地域、趣味、婚姻区分、音楽、好きな食べ物や映画、彼女が持っているユーモア、彼女が話すアクセントなど。

世界中の様々な国のユーザーからアクセスするデジタル・アシスタントを設計する場合は、文化的および地域の違いを考慮する必要があります。デジタル・アシスタントは、どこからアクセスしても同じペルソナである必要がありますが、地域的および文化的な専門分野に適応することは大丈夫です。しかし、デジタル・アシスタントは、サービスを提供し、すべての人に喜ばれるように存在することに留意してください。

デジタル・アシスタントは自分自身を構築しません。これには、バックエンドの統合、システム管理、プログラミングなど、多様なスキル・セットが必要です。さらに、ボットに固有のロール(会話デザイナ、会話メッセージ・ライターおよびモデル・デザイナ)も必要です。後者の3つは必ずしもチームで常勤のポジションに代表される必要はありませんが、そのポジションに割り当てられるポジションは、その職務の専門家になる必要があります。

スキルを使用して、大規模なユースケースを多くの小さなユースケースに分割できます。スキルは、デジタル・アシスタント内の他のユーザーとともに構成された個々のデジタル・アシスタントです。次に、機械学習を使用して、デジタル・アシスタントは、ユーザー・メッセージの内容に基づいて、リクエストの転送先のスキルを決定します。

大規模なユース・ケースを複数のスキルに分割すると、デジタル・アシスタントの機能を段階的に増やし、開発を容易にし、懸念事項を明確に分離できます。

新しいものと同様に、デジタル・アシスタントの最初のリリースは最適なバージョンではありません。最初にクロールする方法を学び、次にどのように歩くか、そして最終的にどのように走るかを学ぶ必要がある奇妙な人たちのように、あなたは次のことをします。

• 設計で考慮しなかった状況を体験してください。

• 人間として認識されているが、デジタル・アシスタントが正しく表示されなかったことを示すメッセージがログに記録されています。

  簡単だと思っていた会話に苦労しているユーザーを確認します。

• 会話を放棄したユーザーに通知します。

成功を測定する方法が必要なため、デジタル・アシスタントを改善するための計画も必要です。このような計画には、デジタル・アシスタントをモニターする頻度、新機能とバグ修正の追加、新しいバージョンのリリースが含まれます。

Oracle Digital Assistantには、スキルおよびデジタル・アシスタントのパフォーマンス・インジケータをレポートする分析機能であるインサイトが含まれています。これにより、ボットがタスクにマップできなかった会話パスおよびメッセージの破損を検出できます。また、デジタル・アシスタントを使用すると、ユーザーがダウンタイムを経験することなく、新しいバージョンのデジタル・アシスタントを再デプロイできます。

また、失敗の苦味は、デジタル・アシスタントができることの過剰販売にも起因します。デジタル・アシスタント・プロジェクトを開始する際に、現実的な期待を管理できます。ボットは最終的に適切にパフォーマンスを発揮し、設定した成功目標を達成しますが、最初のバージョンには含まれません。

ボットの操作時のユーザーの注意率は無限ではありません。まもなく、ユーザーは、デジタル・アシスタントが他に何を実行できるか、またはどのようにそれを取り除くかをテストするというアイデアから追い出される可能性があります。したがって、ビジネス関連のファンクション設計以外に、デジタル・アシスタントを構築したビジネスの領域にない機能が必要です。

デジタル・アシスタントでは、小規模な講演に対処することが一般的な要件です。ユーザーは、ボットが人間かどうか、デートに出かけたいかどうか、天気はどうなっているか、共有する良い冗談を知っているかどうかなどを尋ねることができます。デジタル・アシスタントは、これらのクエリに完全に回答する必要はありませんが、最も一般的なクエリを処理できる必要があります。

たとえば、天気を求められたら、花を販売するデジタル・アシスタントは次のように答えることができます。「データ・センターに窓はありませんが、花を注文するのに十分な天気だと言われています。だから、あなたの花の注文を手伝ってあげましょう。"だから、小さな話のおかげで、デジタルアシスタントはリクエストを理解し、ユーザーがボットの目的を思い出させるようにそれに対処します。スモール・トークは、うまく処理すれば、ユーザーとボットにとって有益な状況です。

• ☑ 軸を削るのに十分な時間を費やしましたか?
• ☑ 利害関係者やプロジェクト・チーム・メンバーと一緒にCDXワークショップを実行します。
• ☑ デジタル・アシスタントのスイート・スポット内にあるユースケースを特定します。
• ☑ デジタル・アシスタントのドメイン内にあるが範囲外のユースケースを特定します。
• ☑ デジタル・アシスタントの成功の意味と、ユースケースに応じた測定方法を定義します。
• ☑ 大きなユースケースを小さなユースケースに分割します。
• ☑ユース・ケースごとに、持つ会話を識別します。
• ☑ 成功の目標と尺度を定義します。会話の成功をどのように測定しますか?会話におけるビジネス価値はどこにありますか?
• ☑ 会話デザイナ、NLPトレーナー、製品管理、Oracle Digital Assistant開発者、バックエンド統合開発者など、チームに適切なスキルがあるかどうかを確認します。
• ☑ ボット・ペルソナを定義します。
• ☑ ボットの背景を記述します。
• ☑ トークやよくある質問の処理方法を検討します。
• ☑ 障害に対処するための計画を準備します。

• Oracle TechExchangeの記事: デジタル・アシスタントを複数のスキルに分割する方法の決定
• チュートリアル: Oracle Digital Assistant Insightsの使用