VUI設計 その1

声でコンピュータとやりとりするVoice User Interface(VUI)。スマートスピーカー向け音声アプリケーションのデザインでは、画面遷移やビジュアル要素ではなく、アプリケーションとユーザーの「会話」を設計することになります。

今回の記事では、まずVUIの特徴や各音声プラットフォーム(音声PF)の推奨するルールを押さえ、そのあとに音声アプリケーションのVUI設計手順を説明します。なお、Voice User Interfaceについてより詳しく勉強するなら「デザイニング・ボイスユーザーインターフェース」(Cathy Pearl著)がおすすめです。

VUIの特徴とルール

VUIの特徴

VUIには次のような特徴があります。VUI設計時には、これらのメリットが生かされるようデザインしましょう。

• 直感的に使える
  パソコンやスマートフォンといった新しい道具を使い始めるときに私たちは、検索キーワードを入力して「検索」ボタンを押したり、目的のアプリを一覧から探し出してタップしたり、道具側の作法を覚える必要がありました。しかしVUIは、私たちがすでに人間同士で使っている「会話」の作法に沿っているため、使い方を覚える必要がありません。誰でもすぐに、直感的に使えます。

• ハンズフリー・アイズフリー
  タッチ入力やGUI(画面インターフェース)では手と目を使うのに対して、VUIでは口と耳を使います。そのため、料理中や運転中など手や目が離せない場面にVUIは相性がよく、別の作業(ながら仕事)を平行して行えます。

• 素早く済ませられる
  タイマーセットや天気情報の確認などシンプルな命令であれば、キーボードやマウスを使うよりも短時間で結果を得られます。

VUIのルール - 音声PFのデザインガイドラインから

第1回で説明した「機械と人間が会話する仕組み」のうち、音声認識・(前段の)意図判定・音声合成は音声PFが担っており、音声認識のインタラクションや統合エージェントとしてのデザインを含めた広範囲なVUIデザインはすでに音声PF側で設計されています。

サードパーティ音声アプリケーションでよいVUI体験を届けるには、音声PFから提供されているデザインガイドラインに沿うことが近道です。ガイドラインは音声PF上で開発・公開するためのルールというだけではなく、よいVUI体験を届けるための実践的なアドバイスにもなっています。

各ガイドラインでは共通して、プロンプト(音声アプリケーション側が話すセリフ)は簡潔で自然な話し言葉にする、ユーザーが話しやすくなるように工夫する(答えを求めるときは疑問形にする、言い方の例を示すなど)、ユーザーの状況に応じて答えを出し分ける、エラーを避ける(ユーザーがどんなことをどのように言っても答えられるよう準備する)ことが推奨されています。人間の会話形式に則ることが要点となっていることがわかります。

音声アプリケーションVUI設計のステップ

ユーザーに使ってもらえそうなアイデアがまとまり、VUIの特徴・ルールを把握したところで、VUI設計に入りましょう。なお、この手順ではスマートスピーカー向け音声アプリケーションの、カスタムスキル/カスタムアクションのVUI設計をするものとして説明します。

音声アプリケーションのVUI設計は、おおよそ以下のステップで進めます。

1. アプリケーション呼び出し名を決める

2. ハッピーパスを書く

3. 設計方針を決める

4. フローチャートにまとめる

ステップ1. アプリケーション呼び出し名を決める

アプリケーション呼び出し名(スキル名、アクション名)はとても重要です。なぜなら、音声アプリケーションを使ってもらうには基本的には呼び出し名を覚えて口にしてもらう必要がありますが、ユーザーにとってそれは簡単ではないからです。

スマートフォンアプリの場合なら一度インストールすればホーム画面やランチャーを開いたときにアイコンが目に入りますが、音声アプリケーションの場合、スマートスピーカーの前に立っても、サードパーティ音声アプリケーションを想起する手がかりはほぼありません(使えるアプリケーション名を全部読み上げてくれるなんてことはないからです)。また、もし思い出したとしても、ウェイクアップワードのあとにさらにアプリケーション呼び出し名を言わないといけないのは、とても面倒です。

できる限りそのハードルを下げるために、アプリケーション呼び出し名は提供機能と関連性があり、口にしやすく、より使われそうな言葉を選びます。決定する前には必ず何人かに実際に喋ってもらい、検証しましょう。各音声PFガイドラインでの要件も事前に確認してださい。

ステップ2. ハッピーパスを書く

ユーザーと音声アプリケーションの理想的な会話(「ハッピーパス」と呼びます)を、台本のような形式で書き出します。利用状況を変えて複数考えてみましょう。 例えば、運行情報を教えてくれる音声アプリケーション「Yahoo!路線」の場合、次の2種類のハッピーパスが考えられます。

(1)特定路線の運行情報を尋ねる

(2)いつも使う路線に遅延がないかを確かめる(アカウントリンク済みでYahoo!路線に登録路線がある場合)

ステップ3. 設計方針を決める

フローチャートの分岐が多くなりそうな場合は、細かな文言やパターン出しをする前に、以下のような項目に対して事前に方針を決めておけると手間が省けると思います。

• 会話継続への力の入れ方
  ユーザーからの質問に答えたあと、さらに次の会話を促してやりとり(ターン数)を増やすかどうか。提供する音声アプリケーションのドメインが「コミュニケーション」型であれば、何度も話しかけやすいVUI設計を目指し、結果としてターン数が増えれば成功と言えるでしょう。一方「タスク遂行」型のドメインでは、不要なやりとりやエラーをできるだけ避け、ユーザーが求める答えに素早くたどり着くことを目指すため、ターン数は少ない方がいいのかもしれません。

• どの程度出し分けをするか
  利用レベル(初めての利用/2回目以降の利用など)やユーザー情報へのアクセス設定状況によって伝える内容を変えた方がVUI体験としては望ましいですが、あまりに分岐が複雑になると管理しづらくなるという面もあります。

• プロンプトのトーン
  プロンプト(音声アプリケーション側のセリフ)の口調はどの程度のフォーマル度またはカジュアル度でいくか。例えば終了時の挨拶は「ご利用いただきありがとうございました」「使ってくれてありがとう」「じゃーまたね」、どのあたりでしょうか。どの程度キャラクター(音声アプリケーションの「ペルソナ」と言ったりもします)を作り込むか・作り込まないか、音声合成の声選びなども関連します。

ステップ4. フローチャートにまとめる

ハッピーパスを幹としたら、枝葉にあたるほかの経路を洗い出し、条件分岐とシステムからの応答内容をフローチャートにまとめます。その際は、想定しない発話が来た場合(例えば「カレーの運行情報を教えて」と言われたら？)、問いかけに対してユーザーが沈黙した場合、出し分け条件の網羅(ハッピーパスの例2では登録路線を答えていましたが、登録路線がなかったら？)、「ヘルプ」や「終了」など共通コマンドの対応などのパターンを含めましょう。

VUIフローチャートについては次回、具体的な事例を元に改めて解説したいと思います。

プロトタイプで気軽に検証

上の4ステップのどこでも使えて、VUI設計の品質を上げるためにとても有効なのが、考えたVUI案を誰かに使ってみてもらい、検証することです。

VUIの場合はとても簡素な検証、例えば文字で書いたハッピーパスを誰かと読み合わせしたりするだけでも、気づきを得られると思います。なぜなら、目で見ると理解しやすい文章が、耳から聞いて理解しやすいとは限らないからです。また、同じ答えを求めていても質問の仕方は人によって様々です。エラーに強いデザインにするには、いろんな人に使ってみてもらうことが必要です(リリース後であればもちろんログも活用できます)。

そして、VUIの検証はお手軽です。人がスマートスピーカーになりすましてセリフを喋れば(「オズの魔法使い」手法と呼びます)プロトタイプ代わりになりますし、その言語を話す人であれば誰にでもテストをお願いできます。

• 音声アプリケーションのアイデア出しのあと、オズの魔法使い手法でアイデアを検証している様子。スマートスピーカー役はポテトチップスの筒を持っています

まとめ

今回はVUI設計その1として、音声アプリケーションのVUI設計手順までを解説しました。次回は実際のフローチャートを元に、VUI設計の実例をご紹介する予定です。