Human Interface Guidelinesの機械学習の章を翻訳してみる(#03 出力篇)
これは何？
今年夏にHuman Interface Guidelinesに追加された機械学習の章を個人で翻訳したものの第3回です(全3回)。
今回は機械学習で得られた結果をどうユーザーに向けて表現(出力)するかについての部分を翻訳していきます。
なお「#01 導入・原則篇」「#02 入力篇」についても、合わせて読むと理解がはかどると思います。自分にとって必要だと思う部分を、かいつまんで読んでみてください。
翻訳の方針(再掲)
あくまで公式の日本語訳がない中個人的に翻訳したものですので、その点ご理解いただいた上でご覧ください。公式の日本語ソースが出た場合などは削除します。
翻訳についてはプロではないので、原文に忠実に翻訳を心がけ、意味が取りづらい部分については大意を損ねない程度に意訳しています。
それでもわかりづらい部分あるかと思うので、英語大丈夫な方は原文を読んでいただくのが一番かと思います。
もし誤訳があったり、こう訳したほういいのでは？というのを発見した方はご連絡いただけるとありがたいです。できる限り対応します。
以下から翻訳です。
間違い
アプリが間違いをおかすことは避けられません。人は完璧こそ期待していませんが、アプリが間違いをおかすことは体験を毀損しますし、アプリに対する信頼を下げる恐れがあります。マイナスの結果を避けるには、次のことが重要です。
・間違いを予測してください。できる限り、間違いを回避し、発生した場合にそれらを軽減する方法を設計してください。
・人が間違いに対処するのを助けてください。間違いはさまざまな結果をもたらす場合があります。それゆえ間違いに対処するためにあなたが提供するツールは、当然それらの結果に対処できる必要があります。
・アプリを改善するときに間違いから学んでください。場合によっては、間違いから学習すると、ユーザー体験が予測不能になるなど、望ましくない影響が生じる可能性があります。理にかなっている場合は、それぞれの間違いをデータポイントとして使い、機械学習モデルを改良し、アプリを改善することができます。
アプリが間違いに対処するのに役立ついくつかの機械学習パターンがあります。
・制約は、提案がどれだけ正確かについて人の期待を調整するのに役立ちます。
・修正は、たとえ結果が間違っていてもうまくやるための方法を提供します。
・根拠は、提案が何に基づくのかの洞察をもたらし、間違いを理解するのに役立ちます。
・確信度は、結果の品質を評価するのに役立ち、結果をどう表示するかに影響を与える可能性があります。
・明示的・暗黙的の両方のフィードバックによって、ユーザーは、あなたが気付かないかもしれない間違いについて教えてくれます。
間違った結果として起きることがいかに深刻かを理解してください。
たとえば、間違ったキーボードの提案は人を悩ませるかもしれませんが、逃したフライトをもたらす旅行ルートを提案することは、深刻なほどに不便です。間違いの深刻さに適した是正措置やツールを提供することで、ユーザーに共感していることを示してください。
頻繁に発生する間違いや予測可能な間違いを簡単に修正できるようにしてください。
間違いを簡単に修正する方法を提供しないと、アプリに対する信頼を失う恐れがあります。
絶えず機能を更新して、人の進化する興味や好みを反映してください。
ユーザーの理解を深め、間違いを避けるための1つの方法は、暗黙的なフィードバックを使って、ユーザーの好みや習慣の変化を発見することです。また、人気のあるエンターテイメントの現在の傾向など、ドメイン固有の情報で機能を更新する必要があります。理想的には、アプリの改善によって恩恵を得るために、ユーザーが仕事をしなくてもよいものです。
できれば、UIを複雑にすることなく間違いに対処してください。
修正や制約などの一部のパターンは、アプリのUIとシームレスに統合される傾向がありますが、根拠などのその他のパタ ーンは統合が難しいことがあります。 UIに対するパターンの効果と、間違いを悪化させる可能性のバランスを取ってください。たとえば、間違った根拠に基づいてUIを更新すると、元の間違いの影響が助長されてしまいます。
先回り的な機能における間違いを避けるよう、特に注意してください。
ユーザー行動に基づいた提案などの先回り的な機能は、ユーザーに何かをするよう頼むことなく、価値のある結果を約束します。ただし、先回り的な機能は求められないため、多くの場合、その間違いに対する忍耐力が低下しがちになります。先回り的な機能による間違いは、自分がコントロールできないと感じさせてしまうこともあります。
ある領域の間違いを減らすことに取り組むときは、それが他の領域と全体の精度にどのような影響を与えるか常に考慮してください。
たとえば、画像認識アプリを最適化して犬の認識方法を改善すると、猫の認識能力が低下する可能性があります。モデルが進化するにつれて、進化する間違いにも備えてください。ユーザーの好みについて知っていることを使って、注力する領域を決めるのに役立ててください。
複数の選択肢
機能の設計によっては、ユーザーが選べる形で単一または複数の結果を示すのが最適になる場合があります。 複数の選択肢を提供することで、単一選択肢の場合よりユーザー自身がコントロールしている感覚をもたらすことができ、モデルの予測とユーザーが実際に望むものとの間のギャップを埋めることができます。 複数の選択肢により、アプリがどのような類の結果をもたらすのかについて現実的な期待を抱かせることもできます。
複数の選択肢をユーザーに示すのは、たとえば次のような文脈においてです。
・推奨される選択肢、つまりユーザーとの過去のやりとりに基づいてコンテンツを提案する、先回り的な機能。 たとえば、Apple MusicのFor Youのレコメンデーションです。
・要求に基づく選択肢、つまり最近の行動に基づいて、ユーザーに次のステップを提案する受身的な機能。 たとえば、Quick Typeの提案です。
・修正。これは、アプリがユーザーに代わって行動しているときにおかした間違いを修正するために、ユーザーがとる行動です。 たとえば、Photosの自動切り抜き機能です。
単調な選択肢より多様な選択肢をよしとしてください。
できれば、回答の精度と複数の選択肢の多様性のバランスを取ってください。たとえば、Apple Mapsは一般に、通行料のないルート、風光明媚なルート、高速道路を使用するルートなど、目的地への複数のルートを提案します。様々なタイプの選択肢を提供することで、ユーザーは好みの選択肢を選択することができ、興味のある新しいアイテムも提案できます。
一般に、あまりに多くの選択肢を示すことは避けてください。
人は選択をする前にそれぞれの選択肢を評価する必要があるため、選択肢を増やすと認知負荷が増加します。できれば、1つの画面に選択肢をリストして、正しいものを見つけるためにスクロールする必要がないようにします。
最もありうる選択肢をリストの最初に並べてください。
確信度が結果の質とどのように関係するかがわかったら、それらを使用して選択肢をランク付けすることができます。最もありうる選択肢を判断するために、時刻や現在地などの利用文脈の情報を使うのを検討することもあるでしょう。アプリにおいて意味がある場合は、デフォルトで最初の選択肢を選んで、すべての選択肢を読み通さずに目標をすばやく達成できるようにしてください。
選択肢を簡単に区別したり選べるようにしてください。
たとえば、経路案内アプリでは、多くの場合、間違った方向に進むことを避けるために、ルートをすばやく選択しなければいけません。選択肢が似ているように見える場合、各選択肢の簡単な説明を提供し、違いを強調するように特に注意を払うことで、人がそれらを区別できるようにします。コンテンツの推奨など、1つのビューに表示するには選択肢が多すぎる場合は、ユーザーがすばやく認識できるカテゴリに選択肢をグループ化することを検討してください。
ユーザーの選択が理にかなう場合は、その選択から学んでください。
ユーザーは、選択するたびに暗黙的なフィードバックをアプリに提供します。ユーザー体験に悪影響を与えない場合は、このフィードバックを使用して、提供するオプションを改善し、最もありうる選択肢を最初に提示する機会を増やします。一般に、誤った結果を提供し続けると、アプリの予測の質に対するユーザーの信頼が下がるおそれがあります。
確信度
確信度は、結果がどれだけ確実かの尺度を示します。すべてのモデルがデフォルトで確信度を出せるわけではないので、アプリのユーザー体験を改善するために使用できる場合は、確信度を出すことを検討しましょう。
確信度が高いと結果の質が向上し、ユーザー体験が向上するように思えるかもしれませんが、必ずしもそのように機能するとは限りません。確信度が結果の質に対応していることを示す必要があります。 たとえば、複数の確信度の閾値を確認したり、アプリの複数バージョンで値を比較したりできます。 確信度が結果の質とどのように関係しているかわからない場合は、それをユーザーに伝えるのは得策ではありません。
確信度をどう表示するか決める前に、確信度の意味を理解してください。
たとえば、特に結果に根拠やその他の文脈情報が付随している場合、補完的な機能による低品質の結果であれば許されますが、低品質の結果を目立つ形で示すと、アプリの信頼を損なう恐れがあります。
一般に、確信度を、ユーザーがすでに理解している概念に変換してください。
確信度を表示するだけでは、それが結果とどう関連するかわかるのに必ずしも役立ちません。たとえば、ユーザーの聴く習慣に基づいて新しい音楽を提案する機能では、新しい曲とユーザーが聴く曲との間に97％の一致があると計算される場合があります。ただし、根拠として新しい曲の横に「マッチ度97％」を表示しても、ユーザーが選択するのに十分役立つような情報を伝えることはできません。対照的に、ユーザーの行動にはっきりと基づいた根拠（「ポップミュージックを聴くから」など）を提供すると、より実用的なものになります。
根拠が役に立たない状況では、確信度を示唆するやり方で、結果をランク付けまたは順序付けすることを検討してください。
確信度を直接表示する必要がある場合は、セマンティックカテゴリの観点で表現することを検討してみてください。たとえば、旅行料金を予測する機能は、確信度の範囲を「高確率」や「低確率」などのカテゴリに置き換えて、値に文脈を与え、人が結果を理解して比較できるようにします。
人が統計情報または数値情報を期待するシナリオでは、結果の解釈に役立つ確信度を示してください。
たとえば、天気予報やスポーツ統計やおよび投票数には、多くの場合、信頼区間やパーセンテージという形でデータ精度を表す特定の値が伴います。
できる限り、実用的な提案になるかどうかの観点で確信度を伝えて、ユーザーの意思決定を支えてください。
人の目標を理解することは、意思決定に役立つやり方で確信度を表現するための鍵です。たとえば、アイテムが最低価格になる時期を予測する場合、時間とお金をどのように使うか最適化したいとユーザーが考えていることがわかります。このような機能の場合、パーセンテージやその他の確信度の数値を表示することは、「これは購入に最適な時期です」や「より良い価格を待つことを検討してください」などの実用的な提案を提供するよりも価値がないでしょう。
さまざまな確信度の閾値に基づいて、結果をどう表示するかを変えることを検討してください。
確信度の高低が、人を結果をどう受け止めるかに大きな影響を与える場合、それに応じて見せ方を調整することをおすすめします。たとえば、確信度が高い場合、Photosの顔認識機能は特定の人物を含む写真を表示しますが、確信度が低い場合、この機能は、写真に人物が含まれているかどうかをまずユーザーに確認してから表示します。
確信度が結果の質に一致することがわかっている場合、通常は、確信度が低いときに結果を表示しないようにしてください。
特に機能が先回り的であったり、求められてないような提案をしかねない場合、結果が悪いと、ユーザーがイライラしたり、機能に対する信頼を失うことさえあります。提案と先回り的な機能については、それ以下では結果を提供しないという確信度の閾値を設定することをおすすめします。
根拠
根拠によって、機械学習モデルの仕組みを正確に説明しなくても、何が結果のもととなっているか表現できます。 アプリのデザインによっては、根拠を使うことでアプリの透明性を担保し、結果からユーザーが気づきを得られるようにするでしょう。 たとえば、アプリがユーザーが読むべき本を提案している場合、「スリラー」というカテゴリの本を提案するときに「ミステリーを読んだから」などの根拠を使うことできます。
根拠をアプリに含めるかどうかを判断しやすくするため、それがどのようにユーザーに影響するかを考えてください。 たとえば、根拠に次のようなことを期待しますか？
・アプリ内での行動を変えるようユーザーに促すこと
・間違いの影響を最小限に抑えること
・アプリの機能のメンタルモデルを形づくる手助けをすること
・時間とともにアプリの信頼が高まるよう促すこと
ユーザーが結果を区別できるように、根拠の表示を使うことを考えてください。
たとえば、一連の結果を、根拠を含む複数の選択肢として示すと、「読んだ著者による新しい本」など、その結果をもたらした前提条件をわかった上で選択肢を吟味しやすくなります。
具体的すぎる、または一般的すぎることを避けてください。
過度に一般的な根拠を示すことは通常、役に立つ情報を提供しません。過度に具体的な根拠を示すこともまた、結果を解釈するために追加作業をする必要があると感じさせてしまいます。コンテンツのレコメンデーションを行うアプリでは、一般的な根拠によって、アプリが自分のことを個人として扱っていないように感じることがあります。他方、特定の根拠を示しすぎることによって、アプリが自分のことをあまりにも注意深く見ていると思わせてしまいかねません。最高の根拠は、これらの両極のバランスを取ります。
根拠は常に事実に基づいたものとし、客観的な分析に基づいたものとしてください。
根拠がユーザーにとって役に立つものであるためには、ユーザーが結果について理性的に考えやすいようにし、逆に感情的な反応を起こさないようにするのが望ましいです。ユーザーの感情、好み、または信念を理解したり判断したりしていることを意味する根拠を、ユーザーに示さないでください。たとえば、新しいコンテンツをユーザーにレコメンドするアプリでは、「ノンフィクションが好きだから」などの根拠を示すのではなく、「ノンフィクションを読んだから」などの根拠を用いるべきです。
一般に、専門的または統計的な専門用語は避けてください。
ほとんどの場合、パーセンテージ、統計、その他の専門用語を使用しても、ユーザーが結果を評価する上で役立ちません。この例外は、たとえば気象・スポーツ・投票や選挙の結果といった分野における情報、すなわち科学的なデータのように、結果自体が統計的または専門的な性質を持つ場合です。
制約
機械学習に基づいているかどうかにかかわらず、すべての機能には、提供できるものに特定の制約があります。 一般に、制約には2つのタイプがあります。機能がうまく働かないことと、機能がまったく働かないことです。 機能に対するユーザーの期待と、機能が実際に達成できることとの間に不一致がある場合、その制約によって機能には欠陥があるように見える恐れがあります。 たとえば、ユーザーは次のように考えるかもしれません。
・Photosは、想像できるすべてのカテゴリをカバーして検索を行ってくれる
・Siriは、「人生の意味は何ですか？」など、明確に定義されていないクエリに応答してくれる
・Face IDは、あらゆる角度からでも使える
設計プロセスの重要な部分は、制約がユーザー体験に影響を与えるシナリオを見定め、ユーザーが制約の中で振る舞いやすくする方法を設計することです。 たとえば、次のようなものです。
・ユーザーが機能を使う前に、期待を調整してください。
・ユーザーが機能を使っている間に、最高の結果を得る方法を示してください。
・だめな結果が出た場合は、その理由を説明して、ユーザーが機能のことをもっとわかるようにしてください。
ユーザーが現実的な期待を持てるようにしてあげてください。
制約がユーザー体験に深刻な影響を与える恐れがあるものの、それがまれにしか発生しない場合は、ユーザーにアプリまたは機能を使うに制約を知らせることを考えてください。マーケティング資料または機能の文脈の中でその制約について説明し、ユーザーがどのように機能をあてにしたいか、みずから決められるようにします。制約の影響が深刻でない場合は、根拠を示すことで、ユーザーが期待を調整するのに役立てることができます。
一番良い結果を得る方法を示してください。
機能を使うためのガイダンスを行わない場合、ユーザーはその機能でなんでもできると考えてしまうかもしれません。優れた結果を得る方法を先回りで示すことで、ユーザーがその機能の恩恵を受け、その機能に何ができるのか、より正確なメンタルモデルを持つことができます。機能の一番良い使い方を示すやり方はいくつもあり、たとえば次のようなものがあります。
・プレースホルダーテキストを使用して、入力を提案してください。Photosでは、検索バーに「写真、人物、場所...」というテキストが表示され、入力をはじめる前に、検索できる内容を理解しやすくしています。Photosには、写真ライブラリをスキャンして検索候補を提供する方法の説明も表示されます。
・ユーザーが機能を操作するとき、行動についてのフィードバックを提供し、驚かせることなく結果に導いてください。たとえば、ユーザーがアニ文字と対話している間、この機能は現在の状況に反応していて、照明を調整するかカメラに近づくことによって結果を改善するやり方を示しています。
・結果なしを表示する代わりに、ユーザーの目標を達成する代替手段を示してください。これをうまくやるには、ユーザーの目標を十分に理解して、意味のある代替手段を提案する必要があります。たとえば、Macでタイマーを設定するようにSiriにお願いする場合、タイマーはmacOSでは使用できないため、Siriは代わりにリマインダーを設定することを提案します。 Siriはユーザーの目標が特定の時間にアラートを受信することであると理解しているため、この提案は理にかなっています。
制約がどのように不満足な結果をもたらすかを説明してください。
アプリの機能が場合によってうまく使えたり使えなかったりするように見えると、ユーザーはイライラしかねません。 理想的には、まずい結果となっている理由を認識して説明し、どのような制約があるかをユーザーにわかってもらい、彼らが期待を調整するのを助けることができます。たとえば、アニ文字は、暗闇ではうまく機能しないことをユーザーに伝えています。
**制約が解決されたときにはそれをユーザーに伝えてください。 **
ユーザーが頻繁に機能を使うとき、機能の制約ゆえ失敗してしまうようなやりとりを避けることを学びます。 アプリを更新して制約を取り除いたときには、ユーザーに通知して、機能のメンタルモデルを調整し、以前にユーザーが回避したやりとりに戻れるようにしてあげてください。
以上でHIGの機械学習にまつわる章の翻訳はおわりです。
不正確な部分・意味のとりづらい部分もあるかと思うので、ぜひご指摘いただけるとありがたいです。
twitterのDM開放しています。
翻訳をやってみて
普段AIプロダクトをデザインする中で強く感じているのが、「AIとどう向き合って良いかよくわからない」人が圧倒的に多いことです。
とはいえ、「AIにまったく触れたことがない」と言っている人でもiPhoneのFace IDは使いこなしているはずですし、多くの人にとって、撮影した写真を完全手動で分類する世界に戻るのは嫌なはずです。
「AI」とあえて口に出すと身構えてしまいそうですが、結局のところ、それを使った体験自体は皆なんらかの形で既に享受しています。
「AIと向き合う」のでなく「AIと融ける」ことを意図したプロダクトは確実に存在していますし、ヒトと機械の関係性は明らかに今後のあるべき姿といえます。
その意味で、今年になってからAppleがHIGの中に機械学習の章を追加し、GoogleがPeople + AI Guidebookを出したのは個人的にはかなり面白いなと感じています。
AI(機械学習)に何ができるのか、逆にヒトに何ができるのかをわかった上で設計することは、本来的にはデザイナーの責務でもあるはずです。
いち個人としては、このあたりをまるっとデータサイエンティストなどに丸投げするでなく、デザイナーとして楽しみながら設計していきたいなと身が引き締まった翻訳でした。
HIGの私的翻訳については議論あるものの、十分公益に資するものとして今回公開した次第です。繰り返しになりますが、公式の日本語訳がない中、あくまで個人的に翻訳したものですので、公式の日本語ソースが出た場合などは削除します。その点ご理解いただいた上でご覧いただけるとありがたいです。
この記事が気に入ったらサポートをしてみませんか？