ユーザーの知識は低いレベルで停滞する
学習というのはたいへんな作業なので、ユーザーのやりたいことではない。その結果、彼らはユーザーインタフェースの探索をすることもなく、ほとんどの機能について知らないままだ。
コンピュータシステムを長期間利用しているユーザーでも、知っていて使っているのは利用可能なコマンドや機能のほんの一部だけであることは多い。デザインのユーザビリティが優れていれば、ユーザーはシステムを利用しはじめて間もなく、かなり容易に一連の基本機能を理解する。しかし、その後、彼らは伸び悩み、それ以上はたいしてスキルが上がらない。システムを頻繁に使っているユーザーですら、年にわずか1つか2つの新しい知識を身につけられるようになるまでには何十年もかかることもある。
ユーザーの知識の停滞は特定のデザインカテゴリーに限定されない。数十年にわたる調査期間を通して、すべての種類のユーザーインタフェースに対してそうした報告が上がっている。
古い事例
先駆的な調査の取り組みの1つとして、Unixの専門家であるSteve Draperのものがあるが、それが発表されたのは1984年である。Draperの発見は、熟練したUnixシステム管理者になるには最低7年かかるということだけではなく、Unixの専門家も人によって知識の範囲が異なる、というものだった。こうした実力のあるコンピュータの専門家も、何でも知っているわけではなかったのである。Unixの専門家はそれぞれ、異なる道筋を辿って知識を獲得してきており、学んでこなかった範囲のスキルはかなり低いままだったからである。
もう少し最近のものには、ユーザビリティ調査のはしりのころ、MicrosoftがOffice 2007になる予定のソフトウェアのリリース時に行った調査がある。そこでUXチームが顧客に依頼したのは、そのパッケージに追加されるといいと思う新機能を挙げてもらうことだった。ところが、リクエストされた「新しい」機能の圧倒的多数はOfficeに何年も前からあったものだった。その結果、デザインチームはその新しいユーザーインタフェースでは発見しやすさに重点的に取り組むことを決断し、リボンを導入した。従来からある機能を確実に理解してもらうほうが、機能を新たに追加するよりも重要だったからである。
実際、Office 2007のそのデザイン変更は効果的で、ユーザーはパッケージのより多くの機能を利用するようになった。それでも、ほとんどの人は利用可能な機能のほんの一握りしかまだ利用してはいないが。
最近の事例
「タッチスクリーン向けのモバイルアプリ」に関するトレーニングコースをアップデートするため、我々はこのところ、最新のモバイルアプリケーションについてのユーザビリティ調査を大量に実施している。特筆すべきは、頻繁に利用しているアプリの基本的機能をいかにユーザーが知らなかったか、だ。iPhoneかAndroidか、それともWindows Phoneなのか、というのは問題ではなかった。つまり、結果はテストしたプラットフォームすべてで同じだったのだ。
この新しい調査は我々がいつも行うユーザビリティ調査とは構成の一部を少し変えていた。具体的には、「show and tell」コーナーを追加し、ユーザーに自分の携帯のアプリを見せてもらい、どのようにそれを利用しているかを説明してもらうように依頼した（訳注： “show and tell”の本来の意味は、学校の課題として、子どもに何かを持ってこさせ、クラスメートにそれについて説明すること）。時には、彼らから説明がなかった機能を利用してみるようにも依頼した。そうすると、どんな場合でも、返ってくる反応はいつもこうだった。「わぁー、このアプリでそんなことができたとは知りませんでした｡教えてくれてありがとうございます」。
（ユーザーが言及しなかった機能を我々が実際に示すことはしていない。我々が依頼したのは、各自でその機能を見つけるというタスクの実行である。それでも、そうしなければ探さなかっただろうものに注意を向けさせたという限りにおいては、我々は良しとされているテスト方法から外れたと言える。しかし、この事例ではそうしても問題はない。というのも、我々はモバイルアプリについてのユーザビリティ調査を数え切れないほど実施しており、基本的な調査結果については全部発見済みだったからである。しかし、もし何かを初めてテストするのなら、どんな小さなことであろうとユーザーにバイアスをかける指示的アプローチはなるべく取らないほうがいいのは間違いない）
以下はユーザーがそのモバイルアプリを頻繁に利用していたにもかかわらず、基本的な機能を知らなかったという例のいくつかである：
Bank of America (iPhone)： 1人のユーザーはこのアプリを定期的に利用して、残高照会をしたり、小切手が決済されたかを確認したりしていたが、小切手で預金できる機能については知らなかった。我々が依頼すると、彼女は容易にそれを見つけ出した。しかし、現実にはその機能は存在していなかったようなものだろう。ユーザーにはそれを探すつもりがなかったのだから。
MyFitnessPal (Windows Phone)： テスト参加者でこのアプリをダイエットに毎日利用している人がいた。彼女が言うには、友達が教えてくれるまで多くの機能に気づいていなかったそうだ（例えば、彼女は自分の体重の推移を記録できることを知らなかった）。テストでは、彼女はどうやって前の日の情報にアクセスするかがわからなかった。また、横方向にスワイプすればさらに機能を見ることができることを忘れがちだった。こういった機能の視認性不足はWindows Phone共通の問題だ。以下に示すのがこの例のスクリーンショットである：
Wag (iPhone)： 1人のユーザーは犬のものを買うのにこのアプリをよく利用していた。が、彼女はアイテムの保存方法を知らなかった上、このコマンドの入ったメニューがトップページ上にあることにも気づいていなかった。残念なことにこのメニューはトップページ上でしか表示されない。つまり、他のページでは出てこないため、この機能をさらに発見しにくくしている。
Wagアプリケーションのトップページでメニューが開いている状態。
製品詳細ページからはメニューへアクセスできない（トップページに戻らない限りは）。
Zappos (Android)： そのユーザーは、お気に入りリストへのアイテムの追加方法を知らなかった。
Weave (ニュースリーダー、Windows Phone)： 1人のテストユーザーはこのアプリで毎日ニュースを読んでいたが、デフォルトのリストにない情報源も追加できることを知らなかった。
iMuscle (iPhone)： あるユーザーは、このアプリを利用して、エクササイズについてざっと見たり、調べたりすることをよくしていた。にもかかわらず、1個の筋肉を鍛えることを目的にしたトレーニングプログラムをどうやって組み立てるか、彼は知らなかった。また、我々が依頼したときにも、特に器具が必要ないエクササイズを見つけることができなかった。
Hulu Plus (Android)： 1人のユーザーはHuluでいつもテレビ番組を探して、視聴していたが、後で見るためのマイリストにどうやって番組を追加するか知らなかった。
こうした事例のすべてにおいて（そして、我々がテストした他の多数の事例でも）、ユーザーは必要最低限のユースケースからほんの少し外れた機能については知らなかった。ニュースを読みますか、はい読みます。ニュースについてそこにある以外の情報源も探しますか、いいえ、それはしません、というわけだ。
多くのアプリは十分にユーザビリティが良いので、促しさえすれば、ユーザーはそうした機能を見つけられた。しかしながら、現実世界にユーザーに新しい機能を見つけさせようとしつづける親切な調査進行役はいない。ラボの外では、こうしたかなり基本的な機能が発見されないままの状態で、もう数年利用される可能性が高いだろう。
知識が伸び悩む理由
自分にとって非常に有益かもしれない機能を知らなくても、長年、コンピュータシステムを利用することは可能だ。これはEメールや文書処理、表計算のような生活のために利用している生産性アプリケーションにもあてはまる。イントラネットのテストで、従業員が重要なエンタープライズ機能に気づいてないということもよくある。
これは矛盾のように感じられる。というのも、ユーザーには大きな利益を得られる可能性があるからだ。そして、その利益は何年にもわたって発生しうるものである。ちょっと時間を使って、ユーザーインタフェースを見て回りさえすればよい。そうすればROIが得られることはわかりきっているのである。
ユーザーがユーザーインタフェースについてもっと知ることで、数学的にはROIが本当に得られるのかもしれない。しかし、行動学的見地からいっても、そのROIが得られるかどうかは今ひとつ不明だ。問題は、投資が瞬間的な行為であることだ。つまり、ユーザーはユーザーインタフェース内のよく知らない部分の移動というインタラクションコストに耐える必要がある。対照的に、利益が得られるのは先のことである。つまり、ユーザーは新しく見つけた機能を利用しても、いつかわからない未来のどこかで少しずつしかそれを理解できるようにはならない。
標準的な経済学は将来の価値から生み出されるNPV（正味現在価値）の算出方法について教えてくれる。具体的にはそれは現在価値を総和したものだが、将来の価値を増加させることになる適切な利率を用いて、各価値の利益を割り引いて考える。
人間とは将来のそうした小さな利益についてはかなり割り引いて考えるようにできているのではないだろうか。我々の祖先が暮らしていた環境では、不確かな将来の出来事が意味のある利益になる前には死んでしまっていただろうからだ。
根底にある生物学がどうであれ、30年にわたる調査の経験から事実としてわかっているのは、ユーザーは現時点にしか意識がいかない、ということだ。目の前にあるものが知っていることのすべてなのである。彼らにとって重要なのは、たった今、やっていることだけだ。
ユーザーはマニュアルを読まない。すてきな機能を求めて、ユーザーインタフェース中を探検したりもしない。うまくいくやり方を一旦覚えてしまえば、もっといいやり方があるのではないかと調べることもしない。（あなた方はこういうことをするのだろうが。でも、あなた方は平均的なユーザーではない）。
学習というのはたいへんな作業なので、ユーザーのやりたいことではない。そんなわけで彼らはデザインについては最低限のことしか学習しないため、知識レベルは長年低いままで留まってしまう。学習曲線はすぐに平らになってしまい、その後、ほとんど変化しなくなるのである。
ユーザーに学習を促すことは可能か
最重要のこととして、ユーザーとは学習したがらないものだ、ということを受け入れよう。自分のところのWebサイトやアプリケーションは特に重要で有益だと思っているかもしれないが、ユーザーにとっては、扱わなければならない数百のうちの1つにすぎない。あなた方のユーザーインタフェースが、すべてのユーザーが洗練されたエキスパートになれて、全機能がわかるようになる、この30年間で最初のものになるとは考えにくい。
ユーザーの知識の停滞という問題の解決は不可能だが、問題を軽減する方法はいくつかある：
- 少数の機能。どんな機能であろうと数が増えれば、それ以外の機能は見つけにくくなるし、学習もたいへんになる。逆説的ではあるが、提供する機能を減らせば、より多くの機能が利用されるようになる可能性はある。
- 目に見える機能。重要な機能は探させてはならない。もちろん、段階的開示を利用すれば高度な機能は目に入らないようにすることが可能だ。しかし、それを開示する方法は目に見える形で提供する必要がある。
- 目に見えるシグニファイア。知覚されたアフォーダンスによって、何ができるか、そのためにはどうすべきかを明確に指し示す必要がある。Webページのリンクを視覚化するためのガイドラインがその良い例になるだろう。行き過ぎたフラットデザインはやめよう。アイテムがどれも同じに見えるし、クリックできるものが無いように見える。
- ジャストインタイム型の学習。ユーザーがマニュアルを読むことはないだろうが、コンテクストの中で示されるちょっとしたヒントなら彼らも読むことがある。
- 教えられる機会のフル活用。エラーメッセージによって問題のより良い解決方法に向け、ユーザーを導くことは可能だ。
- 寛容さ。探索はユーザーがどんな状況からでも容易に脱出できるときに行われることが多い。（戻るボタンを含む)取り消しが可能なこと、明快なナビゲーションは不可欠だ。反対に、ユーザーは新しい機能を試して痛い目に遭うと、間違いなくあなた方のところのUIを二度と探索しようとはしなくなる。
- 関与度合いの低いプレビュー。さらに寛容なのは、実際に起こる前に何が起こる予定かをユーザーに示すことである。例として、ファセットナビゲーション内の様々なオプション選択用の重要なアイテムの提供、Microsoft Wordでスタイルにマウスオーバーしている間の文書の書式の一時的変更などがある。
- 平易なユーザビリティ。利用しやすければしやすいほど、学習のための認知的余裕をユーザーは持ちやすくなる。
こうしたガイドラインに従うとよい。そうすれば、徐々にユーザーの理解は進み、もっと多くの機能が利用されるようになる。あなた方のデザインを利用することで成果が上がれば、さらにデザインは気に入られるはずだ。そうすれば皆がメリットを得られる。
参考文献
Stephen W. Draper (1984): “The nature of expertise in UNIX” in B. Shackel (ed.) Human-Computer Interaction — Proceedings of the INTERACT ’84 Conference (North-Holland: Amsterdam), pp. 465–471.
