Human Interface Guidelinesの機械学習の章を翻訳してみる(#02 入力篇)
これは何？
今年夏にHuman Interface Guidelinesに追加された機械学習の章を個人で翻訳したものの第2回です(全3回)。
第1回の「#01 導入・原則篇」については以下をご覧ください。
翻訳の方針(再掲)
あくまで公式の日本語訳がない中個人的に翻訳したものですので、その点ご理解いただいた上でご覧ください。公式の日本語ソースが出た場合などは削除します。
翻訳についてはプロではないので、原文に忠実に翻訳を心がけ、意味が取りづらい部分については大意を損ねない程度に意訳しています。
それでもわかりづらい部分あるかと思うので、英語大丈夫な方は原文を読んでいただくのが一番かと思います。
もし誤訳があったり、こう訳したほういいのでは？というのを発見した方はDMなどでご連絡いただけるとありがたいです。できる限り対応します。
以下、早速翻訳していきます。
明示的なフィードバック
明示的なフィードバックは、アプリが提供するコンテンツと体験を改善するために使うことのできる実用的な情報をもたらします。暗黙的なフィードバック(アプリがユーザー行動から収集する情報)とは異なり、明示的なフィードバックは、アプリからの特定のリクエストに応じてユーザーが提供する情報です。
お気に入り(将来、アイテムに素早くアクセスするためのマーキング)や、ソーシャルフィードバック(他者に対する感情を表現するもの)は、一見して明示的なフィードバックを提供するメカニズムのように見える、一般的なやりとりです。ただし、これらのツールはアプリ固有の要求をサポートしていないため、意外かもしれませんが暗黙的なフィードバックを提供しています。人はお気に入りやソーシャルフィードバックを使用して自らの目標を達成し、アプリはこれらのやりとりから暗黙的なフィードバックを収集することができます。
必要な場合にだけ、明示的なフィードバックをユーザーに求めてください。
ユーザーは明示的なフィードバックを提供するために行動する必要があるため、できればそれを求めないことをおすすめします。代わりに、ユーザーに余計な作業を求めることなく、アプリをどう操作するか学習するために、暗黙的なフィードバックを使用することを検討してください。
ユーザーが明示的なフィードバックをアプリに提供するのは、常に自発的なタスクとしてください。
明示的なフィードバックは、それを提供することが必須だよとユーザーに感じさせることなく、体験を向上させるのに役立つことを伝えたほうがいいです。
肯定的フィードバック・否定的フィードバックの両方を求めないでください。
良い提案はフィードバックを必要としないものなので、ユーザーがいいねと思った結果すべてに肯定的なフィードバックを与えるべきだよとは示さないほうがいいです。 代わりに、ユーザーがいいねと思わない結果について否定的なフィードバックをする機会を与えて、体験を改善できるようにしてください。
シンプルで直接的な言葉を使って、明示的にフィードバックの選択肢を表し、それを選んだ結果として起きるかを説明してください。
「好ましくない」といった不正確な用語の使用は避けてください。そのような用語は結果を伝えず、翻訳が難しい場合があるためです。 代わりに、たとえば次のような選択肢を選んだときに何が起こるかをユーザーが理解できるよう、各選択肢に説明を施してください。
・もっとポップ・ミュージックを少なくする
・もっとスリラーものを多くする
・1週間、政治モノをミュートする
**理解の助けとなるのであれば、アイコンを選択肢の説明に加えてください。 **
アイコンは、オプションの説明の一部を明確にしたり強調したりするのに役立ちます。 アイコンを単独で使用することは避けてください。アイコンだけでは、粒度や結果を伝えるのに十分といえるほど明確ではないためです。
明示的なフィードバックをユーザーに求める場合には、複数の選択肢を提供することを検討してください。
複数の選択肢を提供することで、ユーザーに自分でコントロールできている感覚をもたらし、不要な提案を識別してアプリから取り除くのに役立ちます。 ユーザーがフィードバックしやすくするために、徐々に選択肢が具体的となるよう検討してください。そうすれば、ユーザーは自らの回答を明確にしやすくなります。
**明示的なフィードバックを受け取ったらすぐに反応し、結果を変更したことを保持してください。 **
たとえば、ユーザーが見たくないコンテンツを特定した場合、そのコンテンツはビューからすぐに消えるべきで、アプリの他のどこにも表示されるべきではありません。 ユーザーからのフィードバックにすぐ反応し、アプリがそれを記憶していることを示すと、フィードバックを提供することの価値に対してユーザーの信頼を得られます。
アプリが結果をいつどこで表示するかを改善するために、明示的なフィードバックを使うことを検討してください。
たとえば、ある結果がよかったとしても、特定の時間や特定のコンテキストではそれを見たくない場合があります。 結果をいつどこで表示するかについて明示的なフィードバックをユーザーに求めることは、アプリでの体験を微調整するのに役立ちます。
暗黙的なフィードバック
暗黙的なフィードバックとは、ユーザーがアプリの機能を操作するときに発生する情報です。 明示的なフィードバックから得られる特定の反応とは異なり、暗黙的なフィードバックはユーザーの行動や好みに関する幅広い情報をもたらしてくれます。 優れた機械学習アプリには暗黙的なフィードバックを組み込む必要はありませんが、フィードバックは、ユーザーに余計な作業をお願いすることなく、アプリのユーザー体験を向上させるのに役立ちます。
**常にユーザーの情報を保護してください。 **
暗黙的なフィードバックは潜在的に機密性の高いユーザー情報を収集する場合があるため、ユーザーのプライバシーを厳しく管理するよう特に注意を払う必要があります。
ユーザーが情報を管理できるようにしてください。
アプリ開発者は、アプリ内外の両方でユーザー行動を理解すればするほど、体験を向上できることを知っています。 ほとんどのユーザーは情報を複数のアプリで利用できることの利点を理解していますが、あるアプリで行ったことが別のアプリでの体験に影響を与えることには驚くかもしれません。 更に悪いことに、ユーザーは「アプリが自分の個人情報を共有している」と考える場合があり、その結果アプリに対する信頼が失われることもありえます。アプリが情報をどのように取得および共有するかをユーザーに伝え、情報の流れを制限する方法をユーザーに提供することが重要です。
**暗黙的なフィードバックにより、ユーザーが探索する機会が減らないようにしてください。 **
暗黙的なフィードバックはユーザーの行動を強化する傾向があり、短期的にはユーザー体験を向上させることができますが、長期的には悪化させる場合があります。 たとえば、現在時点でユーザーが興味のあるすべてのことと合致するよう一連の提案をすることは、一見良い考えのように思えるかもしれません。しかしながら、そうすることでユーザーは新しいことを探索しなくなってしまいます。
できれば、ユーザーからの複数種のフィードバックを使うことで、提案を改善したり間違いを軽減してください。
暗黙的なフィードバックは間接的なものであるため、収集する情報においてユーザーの実際の意図を識別することは困難です。 たとえば、誰かがある写真を見て、メッセージで共有し、共有アルバムに追加した場合、それは必ずしもユーザーが写真に肯定的な感情を持っていることを意味しません。 複数の情報源およびやりとりからの暗黙的なフィードバックを組み込んで、ユーザーの意図を誤解しないようにしてください。
プライベートな提案やデリケートな提案を差し控えてください。
多くの場合、ユーザーは自分のアカウントとデバイスを他のユーザーと共有したり、個人用の使用から共有用のものに切り替えたりします。 アプリがプライベートなトピックやデリケートなトピックに関する暗黙的なフィードバックを受け取った場合、そのフィードバックに基づいてレコメンドを提供することは控えてください。
最近のフィードバックに優先順位を付けてください。
ユーザーの好みは頻繁に変わるため、最近の暗黙的なフィードバックに基づいてレコメンドを決定するようにしてください。 たとえば、Face IDは、ユーザーの今の見た目を反映する可能性が最も高いため、最近の顔入力を優先しています。 最近のフィードバックが利用できない場合は、過去のフィードバックに遡っていくのがいいでしょう。
フィードバックを用いて、機能についてユーザーが持つメンタルモデルと一致するようリズムの予測を更新してください。
たとえば、ユーザーは入力中に入力候補がすぐに更新されることを期待しています。 一方、更新された歌のレコメンデーションを四六時中ユーザーにしてしまうと、個々の歌について考えることが難しくなり、急かされたり圧倒されたような気分を感じさせてしまいます。
アプリのUIを変更するときに、暗黙的なフィードバックの変更に備えてください。
わずかなUIの変更でさえ、暗黙的なフィードバックの量とタイプに顕著な変化をもたらす可能性があります。 たとえば、ボタンのアクションから得られる利益に変化がない場合でも、ボタンの位置を変更すると、その使い方に影響出る場合があります。 アプリの操作がもたらす暗黙的なフィードバックを解釈するときは、このような変更を考慮してください。
*確証バイアスに注意してください。 **
暗黙的なフィードバックは、ユーザーがあなたのアプリや他アプリで実際に表示したり実行できる内容によって制約を受けます。これにより、ユーザーがやりたいと思われる新しいことについて洞察が得られることはほとんどありません。 結果を知らせるために、暗黙的なフィードバックのみに頼りきることは控えてください。
* 訳注：確証バイアスは、仮説や信念を検証する際にそれを支持する情報ばかりを集め、反証する情報を無視または集めようとしない傾向のこと。認知バイアスの一種。
キャリブレーション
キャリブレーションは、アプリの機能を使う前に、必要な情報をユーザーが提供するプロセスです。 たとえばFace IDを使用するには、最初に顔をスキャンする必要があります。
一般に、キャリブレーションは、その初期情報なしでは機能が使えない場合にのみ使用してください。 キャリブレーションなしで機能が使える場合は、暗黙的なフィードバックや場合によっては明示的なフィードバックなど、他の方法を使ってユーザーについての情報を集めることを検討してください。
常にユーザーの情報を保護してください。
キャリブレーション中に、ユーザーは機密情報を提供する場合があるため、必ず安全な状態を保ってください。
なぜユーザーの情報が必要なのかを明確にしてください。
通常、機能を使用する前にキャリブレーションが必要です。そのため、なぜ情報を提供するかの価値をユーザーが理解していることが不可欠です。ユーザーがあなたの機能からどのように利益を得ることができるか簡潔に説明するとき、それがどのように動くかではなく、それが何をしてくれるかに焦点を合わせてください。
最も重要な情報のみを収集してください。
情報の取得は少しだけにすることを念頭に置いた固有の体験を設計できると、ユーザーがプロセスに参加しやすくなり、アプリに対する信頼が高まります。
キャリブレーションに複数回参加するようユーザーに求めないでください。
また、ユーザー体験の初期に、キャリブレーションが行われるのが最適です。ユーザーがアプリや機能を使い続けると、暗黙的または明示的なフィードバックを使って、再参加するよう求めることなく、ユーザーについての情報を進化させることができます。例外は、ヒトではなくモノを使ったキャリブレーションが必要な機能です。たとえば、ユーザーが野球のスイングを改善するのに役立つアプリは、新しい野球場ごとに調整する必要があります。
キャリブレーションを素早く簡単に行えるようにしてください。
短いキャリブレーションであってもユーザーの時間と労力がかかります。理想的なキャリブレーション体験は、ユーザーが提供する情報の質を損なうことなく、簡単に対応できるようにすることです。次の手引きは、効率化されたキャリブレーション体験をつくるのに役立つでしょう。
・重要な情報をいくつか取得し、残りを他の情報源から推察したり、フィードバックを得ることから推察することに焦点を合わせてください。
・ほとんどの人が調べなければならない情報を求めないでください。
・難しいかもしれない行動をおこなうようユーザーに求めるのは避けてください。
キャリブレーションを正しく行う方法をユーザーがわかっているか、必ず確かめてください。
キャリブレーションに参加することを決めた後、明確な目標を与え、目標達成までの進捗を示すようにしてください。たとえば、Face IDのキャリブレーションは、スキャンの進行に合わせて顔を囲む目盛りの外観を変更することで、ユーザーが何をすべきかを簡潔に説明しています。
進行が止まったときには、すぐに手助けをしてください。
進行が止まると、人は立ち往生したり無力になったりし、アプリに対する信頼を失う可能性があります。このような状況では、ユーザーがすぐに軌道修正できるような、実際に行動できる提案をすることが大事です。この手引きを提供する際には、何かがうまくいっていないことやユーザーに落ち度があることを暗に示したり、明確なネクストステップがないまま放置したりすることは絶対に避けてください。
ユーザーが正常にキャリブレーションを完了できているか確認してください。
ユーザーがキャリブレーションを正常に完了した瞬間、その機能を使うための明確な道筋を示すことによって、時間と労力に報いてください。キャリブレーション体験においてはっきりとした終わりを示すことで体験のユニークさが強化され、いざ機能を使い始めるほうにユーザーが意識を切り替えやすくなります。
いつでもキャリブレーションをキャンセルできるようにしてください。
いつでも体験をキャンセルする簡単なやり方を提供し、ユーザーの選択についての評価を暗示しないようにしてください。キャンセルされたキャリブレーションについていちいち言及するメッセージを提供する必要はありません。いつでもまたやり直せるからです。
キャリブレーション中に提供した情報を更新したり削除したりする方法を教えてあげてください。
ユーザーが情報を編集できるようにすると、ユーザー自身がより多くのことをコントロールできるようになり、アプリをより信頼できるようになります。キャリブレーション体験は反応を調整するのに役立ちますが、この体験以外でも情報を編集できるようにして、いつでも気軽に変更できるようにすることをおすすめします。
修正
アプリが犯す間違いを直すために、人は修正を行います。たとえば、写真アプリがユーザーが好ましくない方法で写真を自動的にトリミングする場合、ユーザーは別の方法で写真をトリミングすることで間違いを修正できます。
馴染みある、簡単な修正方法を提供してください。
アプリが間違えた場合、それを修正する方法について混乱を招くことは望ましくありません。アプリが自動化されたタスクを実行するときに行う手順を示すことで、混乱を避けることができます。たとえば、Photosでは、写真を自動トリミングするために使用するコントロールが強調表示されているため、同じコントロールを使用して結果を調整または元に戻すことができます。
修正が行われたら、すぐに価値を提供してください。
修正された内容を即座に表示することによってユーザーの労力に報いてください。その機能が重要であったりユーザーの直接入力にあなたが返事をするような場合には特にそうしてください。また、必ず更新を永続化して、ユーザーが同じ修正を再び行う必要がないようにしてください。
ユーザーが自分の修正を修正できるようにしてあげてください。
時々、ユーザーは自分が間違いを犯したことに気付かずに修正を行います。他のすべての修正と同様に、更新された修正にすぐに対応し、更新を保持してください。
常に機能の利点と修正に必要な労力のバランスを取ってください。
タスクを自動化する機能が間違いを犯しても気にしないかもしれませんが、タスクを自分で実行する方が簡単だと思われる場合は、機能を使うのをやめる恐れがあります。
決して低品質の結果を補うために修正に頼らないでください。
修正は間違いの影響を減らすことができますが、それらに頼ることにはアプリに対するユーザーの信頼を損ない、機能の価値を下げる恐れもあります。
ユーザーによる修正が理にかなっているときには修正から学んでください。
修正とは、アプリがいかにユーザーの期待に応えられていないかの貴重な情報を得られる暗黙的なフィードバックの一種です。修正を使ってモデルを更新する前に、修正がより高品質の結果につながることを確認してください。
できれば、自由形式の修正の代わりにガイド付き修正を使用してください。
ガイド付き修正は特定の代替案を示すため、ユーザーの労力が少なくて済みます。自由形式の修正は特定の代替案を示さないため、ユーザーからのより多くの入力が必要となります。ガイド付き修正の例としては、音声からテキストへの変換機能があり、選べる形で代替テキスト補完されたもののリストが示されます。対照的に、Photosは自由形式の修正を行なっているため、人々は写真の自動トリミングを適切に調整できます。アプリにおいて意味がある場合は、ガイド付き修正と自由形式の修正を組み合わせて提供したほうが望ましいです。
翻訳は以上です。
同じくAIプロダクトをつくっている人、これからつくろうとしている人の参考になれば幸いです。
翻訳が誤っているところ、適切でないところに気づいた場合は遠慮なくtwitterのDMなどでご連絡いただけるとありがたいです。
次回は出力篇です。乞うご期待ください。
この記事が気に入ったらサポートをしてみませんか？