Design in Action "Design Principles and Methodology"を日本語訳しました
注: この日本語訳は、翻訳時点での内容が反映されています。そのため、既に古い記載内容となっている可能性があります。必ず最新の情報を Actions on Google Document で確認してください。
Actions on Googleを使ってGoogleアシスタントにアプリを提供する際の会話型UI設計について、The Conversational UI and Why It MattersとHow Conversations Workによって、会話型UIがどういうものなのかが説明されています。しかし、概要なので、それらだけ読んでもなかなかイメージを持つことは難しいかもしれません。ドキュメントでは、更に具体的にアプリを設計するための説明が続きます。
ここでは、Design in Action - Design Principles and Methodologyの日本語訳を紹介しましょう。より具体的にアプリの設計指針が書かれています。特に、「会話型UIでやって良いこと、やっちゃいけないこと」がまとめられています。
設計原則と方法論
私たちの推奨する設計プロセスは、会話のアクションを構築する際の確固たる開発者リファレンスとして、ユースケースを考え、自然に聞こえることを確実にするための簡単な方法を提供します。
主な手順は次のとおりです。
- 正しいユースケースを選ぶ
- ペルソナを作成する
- ダイアログ（対話）を書く
- それを試す
- ビルドと反復
会話のために最適化する: 適切なユースケースを選ぶ
伝統的なUIを超えた対話型インターフェイスを使用することを決定する際、ユーザーは意識的なトレードオフを行います。しばしば彼らは出かけていて、情報のためにウェブサイトを閲覧する時間がなく、他の何かに注目しなければならない、または彼らの手は塞がっています。
既存のモバイルアプリやデスクトップアプリを「会話に変換する」ことに誘惑されないでください。会話はスピードとシンプルさをもたらしますが、他のやり取りの様式に基づいた際には簡単に過度に複雑となります。
どのようなタイプのユースケースが会話のやり取りにうまく移行するか、に関するいくつかのガイドラインがあります。
- 人々が思いつきで答えることができること。 基本的なユーザー情報、場所、時間、日付など、使い慣れた入力を求めるアクションです。ユーザーが知っている情報は、尋ねられたときに簡単に思いつくことができ、記憶しやすいので、今後の利用のためにアクション内で費やされる時間を最小限に抑えることができます。
- 迅速、しかし説得力のある有益なアクション。 これらは、通常、ユーザに費やされる時間がほとんどない場合に多くの利益をもたらします。たとえば、数秒で食べ物を注文して30分後に出てきたり、乗車を求めてタクシーが数分であなたの戸口に来たり、ということです。その他の便利なアクションには、答えを探したり、速やかに計算したり、情報の記録や追跡、携帯電話を取り出したり紙切れを探すといった、他の動作が一時中断しないようにする何かが含まれます。
- 本質的に声によく適したアクション。 これらは、通常、料理中にレシピを聞くことや、運転中に覚えておくことなど、ハンズフリーでやりたいことです。これらのタイプのユースケースは、実際に手で操作するやり取りを必要とする画面を備えたデバイスにも非常によく結びつきます。これは、画面とのやりとりには、UIが迅速かつハンズフリーな操作に特化している場合に、実行が容易になるタップやジェスチャーが必要になるためです。
これらのものを最適化する
スピード、シンプルさ、ハンズフリーのやり取り。良い会話のデザインのいくつかの簡単な原則については、以下の原則を参照してください。
ペルソナを作成する
会話型インターフェイスを設計する前に、会話をどのように感じ、奏でたいかを考えてください。あなたが楽しいゲームを作っているなら、風変わりな音色を使いたいかもしれません。ニュースリーダーを作成している場合は、より慎重で生真面目なトーンを使用することを使いたいかも知れません。
人格の認識
人々は、人間の性格と同じように、「仲介」キャラクタ（バーチャル・アシスタントなど）に対して、同様の社会心理的な反応を示します。たとえ数秒の長さであっても、私たちは本能的に人間の特徴や性格を（話しているか、視覚的なテキストかを問わず）デジタル音声に適用します。すべての声にはオーナーがあって、私たちは自然にスピーカーの精神的なイメージや複合物を形成します。実際の人格を多かれ少なかれ協力的なものとして評価するのと同じように、つまりその特質が意図的に設計されているかどうかに関わらず、私たちは設計された人格を評価します。
多くの人々は、会話体験のレベルを共有しようと思わないデバイスとやりとりすることを、愚かで厄介だと考えます。そして、人間の言語の親密で個人的な性質のために、私たちは一般に、他の会話のやり方よりも明らかな利点を提供しない会話型UIを使用しないでしょう。 UI設計は、アシスタント（または会話内で作られた役割を果たす他のキャラクター）の人間としての精神的モデルに合わせて調整されるべきです。ユーザーの研究は、そのモデルの理解につながります。だから、私たちは人々のために設計し、デバイスに従わせる必要があります。
ペルソナは会話をデザインし記載するのを手伝ってくれるので、正しい単語、構文、そして構造を簡単に選ぶことができるように、早い段階で選択してください。覚えておいてください。あなたがペルソナを計画したかどうかに関わらずにユーザはペルソナを認識するので、偶然になるのではなく、それはあなたが理解させたい体験を構築するためのブランドの最大の関心事になります。
声を選択する
アシスタントは、特定の言語とロケールに対応する、ペルソナにマッチさせるのに役立つさまざまな声を提供します。使用できるボイスの種類の詳細については、Languages and Localesを参照してください。
ダイアログ（対話）を書く
今、いくつかのユースケースを選択し、そしてペルソナを決定しました。あなたは開発に飛びつきたくなっているかもしれませんが、その衝動は抑えてください！
代わりに、鉛筆と紙、またはあなたが素早く書ける何かを使って、会話を書くことから始めます。
始めるには、ユーザーが可能性として通過可能な複数および個別のダイアログを書き留めます。あなたが書くことを検討しなければならない、ダイアログのいくつかのタイプがあります。
- それほど複雑ではなく、最も簡単な方法でアクションを達成すると考えられる、ユーザーのための「ハッピー・パス」。
- ユーザーが「ハッピー・パス」と同じ結末になるために必要な追加パス。これは、一部のユーザーが一度に1つずつの情報を与えて、その他が一度にそれを話すようなバリエーションの可能性があります。
- ユーザーが予期せぬことを行った場合のConversation repair（会話の修復）シナリオ。たとえば、サポートしていないことや、理解できないことを実行するよう求めている、などです。
- ユーザーが会話の途中で終了する、またはユーザが望むことを行った際に終了するダイアログ。会話の終わりを確認する方法を考えてください。
- ユーザーの出迎えと、アクションが呼び出される方法。ユーザーがアクションを呼び出す方法と、いろいろなやり方で開始するダイアログを書く方法の詳細については、Invocation and Discoveryを参照してください。
- ダイアログがどのように奏でられるかの良いアイディアを持った後は、画面を持つデバイスにダイアログを表示する方法を考えてください。Actions on Googleは、音や視覚的なUI部品を利用可能な携帯電話などのデバイス向けの体験に対応できる様々な画面のアフォーダンスを提供します。具体的には、画像の利用のために、画面に表示されるものとは異なる何かをTTSに返事をさせると良いでしょう。会話にてそれが必要なときは、画面を持つデバイス向けに、完全に異なるダイアログを作成した方が良いかも知れません。この機能は、最近の商品の迅速な再注文や、オーディオやスクリーン出力のあるデバイスでの完全なショッピングカートの体験など、オーディオ専用デバイスの簡素化された体験が必要な時に役立ちます。
会話型言語を使用する
最良の意図であっても、会話を英語で書き、そして英語で話さずに設計する傾向があります。たとえば、文章を書くときにフレーズを縮めることをしばしば忘れることや、紙に書かれた何かを参照するときに、私たちは「this」を使用することがよくありますが、話したときには「that」を使用します（そして、結局は、”Is that right?”の代わりに、”Is this correct?”のようなフレーズを使うことになる）。これに気をつけて（！）、会話が自然に聞こえるようにし、そしてあなたが選んだペルソナを反映させるように、会話を大きな声で話してみてください。
テストする
アプリをテストすることは、あなたが考えているよりも実は簡単です。必要なのは、開発に関与していない人だけです。何をすべきかのヒントや手がかりなしに、彼らにアプリを使用させてください。このプロセスを数回実行すると、どの会話パスに到達するのが難しいのか、またはユーザーのやり取りに関して、レスポンスがどのように聞こえるかについて、洞察を得るはずです。
その後、個人的なフィードバックを得ましょう。彼らは、どこで立ち往生しましたか？「オフ」と感じたのは何ですか？この情報は、幅広いユーザー層から得るであろう情報から比べると小さなものですが、アプリを公開する前に入手しておきます。
設計のための原則
短く保つ
ユーザーの時間を尊重します。ポイントに到達したら、道から出ます。
彼らに信用を与える
人々は言語を知っていて、話す方法を知っています。どのように話すか、そして言うべきことをユーザに教えることを避け、ダイアログを進める自然な方法にフォーカスしてください。
関連性を最適化する
ユーザーの現在のニーズやユーザーがおかれているであろう環境に、文脈的に適切で敏感にします。
心を邪魔することなく耳を喜ばせる
個性を追加するときは、ユーザーの作業を妨害するほど大げさなものではないことを確認してください。
初心者の参加とエキスパートの誘致
Designing for many people doesn’t mean designing for the lowest common denominator. 多くの人のために設計することは、最小公約数の設計を意味するものではありません。
交代する
ターンを早まって取り戻さないでください。ユーザーに質問をする場合（あなたのターンを明け渡す）、彼らが答える権利の邪魔になるような追加の命令を投げ込まないでください。
心を読まない
彼らに事実を与え、決定させましょう。
UIで行うこと、行わないこと
行うこと
- 基本的な会話のルールと毎日の音声パターン（挨拶を含む）に従う。
- Grice’ Maximの原則を適用する。
- さまざまな発声スタイルに対応する。
- 人々が（教えることなく）何ができるかの直感的な例を提案する。
- システムが聞いていることを示すために、肯定応答を使用する。
- UIサウンドをより自然にするために、肯定応答をランダムにする。
- 重要な要求を明確にするために明示的な確認を使用し、要求を実行する危険性が低い場合は暗黙的に確認する。
- より意味のある（そして自然な）相互作用の機会として「エラー」を使用する。
行わないこと
- ユーザーに質問を訪ね、その後話し続ける。
- タッチトーンアプリと電話ツリースクリプトでのモデルレスポンス。
- 何を言うべきかを人々に教えようとする。
- 分かりきったことを言う
- ユーザーに話しかける、または機械的に聞こえるレスポンスを提供する。
Creative Commons Attribution 3.0 License 原文
← Actions on Google開発者向けドキュメント 日本語訳インデックス
