ストリーミングはほとんどのブラウザと
Developerアプリで視聴できます。
-
優れたショートカットを設計する
ショートカットを使用すると、ユーザーはいつでも(またはショートカットAppで)情報を確認したり、アクションを実行したりすることができます。優れたショートカットを作り出すには、Appにおけるユーザーのワークフローを高速化する方法を見定める慎重なデザインプランが必要です。このセッションでは、優れたショートカットの条件と、便利で、美しく、応答性の高い体験を設計する方法を紹介します。パラメータを使用する際にSiriのダイアログフローを緻密に計画して、ショートカットを柔軟で便利にする方法の例についてご確認ください。
リソース
- Donating Shortcuts
- SiriKit
- Soup Chef: Accelerating App Interactions with Shortcuts
- プレゼンテーションスライド(PDF)
関連ビデオ
WWDC23
WWDC21
WWDC19
-
ダウンロード
(音楽)
(拍手) Siri ショートカットチームの ジェイです 優れたショートカットの 作成方法を紹介します
主なトピックは3つです
1つ目はショートカットに適した Appの機能の見極め方
2つ目はショートカットを 目立たせる方法
3つ目はiOS 13のショートカットの インタラクティブ機能で Siriの体験を向上させる方法です
ショートカットとは Appの機能を ユーザの前に届ける方法です ショートカットが表示されたら 役立つ場面を確認します
Appの利用状況が分かれば 次はいつ使うかを予測して ショートカットを提案 ロック画面や検索画面に表示します これは日課の運動を すぐに開始できるショートカットです
フレーズを指定しSiriに追加すれば いつでも声で起動できます 夕食を注文するショートカットでは 1回の操作で地中海料理が届きます
ハンズフリーやアイズフリーでの 利用も可能です HomePodへ “Hey Siri バスの時刻”と言うと Siriが時刻を案内します
マルチステップの ショートカットも可能です 例えば 帰宅時のショートカット 夕食を注文して音楽を再生し 運転の最短ルートを表示します
Appでよく使う機能の高速化に ショートカットが最適だと分かります 簡潔な情報を音声でも提供し 異なるAppと組み合わせ 機能させることもできます
Siriからの提案は iOS 12で導入されました 開発方法の詳細は 過去のセッションをご参照ください 今回はSiriの新機能を活用する ショートカットに注目します ショートカットに適した Appの機能をどう選定するか Soup Chefを例に説明します スープを注文し 配達も頼めるAppです デザイン過程を見ていきましょう
Appの機能を列挙します その際 声で操作することを考えます このAppで主に行うのは メニューの閲覧と注文― 注文状況や履歴の確認です 1つずつ見ていきましょう
メニューの閲覧は視覚を使うので 音声化は困難です スクロールなどの操作も必要です また 情報が毎回変わるものでは ありません
過程の1つで 重要なアクションでもありません
ショートカットは不要でしょう
注文状況はSiriで確認できると いいかもしれません しかし 利用するのは 注文後のわずかな時間です このショートカットを利用するとしたら 配達までに日数や段階がある場合です
注文履歴は 定期的に確認するか疑問です 不向きでしょう
注文は大事なアクションです 最も重要と言えます 好きなスープは繰り返し注文します
かなりショートカット向きです
大事なのは 重要な機能であり 繰り返し使うこと 視覚やタップに頼らず声が使え― 起動の機会が多いこと 少なければ不向きです
では スープが再注文できる ショートカットを App内に明示する方法を見ます 「Siri に追加」ボタンで Siri ショートカットにできる機能が 一目瞭然です 注意点があります
メニューの全品目には つけないでください いくらデザインが良くても 全部につける必要はありません ボタンが多いと 注文時の邪魔になります しかも 注文履歴がない品目なら 再注文の提案は筋が通りません
再注文の可能性を捉えた時に ユーザに表示しましょう
例えば 注文の直後に ボタンを表示します 以前に注文して気に入った物なら 再注文の可能性があります 操作の邪魔にもなりません 注文完了時が良い機会です
Appのデザインに ボタンがフィットするよう― 角の丸みが調整できます
外観はユーザのモードに合わせて 切り替わります
万が一 デザインに合わなければ 独自にボタンを作成することも可能です しかし 機能の再現が必要です
標準のボタンは 指定したフレーズを表示します これならフレーズを忘れても安心です
タップすると 編集用のシートが表示されます
App内にショートカットを集約する場合 ボタンを並べるのは やはりお勧めしません 代わりにUIKitの要素が使えます ユーザがショートカットを設定する場合 フレーズの表示は必須です タップによる編集も可能にします ユーザ側の設定を確認してみましょう
ボタンをタップするとシートが表示され 起動時のフレーズが選べます iOS 13はApp側で デフォルト値を設定できます ユーザの多くは そのフレーズを使うので 適切な値が必要です
“スープを注文”は覚えやすいですね ユーザも気に入るでしょう スープ以外の例も見てみます
“バスの時刻を確認” この短いフレーズは妥当に思えますが 言い方が変わる可能性が大いにあります 例えば― “バスの時刻を調べて” “バスの時刻” 1文字抜けることも
Siriは一致を試みますが 長いフレーズは多様に変化します 最適なフレーズとは言えません
3語以下に短くすることです 固有名詞か動詞と目的語に限定すると 語順などが変わる可能性が減ります
スープの注文用 ショートカットを作る際 毎回違うスープを注文するには どうするか? iOS 13では“Do”の下のセルをタップ フィールドの1つをタップし 情報をカスタマイズします
ユーザはフィールドを空白にできます 空白があると Appの代わりにSiriが尋ねます やり取りは最小限に抑え よくやる作業を高速化するのが理想です
アクションのシートに 可能な限りの情報を含めれば 操作は1~2回で済みます すべて指定済みの場合 1回で確認画面に進みます
では すべてを空白にし Siriとのやり取りで詳細を埋めるには?
Siriとの対話だけで 注文する例を見ます
注文の実行に どんな情報が必要か考えます まず スープの種類 配達か 店へ行くのか それによって配達先の住所や 現在地の情報も必要です 情報を集める順序と方法を考える時 Siriとの会話であることを考慮します
会話を視覚化できるのが台本です 会話の流れを記すのに便利です
もちろん流れは1つではなく 想定されるすべての会話をメモします もし ユーザが対象外のことを選んだら Siriはそれを伝えるべきでしょう
設計仕様として 台本を渡すのは体裁が悪いため 最終的には 恐らくこうなります 想定される会話を網羅した フローチャートです Siriによる提案と入力処理には 特定の方法があります ここでは自由な会話パターンを 見ていきます
最初はプロンプトです 値を回収できる 最も自由な回答形式です 質問として書き 的確な答えを導く言い回しにします
ユーザの発話が複数の意味を持つ時は 選択肢からその意味を 選べるようにします あいまい性の除去です 手間が増えるこのプロンプトを 最小限にするため 先に選択肢を表示します ユーザが“スープを注文”と言ったら 選択肢を表示 選択肢を限定できる場合に 利用してください 一覧からの選択を促す質問とし “どれ”などで始めるといいでしょう
ディスプレイがなければ 選択肢を読み上げます HomePodなど 声で起動するケースです
SiriはビジュアルUIの内容を 読み上げますが 似たような選択肢が多いと くどくなります これを改善するため 各選択肢に発音の強弱をつけ 読み方を指定することができます
少し異なる例も見ます スープが2種類あるとします ビーフスープと野菜スープなら “ビーフまたは野菜?”にします 読み上げるのは 違いを表す言葉だけです
次に ユーザの発話に 対処する必要があります 選択肢と同じ言葉とは限りません
微妙な言葉の違いに対処するため 選択肢の同義語をSiriに与えます 回答がビーフなら ビーフスープです
ここで同義語の注意点です 質問の仕方は回答に影響します
選択肢を大まかな言い方で 説明する場合 大まかな答え方にも 対応できるようにします
重大な結果につながる回答に対し 確認が必要な場合 パラメータの確認を要求します これは減速につながるため 例外的な利用が賢明です
パラメータの確認の代替手段が 要求を予測するAppのロジックです 最も妥当な予測を示し 確認を得れば さらなる情報は不要です 否定されたら より自由な回答形式に戻ります 予測が可能なら 大きな時間短縮になります
最後はアクション全体を確認する プロンプトです 特に重要なアクションに使えます 実行直前に アクションの全詳細を確認できます 決定に関わる価格などの ビジュアルUIはカスタマイズ可能です 注文のアクションには ユーザの確認が必要です 確認の場面では 最高の体験を提供しましょう
画面を見ずに実行することも考慮し 音声用のダイアログを提供します ユーザの選択を助ける 追加のダイアログです
ビジュアルUIに表示された情報を 言葉で伝えることがその目的です ディスプレイに描画する 最も重要な情報を 口語にすると考えます
最後は応答です Siriが状況を伝えます 追加の詳細説明は ビジュアルUIサマリで提供します 配達員の名前や配達予定時間などです “注文完了”と詳細を ディスプレイに表示しています 音声のみの場合は 具体的な説明が必要です
繰り返しますが 追加のダイアログは 応答画面の最も重要な情報に相当します
確認と応答のダイアログ作成時に ショートカット用の カテゴリを選択します Xcode内で機能に最も近い カテゴリを選び定義します 今回は明らかにOrderです
Siriはカテゴリに基づき質問をします そのため 確認のダイアログに 質問を含めないでください
応答もカテゴリに基づき Siriが状況を伝え カスタム ダイアログは そのあとに続きます
音声対話も堅牢さを追求し ユーザに操作を強いることは 避けるべきです パラメータ値が無効なら エラーメッセージが必要です Siriは値を聞き直します 本来 この展開は避けるべきです 無効と分かっている選択肢は 表示しないでください
ユーザを救う機会も考慮しましょう 例えば自宅を 配達先に設定しているユーザは 配達先を言い慣れていません 自宅から離れた場所にいる場合 配達先の確認が必要です ショートカットで このまま実行したい場合は 任意の場所をタップします ユーザインターフェイス全体を 起動ボタンと考えます そのため 操作可能な要素は 描画できません
タップしたら 適切な画面が開くようにします ユーザがAppに提供した 全情報がある場所です
ダイアログの作成には 時間をかけましょう 簡単にはできません 出荷前にはデモを行ってください 音声対話では言葉が ユーザインターフェイスです 画面上のデザイン同様 Siriが話す言葉にも注意を払います
ガイドラインの確認です
個性的なものはダメです ショートカットを実行するたび 不要な会話が流れたら イライラしますよね
Siriでテストをしてください 3回聞いて どう感じるでしょう 10回なら? 不快に感じる部分が 余分な言葉だと分かります
簡潔かつ中立的に 期待する応答の形式を伝えます
App名は含めません
確認と応答の ユーザインターフェイスに含まれます Siriが言う時もあります
安心して外してください
ユーザ名も含めないでください
Siriは時々 ユーザ名を確認します 重複すると しつこく感じます
外しましょう
実行するのはAppなので 一人称代名詞は避けます 微妙な違いですが重要です Siriが“私”と言うと Appの能力を 熟知しているように聞こえます ユーザは無理なアクションを 試すでしょう
そこで 中立的に “選択肢があります”などとします
おさらいです
ショートカットで よく使う機能が向上します
「Siri に追加」ボタンで その機能をユーザに伝えます
Siriの対話は論理的で 簡潔かつ堅牢に
ダイアログの作成は慎重に ありがとうございました (拍手)
-
-
特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。
クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。