ストリーミングはほとんどのブラウザと
Developerアプリで視聴できます。
-
優れたML体験をデザインする
機械学習により、ユーザーが言ったことを理解し、ユーザーが好きなものを予測して提案し、ユーザーが新しい豊かな方法で自分を表現できる新しい体験を生み出すことが可能になります。また、機械学習は、日常のタスクを自動化し、やり取りの精度と速度を向上することで、既存の体験を向上させます。このセッションでは、ML体験をAppに組み込み、思い通りに操作できるユーザーインターフェイスを設計するための実践的なアプローチについて説明します。
リソース
関連ビデオ
WWDC21
WWDC19
-
ダウンロード
(音楽)
(拍手) こんにちは
ご参加ありがとうございます 今から私ケイアと デザイナーのルビーとキャスが デザインと機械学習について お話しします Appleは以前から デザインと機械学習に注目しています 機械学習で話題になるのは 音声認識やコンピュータビジョンの 技術進歩です ディープニューラルネットや オンデバイス機械学習の カスタム処理も論じます そうした議論をするのは製品のためです 現在構築している製品の多くや 将来的に構築したい 製品や体験の多くには 機械学習が不可欠です 例を見ましょう
AirPodsは Siriを介して デバイスを音声操作します 音楽の変更や電話応答を 手を使わず画面を見ずに行えます このAirPods体験は 機械学習とSiriのなせる業です 機械学習で生成されるFace IDで iOSデバイスの認証を 迅速 安全に行えます
Appleは 機械学習を 意外な形でも活用して デバイスの体験を向上させています 例えばタイピング体験向上のため ユーザの入力を予測して タップエリアを拡大 縮小します 機械学習アプリケーションは 音声アシスタント コンテンツ推薦 自動運転車に限りません ソフトウェア工学の 他のアプリケーションに劣らず多様です 既存の製品を改良でき 新製品も実現可能にします Appleでここしばらく検討しているのは 優れた機械学習製品の要件です それをPhotosの体験で見ていきましょう Photosでの機械学習活用は アルバムの作成 写真の編集 メモリーの検索など多様です メモリーといえば 私は最近これを捜しました 数年前に撮った 家族の友アンジーの写真です その場の友人に ふと見せたくなったのです つい最近まで 写真は探すのが困難でした 場所や時期を思い浮かべて 何千枚も調べました 大変です 私としてはメモリーを共有したくても 写真検索がネックでした
iOS 10では新たな体験として 被写体を検索できるようになりました この体験は改良を重ねていますが 現状をご紹介します
“dog”と入力して検索すると イヌの写真がヒット あとは選んで共有するだけです 被写体で探せれば メモリーの扱い方も変わります これは今となっては当然の機能で なかった頃を思い出せないほど 優れたデザインです この体験は 多くのインターフェイスから成ります Photosは検索可能なカテゴリを提案 入力を自動補完し 結果をモーメントに関連付けます この体験のデザインは グリッドビューにとどまりません ただ見ていては 検索体験の最重要部を見逃します 検索可能なカテゴリ別の結果表示です 体験のこうした側面は デザインするべきです 含めるカテゴリとその特質レベルを 決めることになります
優れた機械学習体験の構築は インターフェイスに限りません その意味は? デザインといえば インターフェイスを考えがちです 製品のルック&フィールや 体験の流れです
機械学習では 製品の機能をデザインします 皆さんの多くは 機械学習の体験がありますよね 詳しい方もいるでしょうが 写真検索での機械学習の役割を ご紹介します
Photosの内部には関数があります 受け取った写真のカテゴリを 調べる関数です この写真はイヌと認識します
従来のプログラミングでは 挙動を命じる関数を書く必要があります
多くの犬種に対応しなくてはならず シナリオ 写真解像度も様々です 顧客もイヌも多様だからです 他の動物の写真が混入しないよう 似た動物を区別する必要もあります このハイエナは イヌのようでも飼えません (笑い声) 無数のバリエーションを一般化する コーディングは不可能です そしてイヌは カテゴリの1つにすぎません 挙動を指示できないが 体験を作りたい一例です
こうした体験の多くで 機械学習を活用できます 学習手段は例です イヌの写真とそれ以外を区別したければ イヌのいる写真といない写真を与えます 機械学習が学ぶ関数は 後にアプリケーションで使えます
アンジーをイヌと理解するこの関数を モデルと呼びます モデルはPhotosの検索体験を 作る仕組みです
このモデルは 初見の写真を一般化できます 犬種を識別し 他の動物や物と区別できるのです モデルは機械学習体験の中核です 機械学習を用いる製品や体験は モデルを用います Siriはモデルで音声をテキスト変換 キーボードは 入力に基づく予測に モデルを活用しています
優れた機械学習体験をデザインするには 機能もルック&フィールも デザインしなくてはなりません 今回はモデルとインターフェイスの 両方を取り上げます モデルの作成は複雑です アルゴリズム パラメータ フレームワークを巡る判断が多く どの判断も モデルの挙動ひいては体験に影響します 機械学習の判断は すべてデザイン絡みです ただしデザインの効果には差があります 特に効果的なものを取り上げましょう
コンピュータの学習のデザインに 必要なのは データです 何を評価するかのデザインに必要なのは 指標です
インターフェイスのデザインも必要です モデルの出力とその提示方法も デザインします ユーザのモデルとの対話もデザインし 時にはモデルを改良する入力も与えます それはまた後ほど
では始めましょう まずデータの話です
写真のイヌを認識するため 例を用いてモデルを作りました その例をデータと呼びます
優れた検索体験は 多様なデータで作ります 検索可能にしたいカテゴリの 写真が必要です イヌと他の動物の写真を 多数与えることで イヌの検索時に別の動物を 表示しないようにします 優れた検索体験は 何千ものカテゴリに対応し ユーザの検索需要をカバーします 各カテゴリにデータが必要です カテゴリの新設にも改良にも データが欠かせません データ選択は 体験をデザインするカギです データがモデルの挙動を決めます データ選択はモデル作りに最も重要です 重要なシナリオを含むデータがなければ そのシナリオに役立つモデルは 作れないでしょう
データがモデルの挙動を決め モデルの挙動が体験を決めるのです データ選択には 顧客に役立つ価値観を 反映する必要があります
例で理解を深めましょう ポートレートモードは
機械学習を用いて顔を検知し 体を背景と区分します 顔認証は従来 有色人種の認識が苦手です Appleでは体験の包括性を確保するため デザインチームと エンジニアリングチームが 様々な人種 文化 シナリオの データを収集 作りたい体験に合う データセットを構築しました データの意図的な収集です データ収集時には自問しましょう 誰が集めるか? 何のデータか? どう集めるか? データセットにバイアスが混入すると 公正さが揺らぎます 公正さと包括性を追求するべきです 他のデザイン意図との ズレがないかの確認も必要です 楽しい体験や役立つ体験を作るなら その意図に沿うデータを抽出したか? アウトドア製品なら そのシナリオから抽出したか? この原則をつい度外視して 既存の顧客からデータを抽出するだけで 済ませたくなります 統一的な標本は便利ですが 世界を切り取るだけでは駄目です バイアスを強化しかねません 既存の顧客ではなく 求める顧客に最適化するべきです そのままの世界ではなく 求める世界を切り取るべきなのです データ収集は 体験をデザインする手段であり 優れた体験は世界を変えられます 現状の反映では足りません これをどう実践するか?
まずデータを意図的に集めます 作ろうとしている体験を理解し 何が必要か考えましょう 特定のシナリオが重要なら そのデータ収集がカギです 最初に時間をかけて 適切なデータを集めれば 時間 労力 費用を節約できます
データセットのバイアスを 検証しましょう 誰がどう製品を使うかの カタログを作り 特定の母集団や体験に対して バイアスがないか調べるのです
データを更新しましょう 製品の仕様は 顧客や市場や真に作りたいものが 分かるにつれて変わります データは 集め直さず調整するのです 重要でない概念は除き 製品の目的に合うよう 随時調整してください
標準データセットは要注意です 学術・産業用の ベンチマークデータセットは 機械学習の仕組みを知る手始めに 役立ちます 製品開発工程の強化にも 使えるでしょう しかし皆さんの体験のために デザインされてはいません 既製のデータセットは 適用範囲を確認してください 必要に応じてデータを増強しましょう
データのカタログ作成と データ収集に― 時間をかけるのです 求める仕様と機械学習の機能を マッチさせるのに役立ちます
以上がモデルの学習に使うデータです
次にモデルの評価に使う 指標の話をしましょう
評価は検証で行います 写真検索なら モデルに動物の写真を与えて 被写体を予測させます そして正しかった回数と 誤りだった回数を比較するのです このモデルの例では 予測精度は75%でした このような指標を用いて モデルの成否を表すことで このまま使えるか改良が必要かを 判断します モデルを評価する観点は 実行速度や 対応カテゴリ数など様々です それを組み合わせて 適切な指標群を作るのです 指標のデザインで モデルひいては体験の評価が決まります しかし最後は皆さんの判断です
指標は 良い体験の判断基準です 何を重視し無視するかによって 体験の一部は 評価されない場合もあるでしょう
つまり指標には 皆さんの価値観が反映されます 例としてFace IDを見てみましょう
Face IDは機械学習で顔認証し デバイスをロック解除します Face IDのデザイン意図のうち 最も重要なのは安全性です 顧客の個人情報が託されるからです Appleは様々なセキュリティ指標を 使っています その1つに“任意の人物がデバイスを ロック解除する可能性”があり これを下げようと取り組みました
当初 任意の人物が デバイスをロック解除できる確率は 100万分の1でした この事実をお客様に伝えることで 個人情報重視の姿勢が理解され Face IDは信頼されました ただ 話は100万分の1で済まず エラーケースの人物 シナリオ 体験を 検討しなくてはなりません
皆さんが私になったと想像してください Appleの普通の社員で 新しいMacBook Proに関して 最近トラブルがありました 誤って 別のタイムラインへの 入り口を作ってしまい―
鏡像世界からの侵入者との 戦いが始まったのです 機密データへのアクセスを防ぐ頼りは パスコードです そっくりの親戚や 悪人の双子がいるような場合も 同様の予防措置が必要です Appleもこの制約を検討しており 基調講演で時間を割きました お客様の理解とデータ予防措置が 重要だからです 皆さんも 統計を分析して 制約を理解し伝えることが重要です
誤りは様々です 機械学習で精度100%のモデルは ほぼありません 最初はあらゆる制約を理解できなくても やむをえませんが 徐々に 何が可能で何が不可能かを 理解していく必要があります 誤りが起きても 諦める必要はありません 誤りを理解すれば対処可能です 新しいモデルを作って 製品を改良するか 技術的制約を明示するのです
指標は 求める価値観の 代用物にすぎません 指標での評価は数値化されるため その向上にとらわれがちです しかし真に見るべきは抽象概念です 良い体験 顧客満足 強いブランドといった概念は 評価が困難です 代用物としての指標を理解するため App Storeの例を見ましょう
App Storeは ダウンロード歴を機械学習して 新しいAppをすすめます 最初はAppの消費時間が 基準となるかもしれません 時間を費やすのは好きだからですよね
App Storeが 指標とモデルのみで動くなら 使用中のAppに似たAppが すすめられるでしょう 私はゲーム好きなので ゲームばかりすすめられます そのおすすめに当面は満足できても 他のAppも気になり 次第に不満が募るでしょう 人の関心や好みは様々です 消費時間が評価を示すとは限りません
App Storeの エディトリアルコンテンツは 様々なAppや体験を探るのに役立ちます おすすめだけ見ていては 気付かないでしょう つまり指標やおすすめの制約に 対処する1つの手段です ただ 製品を展開し 顧客のニーズを知るにつれ 焦点も変わります
指標も改良しましょう 例えば多様性を指標に織り込みます 多様なコンテンツの消費を測定でき Appの特質と多様性のバランスを取る モデルを作れます もちろん焦点を追うことが前提です 良い体験 顧客満足 強いブランドを 判断できる指標であるかの― 検討が必要です
これを日々実践します
誤りの理解に努めましょう 様々な誤りを カテゴリとシナリオに分類すれば 各シナリオの重要性が分かります デザイン向上など 機械学習でない対処と モデル改良のどちらが必要かを 判断します
誤りのシナリオをデザインします 体験がうまくいく場合だけを 想定しては駄目です 失敗も想定してください 顧客の立場を重視するのに役立ちます
体験の評価に時間をかけましょう 指標で モデルの 客観的な性能が分かります モデルは体験ではありません 実際に経験するのが体験です その体験を評価します ユーザ調査 デモの構築 顧客との対話 フォーラムの閲覧 体験が悪いのに指標が良いなら 指標の誤りでしょう 体験は同じなのに 指標が向上しているなら 指標の誤りでしょう
指標は改良が必要です 現在の指標を過信せず 批判眼を持って 有効性を随時評価しましょう
結局は指標が価値観を表します 指標を価値観にマッチさせたいなら 入念に 批判的に 継続的に 評価の実態を検討しましょう
お話ししてきた指標は モデルを評価する手段でした
次はインターフェイスです モデルのデザインのカギは指標ですが モデルのインターフェイスも 検討する必要があります 入出力の話は ルビーとキャスに委ねましょう ありがとうございました (拍手)
ケイアが示したように 体験を作る時 機械学習システムの 構成要素は多々あります 対話を担うインターフェイスも デザインする必要があります
インターフェイスは モデルの結果を 人間用の出力に変換します 対話からのフィードバックは 体験を改良する入力になります
Human Interface Guidelines (HIG)から 入出力のパターンを用意しました キャスと私が説明しますので 参考になさってください
まず出力の話です 出力は予測にとどまりません 体験を文脈に合うシームレスなものに 改良できる媒体です 4タイプを見ていきましょう
複数選択肢は多様な出力を提示できます
属性は Appの判断方法を 分かりやすく説明できる概念です
信頼度は出力に対する確かさです
制約は ユーザの想定する機能と 実際の機能が 食い違う時に発生します
まずは複数選択肢です
複数選択肢は 機能の結果の中から ユーザが選べるものです この意味とは?
最善の選択肢だけ提示した場合は大抵 最善の体験にはなりません 実例を見ましょう 私は先週 遠出したくなり サンフランシスコからナパへの経路を 同僚に尋ねました
尋ねた相手と時期によって 答えは変わります I-80号線と言われたり 101号線と言われたりするでしょう
経路予測は 絶えず変わる変数が多く 複雑だからです 渋滞 工事 交通事故などですね
マップはそれらを考慮して 最善の経路を予測しますが 単一の選択肢では時に不十分です ある人の好みすべては把握できません 眺めの良さ 通行料の有無 ハイウェイか否かなどです
多様な経路を提供すれば ユーザは モデルの予測に 自分の好みを加味できます この例の経路は ノースベイ経由が1つ イーストベイ経由が2つあり ユーザは経路の選択権を得られます
可能なら常に 多様な選択肢を ユーザに示しましょう
マップを移動中に使う場合 選択肢が似すぎていると 経路を素早く選べません 属性を用いれば 選択肢を区別しやすくなります
この例では 通行料の有無や
道路名を示します
経路をハイライトするので 海辺で眺めが良いかも簡単に分かります
こうした情報は有用です ユーザは 幅広い選択肢を区別しやすくなり 選択が容易になります
マップが選択肢提示の好例なのは 入力が明確だからです 現在地と目的地が明らかで 複数選択肢も期待できます
複数選択肢は 予測提案機能にも役立ちます つまり意図や文脈が もっとあいまいな場合です
時計の例を見ましょう 私は毎朝 天気を確認したり
予定を見たりします
リマインダーも見ます Siri文字盤では 最大19のデータソースから 情報を得られます 天気 カレンダー リマインダーなどです サードパーティ製Appも選択できます 19のAppからの情報を 小さな画面で見るのは大変です そこでSiriは 見せる選択肢を 時間 場所 対話履歴を基に 絞ってくれます
私は朝 自宅にいる時は 特定の時間に電気をつける選択肢を いつも選びます なので毎朝それがトップに現れます
Siriが私の使用歴を知り この日課を助けてくれるので 起きがけに 膨大な選択肢を見ずに済みます
私のように朝の苦手な人は 朝の苦労が減りますね
ユーザが選択肢を選ぶたびに 暗黙的フィードバックが与えられ それを使えば 最適な選択肢を 常にトップにできるのです
選択を学習すれば 徐々に提案も向上します
マップの話をした際
属性が経路の区別に使えましたね
属性はもっと多用途です
属性は Appの判断方法を 分かりやすく説明できる概念です
App Storeでは 属性をおすすめの説明に使っています 提案の仕組みや ユーザデータの用途を 理解しやすくするためです
料理Appをダウンロードすると 提案が出るとします 料理Appをダウンロードした人が 料理好きとは限りません
そのAppが好きとも限りません
よって提案を属性で説明する時は 好みより客観的事実を述べるべきです こちらは単に“NYT Cookingの ダウンロードに伴う提案”としています
人の好みは 変わる可能性があるので 完全には把握できません アカウントが 共有されている場合もあるため 好みをプロファイルすると ユーザは戸惑います
ユーザの感情や好みを 把握したかのような言葉は 使うのを避けるべきです
属性は 結果の信頼性を示すのにも 役立ちます 天文マニアの私は 今夜見える惑星を知りたくなり いつ木星が見えるかSiriに聞きました
するとWolfram Alphaをソースとして 時刻以外の情報も教えてくれました
Wolfram Alphaは 有名な知識エンジンなので 信頼できる予測と思えます この機能が特に重要なのは ソースの信頼性が求められる時です 科学情報や選挙結果などですね
ソースを示せば ユーザは予測の信頼性を判断できます
属性はパーソナライゼーションや 予測の説明にとどまらず 信頼度の伝達にも使えます
App Storeで難解な表現を 避けている例を見ましょう
このように “85%一致”と表現したのでは どういう意味かよく分かりません 数値の捉え方も人それぞれです
そこでApp Storeでは “ダウンロードに基づく提案”のように 説明しています
“85%”は信頼度で ユーザが提案を 気に入る確度が85%という意味です モデルから得た信頼度の数値を ユーザに分かりやすい形で 伝えることが重要です
数値をそのまま使う時もあります 天気Appを見ると 雨予報だけでなく降水確率も分かります
“降水確率30%”と聞いた人は どう判断すべきでしょうか 傘を持参するべきか?
それは不確かですが 経験的に判断できます
数値の提供は 天気 スポーツ 選挙といった 統計的予測には適しています しかし適さない予測もあります
これは Hopperという 航空運賃予測Appです 運賃変動の予測を信頼度で示します この場合 確率を出しても ユーザは解釈に苦しむでしょう
“65%の確率で運賃が下がる”と 言われて動けますか? 70%との違いもよく分かりません
Hopperは信頼度を 取るべき行動の形で提示します 待つか買うかの提案です
節約できる費用や 最適な予約時期も教えてくれますので
ユーザは 情報に基づいた判断ができます
信頼度を適切に用いれば 体験を人間的なものにできます
信頼度は ユーザが判断しやすい 言葉にすることが大半です
信頼度が 判断のリスク見積もりに役立つことを ご理解いただけたと思います
例外もあります 例えば サンフランシスコまでの 所用時間を尋ねたとします “信頼度72%で1時半に着くよ”と 答えられたら 戸惑うでしょう 実際の帰宅時間を知るには?
予測を範囲で示すとベターです 相乗りの場合は 同乗者が増えたりするため 正確な到着時間は なかなか示せません
Lyftは 予約前に 到着時間を見積もれるAppです 範囲の形で 顧客の乗車開始時間と
空港到着時間を示します これなら私も 実際の帰宅時間を予想できます
範囲は判断のリスク見積もりに 役立ちます
以上は信頼度の示し方の好例です では信頼度が低く 行動を取るのに十分な情報がない時は?
大抵 ユーザの助けを借りられます
例えば Photosは 写真を検索しやすくするため 人を自動認識できます
認識の信頼度が低い場合は ユーザに その人の 別の写真を見せて確認します
確認は重要です 別人の写真が私だとタグ付けされたら 困るからです
タグ付けするたび Photosの私の認識精度が上がります
これは Photosにおける 顔認識の制約の一例で
出力の最後の話にも重なります
制約とは何でしょうか 制約は ユーザの想定する機能と 実際の機能が 食い違う時に発生します
私が“Photosは常に私を 認識できる”と期待しても 写真がぼやけていたり 暗かったりすれば無理です
機能にはデザイン 性能 環境から来る 制約があります
Appを信頼してもらうには 制約を認めて 対処法を示す必要があります
ミー文字は私の好きな機能ですが 実は うまく動作しない状況があります
顔が見えない時
カメラが塞がれている時
周りが暗い時です
この制約が発生するたび インラインでヒントを示し Appがユーザの対処を支援します
すると ユーザは同様の状況を 予防できるようになるのです
制約に適切に対処しないと 機能への信頼が揺らぎます 機能に対するユーザの期待を把握して 制約への対処法を示しましょう
制約へのもう1つの対処法は 代替手段を示すことです
この場合 目的を十分理解して 適切な代案を示す必要があります
例えば SiriにMacの タイマーのセットを頼むと macOSにはタイマーがないため Siriは実行できません
単に“できません”と答えると ユーザが困惑するので Siriはリマインダーを提案します 適切な提案ですね Siriは 特定の時間に通知が 欲しいという目的と リマインダーがそれを 果たせることを分かっているのです
可能なら 目的を果たせる代案を 示しましょう
以上の話が 機械学習モデルの出力の 参考になれば幸いです
出力はデザインの媒体です 出力のタイプを理解しましょう そうすれば モデルの標準出力だけに頼らず 作りたい体験に沿う出力を選べます
分かりやすく有用な出力にして ユーザの労力と時間を 節約しましょう
出力をインターフェイスで 見せる方法はいろいろあります
出力は 静的ではなく動的で 入力に応じて変化します
入力はユーザが行いますが キャスがそのデザインを説明します ありがとうございました (拍手)
ルビーは ユーザとの対話に使われる 出力を紹介しました その対話から得られる フィードバックは入力として 体験の改良に使えます この4つを説明します
キャリブレーションは 体験の必須情報の取得に便利です キャリブレーション処理で 体験の対話から 重要な情報を得られるのです 明示的フィードバックは 結果について尋ねることで情報を得ます 修正は モデルの誤りを既知の インターフェイスで直せる機能です まずキャリブレーションです キャリブレーションとは ユーザが 必須情報を提供できる機能です 生体認証やユーザ環境に関する データ取得に使えます HomeCourtの例で説明しましょう HomeCourtは バスケットボール練習Appです カメラ映像を機械学習で解析して シュートの精度などを 割り出せるものです 人 ゴール コートを検知できるよう カメラの調整が必要ですが―
HomeCourtは それを素早く直感的に行います カメラをゴールに向けて 枠内に収めるとすぐ検知されるので シュート1本で準備完了 Appがシュートを数え始めます
注目すべきは人の作業が不要なことです ゴールを線で囲ったりする必要がなく ゴールの検知が正しいかも 尋ねられません 別角度からのシュートも不要です
キャリブレーションは Face IDの設定時にも 必須情報のみを得るために 使われています 顔を2回スキャンすれば設定が済み 以降は 眼鏡をかけても 髪型を変えても動作します
キャリブレーションは 素早く簡単な処理に努め 必須情報の取得に絞ります 極力 一度の実行で 済むようにしましょう
Face IDの設定はガイド付きです 開始画面で 顔をスキャンする必要性を明示し 仕組みとメリットを説明します
全工程で 顔周囲のこのラインによって 進み具合も表示
処理が行き詰まった場合は 先に進めるようガイドします 今の矢印は 見てほしい向きです
最後は 処理が済んだので 機能が使えると伝えます
キャリブレーションでは 導入 ガイド 確認を行いましょう
Face IDで集めた個人情報は プライバシー尊重のため 設定で編集・削除可能にしています
極力 ユーザによる情報更新を 可能にしましょう
Face IDは 1度の キャリブレーションで利用可能です 以降は眼鏡 帽子 スカーフを着けても 髪型が違っても 加齢で顔が変わっても動作します これはデザインの難関でした 随時 顔を 再キャリブレーションする方が 認識の継続は楽でしょう ですがユーザに負担がかかります そこで顔の情報を更新するため Face IDが使われるたびに 暗黙的フィードバックを取得します 入力の2つ目のパターンですね
暗黙的フィードバックは ユーザの対話から生じ モデルと機能の改良に使える情報です よくある例は パーソナライゼーションです 例えば SiriはiOSでの検索体験を デバイスの使い方で パーソナライズします
ホーム画面で“検索”をタップすると Siriは 使われそうなAppを提案 現れるAppは 暗黙的フィードバックで決まります ユーザが頻繁に使うAppや その時間帯によく使うAppなどです 例えば車内なら 道を確認するマップや 何かを聞くミュージックやPodcast 職場なら 会議で便利なメモやリマインダー 自宅なら メールを送れるメッセージや アクティビティ Newsなど
SiriがAppの使用傾向を基に 私の意図を酌み 役立ちそうなAppを提案するのです 暗黙的フィードバックを使う時は ユーザの意図を 対話傾向から酌みましょう
やがて Siriは意図の理解を深め 私がよく実行するアクションの ショートカットも提案し始めます 車内なら よく訪れる場所や 次の会議の場所への案内 職場なら 会議メモや リマインダーのショートカット 自宅なら 電気の点灯や 家族へのFaceTimeのショートカットなど
ショートカットが出るのは 数日後以降です Siriの把握が深まれば 提案が具体化します この提案は 暗黙的フィードバックによるものなので 多少の時間は必要です 無用な提案をすぐ行うより 確度が高まるのを待つ方が適切です
暗黙的フィードバックは 経時的な精度向上が期待できます
提案はロック画面にも出ますが 微妙な情報を含むかもしれません サプライズにしたいイベントや 内密のメモの情報です
そこで どのAppやショートカットを 検索に出すかを 設定できるようにしました
プライバシーを尊重し ユーザが情報の出し方を 制御できるようにしましょう
暗黙的フィードバックは あまり目立たない目的にも使えます 例えば 指示の速度や精度を 上げることです iOS当初からの好例はキーボードです
各キーのタッチエリアは 入力履歴を基に 機械学習で最適化しています
各タッチエリアの大きさを 入力中の言葉や 指の配置によって変えるのです
見た目には キーの大きさは変化しません キーボードは不変に見えますが 徐々に タイピングの精度が向上し パーソナライズされます
暗黙的フィードバックで 対話の質を上げられるわけです
最後の例は SafariにおけるSiriの提案です Safariは 機械学習でリンクを集めています 収集元はメール iCloudタブなどです こうした提案が 興味深いコンテンツの発見に 役立てば幸いです ただ時には 不要な提案もあるでしょう 関心のない記事や 信頼しがたいソースの場合です どの提案も役に立たないと 提案だけでなくSafariへの信頼も 薄れるかもしれません それは避けたい事態です ルビーの属性の話で 提案を示す理由が分かりましたね ユーザが提案を制御して 不要なものは停止できる必要もあります それが次の明示的フィードバックです
これは Appが結果について尋ねることで 情報を得られる機能です
前の例では 不要な提案に関する フィードバックを得て 似た提案をやめるよう モデルに学ばせたいですよね そのアクションのデザインとは?
これは明示的フィードバックで よく登場する2つのアクションです ただし このボタンを見るだけでは たとえラベルがあっても タップしてどうなるかが不明です
3つ目の記事への反応を得たいとします メニューに アクション“Love”がありますが
好きな記事全部に 行う必要があるのでしょうか 正の明示的フィードバックは 労力を伴う印象を与えます 提案向上のためだけなら負担でしょう よって 負のフィードバックを 優先することをお勧めします 正のフィードバックは 記事を読む ブックマークする 共有するなど― 暗黙的な方が適切です
Loveはやめて“Dislike”だけ 出すのが良さそうですが それでも意味はあいまいです ある記事が嫌いな場合 内容 著者 ソース 送り主 受け取ったAppのどれが嫌いか? Dislikeをタップしてどうなるかも 不明です
“提案を弱める”や “提案を隠す”の方が 実行するとどうなるかが 分かりやすいですね 不要な提案を ユーザがもっと制御できるよう 送り主や受け取ったAppを 選択可能にしてもいいでしょう
明示的フィードバックでは 選択肢と結果を 明確な表現で示してください 可能なら 様々な選択肢によって 好みを把握しましょう
選ばれた選択肢は インターフェイスにすぐ反映し 設定された提案を隠すべきです
明示的フィードバックには 即座に持続的に対応しましょう
ユーザは 明示的フィードバックで 不要な提案を制御できます しかし機械学習には 明示的フィードバックが 不適または不可能な機能もあります 再びアンジーを例にしましょう このイヌはよく話題になります
キーボードは機械学習で 入力の修正を提案します 私が“angie”と入れると “angle”が修正候補に出てきました 誤った提案ですが 明示的フィードバックするのも 不自然です コンテクストメニューを出します しかし一見どういう意味か よく分かりません そこで単語を選択して 入力し直すことで提案を修正しました すると今度は自動修正されません キーボードが私の修正を学習して 次回は“Angieはangleの 誤りではない”と判断するのです これは最後のパターンの 分かりやすい例です
修正は モデルの誤りを 既知のタスクで直せる機能です 既知のタスクを説明します 先ほどのこの例では 標準のテキストコントロールで 修正を行いました 新しいインターフェイスではなく キーボードによる 誰もが知っている方法です 修正は 手間を感じさせずに 結果を最適化する点で優れています
別の例を見ましょう Photosは機械学習で最適化を行い 写真の回転やトリミングを支援します Photosが提案する 回転やトリミングは微細です 編集モードで該当ツールを選ぶと Photosが回転やトリミングを行います 最初は 実際にはトリミングなどをせず 提案するのみです ユーザが提案を気に入り 完了をタップすると 適用されます 提案に変更を加えたい場合は 枠線をドラッグして トリミングなどを行います こうして通常のコントロールを示し ユーザの修正から学ぶのです
最後のパターンでした 既知の方法を介せば 簡単に素早く直せます 修正はすぐ反映させましょう テキスト修正の例では 自動修正がなされなくなりました 修正は 機械学習において 結果を向上させる 優れた暗黙的フィードバックです
インターフェイスの説明でした 以上のパターンの多くは 従来の インターフェイス要素を活用します つまり機械学習は 従来の動作を引き上げるものです パターンは新旧あっても 適用されるのは新しい文脈です パターンを選ぶ時は ユーザの作業を尊重しましょう 属性やフィードバックアクションを 追加すると ユーザの解釈する情報が増えます 作業への注意が損なわれかねません まずユーザを念頭に置いてください
機械学習体験のデザインは インターフェイスでの出力に限りません データ 指標 入力 出力の選び方が 体験を分かりやすく直感的で 快いものにするために大変重要です
冒頭のケイアの話に戻って 終わりましょう Appleは 機械学習を使って 従来不可能だった念願の製品や体験を 作り出しています 例を見たように 機械学習は集中力管理や 優れたレコメンド 文脈情報のタイムリーな提示に有用です 日常的なタスクの自動化にも役立ちます 機械学習の用途はもっとあります Appleは テクノロジーを活用してきましたが 機械学習はその力を高めるのです
アクティビティを測定して健康管理
コミュニケーションで インクルーシブを促進 例えば カメラに音声操作機能を加えると 目の不自由な人に役立つでしょう
心拍などを測定して心臓の問題を検知 安全な暮らしを支えます
そして 斬新な視点から創造を促します ペンシルで画面に スケッチできる機能などです
創造の仕方と価値観がマッチした時 人間の可能性を高める体験を作れます
本セッションは以上です 機械学習体験のデザインの 参考になれば幸いです お話ししたパターンはすべて HIGに載っています
機械学習関連のイベントは まだいくつかあり 私たちはUser Interface Design Labで 質問をお受けします ぜひお立ち寄りください ご参加ありがとうございました (拍手)
-
-
特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。
クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。