Conversation Design Memo
はじめに
Conversation Design をベースに意識するポイントをメモ。
(2019.07.時点でまとめたもの)
Conversation Design / 会話デザインとは
会話デザインは、人間の会話に基づいたデザイン言語。
インターフェイスが人間の会話を活用するほど、使用方法を教える必要があるユーザーが少なくなる。
それは
- 音声ユーザーインターフェースデザイン
- インタラクションデザイン
- ビジュアルデザイン
- モーションデザイン
- オーディオデザイン
- UXライティング
- 洗練された会話デザイン
を含む、いくつかのデザイン分野の統合である。
(Google Assistantのアクションを作成するには幅広いデザイン知識が必要)
会話デザイナーの役割は建築家の役割と同じ。ユーザーのニーズと技術的な制約の両方を考慮しながら、スペース内でユーザーができることをマッピングする。
既に実用的なグラフィカルユーザーインターフェース(GUI)がある場合は、音声入力と音声合成(TTS)出力を単純に追加し、それを「会話デザイン」に変えることをお勧めする。
「会話」は話されている、または聞かれていることだけを指していると仮定するのはよくある誤解。会話は本質的にマルチモーダルである。
基本的に、会話デザインは会話の流れとその基礎となるロジックについてである。
したがって、会話型になるようにインターフェースを再設計するときには、ボトムアップから始める必要がある。
グラフィカルインタフェースに機能するロジックが、会話型インタフェースにそのまま機能することはほとんどない。
会話は後付けであってはいけない。代わりに、それは可能なこととユーザーがそこにたどり着く方法のロードマップである。
How to Design Better Apps for the Google Assistant
より良いアプリをデザインするヒント
上記動画のまとめ
1. ペルソナを作成すること
ペルソナはユーザー数、ニーズとアプリのブランドに関連するイメージと品質に基づくことが必要。
それは音声と会話経験によって捉えられた構成人格。
ユーザーにとって体験の顔、ユーザーが話している相手。
ペルソナは声のトーン、単語や語句の選択、スタイル、テクニック、声を通して伝わる。
2. 文字通り型にはまらずに考えること
脚本を書くような中心的経験を書くべき。
それを同僚と一緒に演じて、紙に書いたり、OZの試作品の会話型ウィザードを作成したりすると断片的になるかもしれない。
コーディング開始の準備が整うまでは微調整してテストしていく。
最初のバージョンをスケッチするときはハイレベルを保ち、ボックスはユーザーのインテントのダイアログ全体を表す。
各会話で使用したい個々の文言は除外しておく。
3. 会話ではエラーがないことに留意すること
問題が発生時にアクションが言うことを想像するとユーザーには「わかりませんでした」と聞こえる。
これはユーザーが音声インターフェイスに不満を持ち嫌う主な原因の1つ。
同じ答えを繰り返すと、人々は怒って声を張り上げる。
私たちは話し方を知っている人々を称賛する必要がある。
彼らがコマンドや選択肢を理解しないからと言って、言語を話さないわけではない。
なので、彼らがうまくいくように手伝う。
例えば、「AかBのトピックを聞きたいか」と尋ねて彼らがAかBを答えるのを期待するのではなく「AとBのトピックのどちらが好きですか」と精密に質問する。
最初の質問は両方とも「Yes/No」か「And/Or」になる。
途中で起こったことに留意する。文脈を守る。
まだ自然で快適な会話を事前に正しい流れにする最善の方法はこれらの会話がまるで通常の会話の流れのように計画すること。言い換えれば、それらをエラーを起こさなかった入力として扱う。
デザインプロセス
会話デザインは俊敏でウォータフォールの少ない設計にして、反復とテストを何度も行う必要がある。
1. Requirements / 必要条件
2. High-Level Design / ハイレベルデザイン
3. Detailed Design / 詳細デザイン
というフェーズで進めていく
Requirements / 必要条件
ユーザーを特定
- ユーザーは誰か？
- 彼らは何がしたいか？
- 普段どのような会話をしているか？
- 環境は？
技術的制約を特定
システムとデータの制約を知る
適切なユースケースを特定
- 最も影響を与えることに注力する。
- 一番ユーザーに影響を与えるシナリオを考える。
非常にわかりやすいユースケースや市場的な差別的要因など。
- ユーザーが何を求めているかの調査をもとにアクションを考える。
従来の UI ではなく会話インターフェースを使用するときに、ユーザーは意識的なトレードオフを選択している。
多くの場合、玄関を飛び出てウェブサイトで情報を確認する時間もない、別のものを見続けていなければならない、手が塞がっている、という状態にある。
既存のアプリを会話型に変換しようとしないこと。
会話はスピードとシンプルさをもたらすが、別のモードの対話をベースにすると複雑すぎるものになることがある。
自分の声を決める
ブランドと指名に表すペルソナを作る。
用意されたテンプレに当てはまらないならHigh Level Designに進む。
ユースケースレビューチェックリスト
1.
- このタスクまたはトピックについて、ユーザーはすでに人と人との会話をしている。
- 対話は短く、前後の対話は最小限。
利点・会話が直感的である。
ユーザーは欲しいと思っているものをそのまま「欲しい」と言わせることができる。
2.
- 画面でタスクを完了するために複数回タップする必要がある。
- 画面でタスクを完了するために複数アプリまたはウィジェットを操作しなければならない場合がある。
- この機能を見つけるのが難しいか面倒。
利点・会話が画面ベースのUIよりも時間と労力を節約。
会話は究極の近道になり得ます。ユーザーが欲しいものをすばやく取得することで摩擦を減らす。
3.
- マルチタスク中にこのタスクを実行できる。
- 自分の手や目が忙しいときにこのタスクを実行できる。
利点・会話により、ユーザーはマルチタスクを実行できる。
彼らが忙しいとき、特に彼らの手や目が占有されているとき、あるいは彼らが移動しているときに役立つ。
4.
- このトピックについて話したり入力したりするのが快適。
利点・会話により、ユーザーは自由に話すことができる。
会話はプライベートスペースまたはよく知られている共有スペースで行うのが一番。書かれた会話は個人用デバイスに最適。High-Level Design / ハイレベルデザイン
High-Level Design / ハイレベルデザイン
ここでは以下の作成を行う。
1. Sample Dialogs / サンプルダイアログ
2. diagramming high-level flows / 図式化
最初に会話に焦点を当てるのは、画面を念頭に置いて設計を始めると、会話のスレッドを見失って会話に適さないグラフィカルインターフェースになることがあるため。
Sample Dialogs / サンプルダイアログ
以下のステップで会話を作る。
1. 1ユーザーペルソナと1つの主要なユースケースに焦点を当てる。
2. パートナーを見つけて会話をロールプレイする。
1人が自分をユーザー、他人をシステムペルソナのふりをする。会話を録音する。
パートナーがいない場合は、両方の役割を果たすことを切り替える必要がある。
3. 会話を書き起こす。これがサンプルダイアログの最初のドラフト。
4. 読み上げ&再生。ダイアログをステップスルーして、ユーザーの行を読み上げ、システムペルソナの各行をテキスト読み上げ(TTS)で再生する。
TTSが不自然に聞こえる場合は、それを書き直すか、音声合成マークアップ言語(SSML)を使用してパフォーマンスを変更する。
5. 様々なユーザーのペルソナと主な使用例について、手順1〜4を繰り返す。
diagramming high-level flows / 図式化
サンプルダイアログをいくつか作成したら、会話の流れとロジックを抽象化できる。これは会話型インターフェースの構造を提供する。
Google Drawings などのフローチャートツールを使用してより正式なものを作成する前に、ホワイトボードまたは紙に高レベルのフローをスケッチすることから始めることを勧める。
Detailed Design / 詳細デザイン
ハイレベルデザインが終わったら、詳細デザインに入る。
Conversational components / 会話コンポーネント作成
会話コンポーネントは、音声プロンプト、ディスプレイプロンプト、およびチップス内のコンテンツで構成。全てのダイアログの順番に合わせて設計する必要がある。
使用するデバイスによっても、応答の仕方や画面の表示が変わってくる。
- スマートスピーカー、ヘッドフォンでの音声のみでの操作。
- 車内のカーナビ、スマートディプレイでの常にユーザーが画面を見ていない場合の操作。
音声プロンプトは会話の大部分を伝達し、コアメッセージのみを伝える必要がある。画面は路側的な視覚的情報ならびに会話を継続するかどうかのチップス提案をする。
- テレビ、ノートパソコン、電話、スマートウォッチでの会話は、音声および画面ベースの対話も同様に適している。
ユーザーは話している内容を音声かビジュアルで続けて操作を選択することができる。そのため、全てのコンポーネントを協調して会話を進め、コアメッセージを伝えることができる。
種類
1. User Input / ユーザー入力
ユーザーの音声入力またはディスプレイからの入力
2. Spoken prompt / 音声プロンプト
TTSまたは録音済みのオーディオを介して、ユーザーに話すコンテンツ
3. Display prompt / 表示プロンプト
画面に表示された内容を介して、ユーザーがアクションできるもの
4. Chips / チップス
ユーザーが会話を継続または会話を中心にできる方法の提案
プロンプト間の関係
- 基本的に音声とビジュアルで同じことを言う。
(↓同じことを言うが音声とビジュアルで全く同じテキストを出すわけではない)
- 表示プロンプトは対応する話し言葉の要約版にする必要がある。
- 声とトーンを一定に保つ。
- 独立して理解できるように音声でデザインしてプロンプトを表示する。
スタイルガイド
- 1ターンで640文字までだが、300文字以下にすることを推奨。
- 表示プロンプトを1〜2つに分けて表示。視覚的に読みやすさを重視する。
- ユーザーに焦点を当てる。
- 独自に立ち上げない。応答を簡潔に。大げさな詳細は入れない。
- 短くて簡単な言葉を使う。
- 専門用語や法律用語を避ける。一般的な用語を使う。
- 必要に応じてプロンプトをランダム化する。人がするのと同じように様々な応答を作成する。これは会話をより自然に感じさせ、経験に新鮮さを欠くのを防ぐ。
- ユーザーに何かしてもらいたい時は、まず理由を挙げる。
例「あなたがほしいものを手に入れるために、これをしてください」
- 悪意を避ける。会話を親しみやすく、同じトーンを使用する。
- 収縮を使用する。”cannot”, “do not” ではなく “can’t”, “don’t”
- UI固有の指示を与えない。「タップ」「スクロール」「スワイプ」「ドラッグ」などのUI固有の説明はインタラクションデザインが進化すると古くなる可能性がある。
- 大文字・小文字を区別して使用する。大文字は先頭の単語のみにする。
- 3つ以上の項目のリストはコンマを使用する。
- 感嘆符は叫び声として認識される可能性があるので避ける。「 ! 」NG
- テキストの代わりに数字を使用する。数字は視覚的コンテンツをより一目瞭然にする。
- テキストの代わりに特殊な記号を使用する。シンボルは視覚的な内容を一目瞭然にする。「thirty-five dollars.」>「$35」
- 時間は「AM」「PM」の形式を使用する。
Building blocks・ビルディングブロック
Actionを効率的に設計および構築するためのパターン
1. ユーザーエンゲージメントの維持
- 通知
- 毎日の更新
- 日常的な提案
2. ユーザーの行動を促進
- 明示的な呼出
-- Ok Google. Talk to name.
-- Ok Google. Speak to name.
-- Ok Google. I want to speak name.
-- Ok Google. Ask name.
- 呼出フレーズ
-- Ok Google. nameに〇〇について話す
-- Ok Google. nameに〇〇のために話したい
-- Ok Google. nameにいつ〇〇があるのか尋ねたい/確認したい
- 暗黙の呼出と組み込みの目的
-- 特定の有用なタスクを実行するアクションを設計した場合、未使用ユーザーにそのアクションを推奨することがある。
-- 組み込みの意図とは、ゲームプレイや注文など、特定のカテゴリのユーザー要求を満たすのに適したアクション。
現在サポートしている組み込みのアクションリスト
- アクションリンク
-- ユーザーのアクションによってインターネットへのリンクを許可する
平易な言葉を使い、リンク先を明確にする
3. 尋ねることがある一般的な質問
- ヘルパー
アシスタントに会話を引き継いで、よくある質問をするように伝える。ヘルパーを要求するとき、標準的なUIを提示するので、独自のものを設計する必要はない。技術的な情報はこちら
- ヘルパーの種類
-- ユーザー情報 : 表示名, 姓名, 郵便番号, 都市, 正確なデバイスの位置(座標と住所)
-- リスト・カルーセルのオプション
-- 日時 : 日付, 時間
-- アカウントサインイン : 関連付けしているアカウントにサインインしてもらう
-- 場所と位置 : 住所, その他場所(Googleで保存した自宅, 職場, 連絡先など)
-- 確認 : はい/いいえ など
4. 購入処理
トランザクションで購入処理するアクションを作成できる
- 商品
-- 1. 物資 : 衣料品, 生活雑貨, 食品などの有形物
-- 2. デジタル製品 : アプリ購入, メディア, ソフトウェアなど
- 支払い方法
-- 1. Google管理の支払い
-- 2. マーチャント管理の支払い
-- 3. デジタル取引
5. 通知
- 毎日の更新 : ユーザーが指定した時間に通知
- プッシュ通知 : 適切と判断された場合に通知
6. アカウント連携
アカウントリンク
(Googleログイン, OAuth&Googleログイン, OAuthの3種がある)
Conversational components / 会話コンポーネント
1. Acknowledgements / 承認
はい。
承認とは「OK」「大丈夫」「ありがとう」などの語句。
“Okay,” “Sure,” “Alright,” “Thanks,” “Got it.”
承認、確認、辞退、確認、訂正、および主題の変更前に使用する。
2. Apologies / 謝罪
すみません。〇〇をすることができません。
- 基本的に謝罪は避ける。あまりにも頻繁に「すみません」と言うことは煩わしいほど反復的に聞こえ、ペルソナに対するユーザーの自信を損なう危険がある。
- 謝罪ではなくソリューションを提供する。
- 問題解決のために何もすることができない場合、ユーザーに短く知らせる。
- 謝罪の代わりに承認する。
- ユーザーを責めない。
- 他人を責めない。
3. Commands / コマンド
- ユーザーが何を言えるかではなく、ユーザーができることを教える。
- 動詞句を使用してユーザーができるアクションを示す。(質問してユーザーに自分の言葉で答えてもらう)
4. Confirmations / 確認
- 確認する必要があるもの
- 1. パラメータ
- 2. アクション : アシスタントを完了しようとしている、または完了した何か
- 処理する方法
- 1. 明示的な確認 : ユーザーから応答が必要な確認
( 例 : メッセージを正しく取得できましたか ? Yes/No )
- 2. 暗黙の確認 : ユーザーが修正を加えたい場合はユーザーからの応答があるかもしれないが、ユーザーからの応答は不要。確認して、続行する。
- 3. 確認なし : Stop.など停止した場合に応答しないで終了するなど
5. Discourse markers / 談話マーカー
ところで…、さらに、また、同じように、確かに、とにかく、しかし、参考までに、例えば、その場合は、このため、そのため、つまり、あるいは、代わりに、全体として、要約すると、結果的に、したがって、同時に、しばらくしてから、それはさておき、ちょっと、ちなみに、おそらく、実際には、まず、最後に、1、2、3…(数字やアルファベット列挙)
コミュニケーションをとるときに必要な次の単語や文脈で使われる話し言葉。
- 談話マーカーは自立できない。「ちなみに」「例えば」だけでは成り立たない。追加コンテンツが必要。
- 談話マーカーを削除しても、文の真実性は変わらない。談話マーカーがなくても会話が成り立つこと。しかし、会話を自然で滑らかなものにするために不可欠。
6. Earcons / イヤホン
<電源入れた時の歓迎チャイム> etc
特定の意味を伝えるように設計された一種の非言語音声(NVA)。
例 : メール送信したときや削除したときなど。
Google Doc : サウンドライブラリー
7. Endings / 終わり
あなたの手助けできることは他にありますか ?
- 会話を適切に終わらせなければならない。
- 完了アクションを確認し、積極的な支援を提供する機会を探す。
- チップス内の関連するインテントを提案する。
- タスクを終了する前にユーザーを終了させる。重要な進捗が失われない限り、再確認しない。
- さよならを言う。会話が終わったことをユーザーが示したら、優雅に終了する。
- ユーザーにデバイス切り替えを強制しない。ユーザーの選択を尊重する。
- 未サポートのアクションの場合、「すみません」などの謝罪を過剰に使用しない。「まだ〇〇はできません」などのフレーズを使用する。
- 残念なことに回復不可能なエラーで会話を終了する場合、エラーを確認し、改善できる方法があるかを確認する。「もう一度やり直してください」など曖昧な行為を与えない。過度に謝罪をしない。
8. Errors / エラー
すみません
アクションエラーにどう反応するかによってUXが向上or低下する。ユーザーが自分のタスクを完了できない場合、次に話すことはほとんどなくなる。だめな対応は次に繋がらない。
- 以下の考慮事項に留意する
-- ユーザーに協力的であること。ユーザーはただ何かを達成しようとしているので、それが何かを理解するのはこちらの仕事。
-- 何がうまくいかないかの説明をするときに、透明性を保つ。
-- コンテキストの固有。同じ情報を求めていても、会話内容は2,3回目の試行で異なる。
- エラーには3種類ある
- 1. 入力なし : ユーザーの応答が聞こえなかった、マイクが閉じるまでにユーザーが反応しなかった
- 2. 存在しないアクション : ユーザーの応答を理解または解釈することができなかった
- 3. システムエラー : アクションが情報に依存しているシステムではタスクを完了できない
- 一致しない場合
-- なぜ一致しないのか : 会話中に躊躇したり、考えを変えたり、文章を完成していなかったとき
-- 初回の不一致 : 情報を迅速かつ簡潔に再収集するか、別の方法で収集する。機械的に聞こえるので1回目の同じ言葉で質問を繰り返さないこと。
-- 応答が曖昧で迷っている場合 : 別の追加情報を含めると、ユーザーが自分の要求を絞り込むのに役立つ。
-- 2回の不一致 : 各コンテキストでユーザーが抱える問題を検討する。次に、プロンプトに、オプション、例、または視覚情報の形式で追加サポートを含める。ユーザーを非難しないこと。
-- どうしても不一致 : ユーザーのフラストレーションを避けるため、2回以上は会話を終了する。他の方法で作業を完了できるかどうかをユーザーに知らせる。
- 入力なし
-- 何も言わなかった or 十分な音量で話していない : 初回の応答と言い方を変えて応答する
-- ユーザーが困惑する可能性が高い場合は、他のサポートが提供できるかを確認する
-- 情報が不要な場合は次のステップに進む
-- 1回目は入力ありで2回目の応答で入力なし : 言い方を変えて、もう一度言う
-- まったく入力なし : 2回目の入力なしで会話を適切に終了する
- システムエラー
-- 過度な記述的な説明をせずにわかりやすく応答する。次のステップがあるかを確認する。
-- リクエストがどうして無効であったかをフィードバックし、可能であればユーザーを教育する。
9. Greetings / あいさつ
ようこそ
- 目的
- 1. ユーザーを歓迎する。初めてと再会とで変える。「初めまして」「お帰りなさい」「また会ったね」など。
- 2. 期待の設定 : なにか質問する。質問しないと次の会話に繋がらない。一度に2つ以上の選択肢を提供するのはNG。
- 3. ユーザーに制御を任せる。何が言えるかをユーザーに伝えない。(例 : できるアクションについて「〇〇と言ってください」とかはNG)
10. Informational statements / 情報ステートメント
- 簡単な概要を説明し、情報を紹介。
- いくつかの回答では簡単な情報提供で十分。文脈なしに答えを提供しないこと。
- ほとんどの情報ステートメントには付随するビジュアルがある。音声プロンプト、ディスプレイブロンプト、およびビジュアルが長くなりすぎないようにする。
- ビジュアルが最も良い答えを提供できるときでさえ、会話メッセージ中心であることを確認する。ユーザーにビジュアルを見ることを強制しない。
- 関連性が高い場合、要求された以上の情報を提供できる。
- 関連性が低い場合、ビジュアルを使用して詳細を追加する。
- メニューまたはオプションをユーザーに提示することができる。
11. Questions / 質問
- 広い焦点から狭い焦点の質問へ
- ユーザーが何を言えるかを考える。質問した後に話し続けないこと。
- 狭い焦点の質問のための例
-- 初回エラー発生では、ユーザーに助けを求める。ユーザーが質問に答える必要がない応答をしない。関係ない発言は時間がかかることを忘れないこと。
-- 曖昧さの回避 : 言葉は曖昧さに満ちているが、ほとんどの場合は文脈を通して解決できる。文脈が十分でないときは、ユーザーに追加情報を尋ねてもOK。
-- 明示的な確認 : ユーザーが誤解するコストが高い言葉(例 : 名前、住所)、元に戻すのが困難なアクション(例 : ユーザーデータ削除、トランザクション完了など)の実行前に尋ねる。
- ユーザーの発言から学ぶ
-- ユーザーデータから収集された洞察は非常に貴重。分析およびモニタリングツールは質問が実際にどのように機能しているかを学ぶのに役立つ。
-- サポートされていない応答を処理するために以下のアプローチがある
-- 1. 文法に新しい同義語を追加して、それらが既存の機能にマッピングされるようにする
-- 2. 質問の焦点を絞って、ユーザーが回答できる範囲を制限する
-- 3. 要求された機能をサポートするための新しい会話型パスを設計する
12. Suggestions / 提案
〇〇についてもっと教えてください。例えば、△△△、□□□、または○○○について聞いてください。？？？を見つけるのにも役立ちます。あなたは何について知りたいですか ?
- ユーザーが質問に答えるのを助けるために提案を提供することができる。
- 音声プロンプトの提案 : ユーザーが言うことができる会話フレーズの例を提供する。例であって指示をしない。スクリーンが必要な提案をしない。
- チップスの提案(画面があるデバイスの場合) : チップスで人気のある答えを提供する。音声プロンプトとチップス両方に提案を入れないこと。
- ヒントと情報の見つけやすさ : 関連情報の最後にヒントを追加することを検討する。
13. Chips / チップス
カートに追加 etc
- 目的
-- 1.トピックスを絞り込む : ユーザーの目的と意図を明確にするチップスを提供
-- 2. 関連トピック、次のステップ、要点を発見する
-- 3. 行動を起こす
- 必須条件
-- ディスプレイがある場合のみ
-- 1ターンあたりの最大チップス数 : 8
-- 1チップスの最大テキスト量 : 25文字
-- ユーザー応答 : デフォルトではユーザーがチップスをタップするとそのテキストがユーザー応答になる。アクションを引き起こすテキストをチップスに含める必要がある。
-- URL(オプション) : 外部Webサイトにリンクすることができる
- ガイドライン
-- ユーザーが会話しやすいように会話する
-- ユーザーの信頼を確保するために関連する
-- ユーザーの関与を促し会話を促進するための行動指針
-- 内容を簡潔にし、表示されるチップス数を最大化する
-- 対話を通じて信頼できる経験を生み出すために一貫性を保つ
-- ユーザーの期待を適切に設定するために目的を明確にする
- 様々なオプションを用意する
- ユーザーが言うことができる正確な単語を使用するよりも、簡潔な行動試行であることを優先する
- 動詞〜名詞の組み合わせを指示する。名詞のみ、動詞のみは推奨しない。例 : NG =「送る」OK =「〇〇を送る」
- リストやカルーセルを表示しているところで、複数のチップスを出さない。リスト・カルーセルで表示してないものを出す。(None of those)
Visual components / ビジュアルコンポーネント
視覚的要素には、カード、カルーセル、その他の視覚的アセットが含まれる。
オプションをスキャンして比較するのに最適。ビジュアルコンポーネントは、詳細な情報を表示する場合に便利だが、ダイアログの順番ごとに必須というわけではない。
1. Basic card / ベーシックカード
基本的なカード。画像とテキストを表示。
- 画像 (説明がない場合必須) : 最大1枚の画像、GIF可。代替テキスト必須。(一枚の絵は一千語に匹敵する)
- カード背景 (任意) : カスタマイズ可能な画像または色
- タイトル (任意) : 最大1行推奨・カスタマイズ可能
- 字幕 (任意) : 最大1行推奨
- 説明 (画像がない場合必須) : 1画像最大10行(約500文字), 画像なし最大15行(約750文字) それ以上は切り捨て
- アクションリンク (任意) : リンク表示する場合リンクタイトル必須。カード最後に1リンク指定可能
2. Browsing carousel / ブラウジングカルーセル
ブラウジング(閲覧用)カルーセルは要素がWebからのコンテンツの場合に、ユーザーが多数のアイテムを1つ選択できるように最適化されている。
- URL (必須) : カルーセルコンテンツは全てリンクしている必要がある。Accelerated Mobile Pages (AMP) コンテンツを推奨。
- 画像 (任意) : 正方形・横長・縦長の3種から選択。代替テキスト必須。
- プライマリーテキスト (必須) : 音声選択をサポートするため会話でわかりやすいものにする。最大2行まで推奨。
- セカンダリーテキスト (任意) : 最大2行まで推奨。
- フッター (任意) : 画面にもよるが約50文字。カード下部に固定しているため、説明が短い場合はフッター上に余白ができる。
- カルーセルアイテム数 : 最大10, 最小2まで
3. Carousel / カルーセル
カルーセルは、それらのアイテムが画像によってもっとも簡単に区別される場合に、ユーザーが多くのアイテムの1つを選択できるように最適化されている。
- 画像 (任意) : 正方形・横長・縦長の3種から選択。代替テキスト必須。
- カード背景 (任意) : カスタマイズ可能な画像または色
- プライマリーテキスト (必須) : 音声選択をサポートするため会話でわかりやすいものにする。最大2行まで推奨。
- セカンダリーテキスト (任意) : 最大2行まで推奨。
- カルーセルアイテム数 : 最大10, 最小2まで
---
- 会話でわかりやすいタイトル(プライマリーテキスト)をアイテムに使用する。
- 簡単な概要(セカンダリーテキスト)でカルーセルを紹介する。
- カルーセルのアイテムの1つを選択するように促すが、強制しないこと。「どれでもない」等のチップスを添える。
4. List / リスト
テキストによって簡単に区別できる場合、リストはユーザーが多くの項目のうちの1つを選択できるように最適化されている。
- リストタイトル (任意) : 最大1行
- プライマリーテキスト (必須) : 音声選択をサポートするため会話でわかりやすいものにする。最大1行まで推奨。
- セカンダリーテキスト (任意) : 最大2行まで推奨。
- 画像 (任意) : 右側に表示される
- カード背景 (任意) : カスタマイズ可能な画像または色
- アイテム数 : 最大30, 最小2まで
---
- 有用で関連性のある情報のみを含め、説明を簡潔にする。
- リストに2つの項目しかなく単純なテキストの場合、チップスで表示に切り替える。
- 1つだけのリストはNG。1つの場合はリストを使うことは不可。
5. Media response / メディア表示
メディアは、音楽や動画などのオーディオコンテンツの再生と再生制御のために使用。
- 画像 : 正方形または上部に大きな画像(カード全幅に入る)
-- 小 (任意) : 36x36, 代替テキスト必須。
-- 大 (任意) : 高さ192, 縦横比が異なる場合は中央配置, GIF可。代替テキスト必須。
- タイトル (必須) : 最大2行まで
- 説明 (任意) : 最大2行まで
- メディアファイル (必須) : 正しくフォーマットされたMP3形式。ライブストリーミングは非サポート。詳しくは開発向け資料参照
---
- メディアを簡単に紹介し、ユーザーに他のアクションも添える(メディア以外の操作をチップスに入れる)
- メディアカード内表示
-- 再生/一時停止
-- 再起動
-- 30秒進む
-- 30秒戻る
- 音声/キーボード
-- Play 再生
-- Pause 一時停止
-- Stop ストップ
-- Start over やり直す
- 状態表示
-- 経過時間は左側に表示。フォーマットは HH:MM:SS 形式。時間が0のときはいつでもドロップされる
-- 合計時間は右側に HH:MM:SS 形式
-- プログレスバー表示
6. Table / テーブル
テーブルは、静的データを簡単にスキャンできる形式で表示するために使用。
- テーブルタイトル (任意) : 最大1行
- テーブルサブタイトル(任意) : 最大1行
- 画像(任意) : カスタマイズ可能な画像形状
- カード背景 (任意) : カスタマイズ可能な画像または色
- 列ヘッダー (必須) : 文字数制限はないが画面幅が狭いと切り捨てられる
- 行内容 (必須) : 最大20文字
- アクションリンク (任意) : 1リンク許可
---
- データは簡潔で、重要で、理解しやすいものにする。
- ビジュアルが最も良い答えを提供するときでも、会話で前進できるような質問をする。
コンポーネント間の関係
全てのコンポーネントが単一の統一された応答を提供することを忘れないこと。
- 常に質問に質問を含める
- 冗長性を避ける
- プロンプトに短い答えを、ビジュアルに詳細を入力する
- ビジュアルが最も良い答えを提供する場合でも、プロンプトがメッセージの中心であることを確認する
- リストやカルーセルから選択するようにユーザーに促すが、音声で続けることもできるようにする
カスタマイズ
- 全体背景色(暗い色は不可)、プライマリーテキストカラーは変更可能。
セカンダリーテキストは色変更不可。
- 背景画像を設定可能。この場合テキストが自動で全て白に変わる。
- プライマリーテキストのみフォントファミリーを変更できる。ただしセカンダリーより読みにくいフォントにするのは不可。セカンダリーテキストを制御することはできない。
- Material Foundationに従った構造要素の形状変更ができる。角丸や角ばった角など。
補足・カスタマイズについて上記のように書いてたが実際には開発担当からdevのドキュメントにはオプション存在しないし、カスタマイズできないという話になった...。そのうち変わるかも ?
参考
Conversation Design
https://designguidelines.withgoogle.com/conversation/
UI toolkit
https://developers.google.com/actions/design/ui-toolkit?hl=ja
会話デザイン ( 実装向けドキュメント )
https://developers.google.com/actions/design/?hl=ja
会話デザインのためのクイックリファレンス ( PDF )
https://developers.google.com/actions/downloads/design-principles-quick-reference.pdf?hl=ja
Touch Enabled Receiver App
( Google Cast の動画・音楽再生プレイヤーの仕様 )
https://developers.google.com/cast/docs/design_checklist/receiver_touch
Implementing media browse on smart displays
( メディアブラウザの仕様 )
https://codelabs.developers.google.com/codelabs/cast-receiver/#11
Dialogflow・言語解析エンジン。
音声入力で問題となりやすい自然言語の解析を容易にする。
https://dialogflow.com/
Google Noto Fonts
https://www.google.com/get/noto/
Google Fonts + 日本語
https://googlefonts.github.io/japanese/
日本語音声
https://developers.google.com/actions/localization/languages-locales#ja-jp_tts_voices
CLOUD TEXT-TO-SPEECH・機械学習機能によりテキスト音声変換。
https://cloud.google.com/text-to-speech/?hl=ja
Actions on Google Reference Document Overview
Googleアシスタントリファレンス概要
https://aogdevs.jp/doc-overview/
Google Doc : Sound Library サウンドライブラリー
https://developers.google.com/actions/tools/sound-library/
---
2018.06.10. - Conversation Designの理解 ( スライド )
https://www.slideshare.net/nobsato/abc2018-spring-cxd-conversation-design
2018.03.14. - VUIデザインの勘所 ( スライド )
https://www.slideshare.net/yukio.andoh/voice-ui-designer-meetup-tokyo-vui
2018.01.24. - Dialogflow入門
https://qiita.com/kenz_firespeed/items/0979ceb05e4e3299f313