エキスパートユーザーでテストする
熟練したユーザーを対象とするユーザビリティ調査は、初心者対象の調査よりも実施が難しく、改善できる点も少ないのが普通だ。それでも、エキスパートのパフォーマンスを改善することは、たいていの場合、努力する価値がある。
Alice Daveyがこういう質問を送ってきた：
私は「アプリケーションのデザイン」等のいくつかのコースを受講したことのある者ですが、コースの内容は非常によかったです。今、私は、ユーザーが頻繁に使えば、すぐにその「エキスパート」になれる、XXXというアプリケーションをデザインしています。
開発の初期段階でユーザビリティテストをしたいとは思っているのですが、ずっと困っているのは、そのアプリケーションが「エキスパート」ユーザーの役に立つかどうかを、どうやったらテストできるかということです。当然ですが、テストに参加することになるユーザーは皆、このソフトに対しては初心者だからです。
この問題は初心者とエキスパートユーザーの間のバランスがエキスパートの方向に傾くと、ますます重要になってくる。
とはいえ、エキスパートユーザーのためのユーザビリティを議論する前に、初心者の時期を経ずには、エキスパートになれる人は誰もいない、ということを思い出そう。利用者数が固定されていて、今後、その製品を売ることや、新しいスタッフを雇って、既存のスタッフと入れ替えたり、増員したりすることを想定していないという、まれな場合をのぞけば、慣れないユーザーのためのユーザビリティについて忘れてはならない。
ウェブ上では、最初のユーザーエクスペリエンスというのは、特に重要だ。なぜならば10年間他のサイトを利用した経験のある人でも、サーチエンジンから初めてクリックスルーしてきた時には、あなたのサイトに関しては初心者であるからだ。あなたのサイトが彼らの期待に応えることが可能で、かつすぐに理解できるものでない限り、彼らは既に知っているサイトにさっさと退却してしまうだろう。
エキスパートユーザーでテストする： 基本
エキスパートでテストするときの基本は他のユーザーテストと同じである：
- 代表的なユーザーをリクルートする
- 現実的なタスクを与える
- 頭に浮かんだことを声に出して言うように依頼する（その間、あなた方は何も言わないようにし、タイミングの悪いヒントで彼らの行動にバイアスがかからないようにする）
また、最初は少数のユーザーでテストをし、次回のテストまでにそのデザインを反復するのが一番よい場合も多い。こうした小規模の調査は、忠実度の高くないプロトタイプを使い、デザインプロセスのできるだけ早い段階で実施すべきである。ペーパープロトタイプは初心者よりもエキスパートに対して、ずっと有効ではないだろうか。なぜならばエキスパートはそうしたテストタスクの実行に慣れているからである。したがって、彼らは当面の問題以上のこと、例えば、ダイアログボックスはインデックスカード上に現れるべきか、それとも画面上に四角として現れた方がよいか、といったこと以上の内容について、重点的に取り組みことが可能である。
初心者でのテストとの違いの1つ目は、エキスパート向けの場合には、「現実的なタスク」は明らかにより高度なものになるということである。深く理解してもらって、より大きな難しい課題に取り組んでもらうことが可能なのである。
2番目の違いは、1つ目ほどは目立たないかもしれない。ほとんどの場合、デザインを利用しながら、独り言を言い続ける形で、考えを言葉で表現するよう、我々はユーザーに依頼する。この思考発話というプロセスは、人々がどのようにデザインの要素を解釈するのか、どこかわかりにくいところはないか、どの要素が無理、あるいは不快か、といったことを伝えてくれる。テストという状況は少々、人工的ではあるけれども、良質な司会者と興味をそそるタスクによって、ユーザーの不信を一時的に解消し、彼らがありのままの真実を伝えることを可能にするのである。
しかしながら、エキスパートユーザーは思考発話調査に以下のような問題を引き起こす：
- 熟練した行動の多くは自動化された行動である（詳しくは、人の心とユーザビリティでのセミナーで論じる）。人はある行動について、自分がどのように考えているかを意識していないと、その行動の理由を言語化することができない。例えば、車をどうやって運転しているか考えてみるとよい。車での通勤中に考えていることを口に出してください、と司会者に依頼されても、車のスピードを上げたり下げたりしているときの手順を説明したりは、普通しないだろう。しかし、いつもAT車を運転しているのに、調査でMT車が与えられれば、クラッチの使用について考えたことをおそらく口にするのではないだろうか。反対に、毎日、MT車を運転している場合、思考発話セッション中、クラッチについて何かコメントする可能性は少ないだろう。エキスパートユーザーにまつわるこの問題をうまく切り抜けるためには、より複雑なユーザビリティ手法使って、反応のスローモーションの映像をゆっくりと（うんざりするほど）分析することで、ユーザーが何も伝えてくれないような事例で何が行われていたかを推測すればよい。
- エキスパートユーザーは、ユーザーとしての役割に留まり、実際の機能と格闘する代わりに、デザインの批評家に成り代わって、製品に対して聴くに値する意見をすることが可能である（というのも彼らはその製品をよく知っているからである）。彼らのコメントは潔く受け入れよう。そして、その一方で普通の人々の言うことや、することと、彼らのそれはかなり違いうるということは覚えておこう。ユーザビリティ調査をする理由は行動データを収集するためである。したがって、ガイドになる参加者にもできるだけ早くデザインを利用するという役割に戻ってもらおう。
エキスパートをリクルートする
もしあなたが既存の製品のデザインを変更しているというのなら、運がよい。なぜならば、そこにはエキスパートユーザーが自然な状態で、既に存在しているからだ。あなたに必要なのは1時間か2時間来てもらえるように彼らをリクルートすることだけである。テスト参加者をリクルートするための従来からあるやり方に従い、いくつかのひねりを加えればよい。登録ユーザーのリストによって、勧誘の電話に対して予想される単調で退屈なプロセスを短縮することもできるだろう。ときには、上得意先のマネージャーと一緒に、あなたの製品のユーザーの何人かにコンタクトすることが可能な場合もある。（もしそうなら、あなたが必要なのは平均的なユーザーであり、マネージャーが見せびらかしたがる「ずば抜けたパフォ−マンスをするユーザー」ではないということは強調しよう）。
ウェブサイトの場合、サイト上にリクエストを載せることや、eメールニュースレター（これには、あなた方の最も忠実な顧客に連絡をつけることができるメリットもある）でボランティアを募ることにより、既存のユーザーをリクルートすることが可能な場合もあるだろう。
エキスパートユーザーをリクルートする他のやり方としては、産業見本市（特にあなたの会社のブースがある場合）や、ユーザーグループミーティング、ソーシャルメディア（特にあなた自身のサイトのソーシャル機能）を利用する手もある。
すばやくエキスパートを育てる
このコラムのきっかけになった質問は新製品に関わるものであった。この場合、エキスパートユーザーは存在しない。なぜならばその製品にはまだユーザーがいないからである。
存在していない人をリクルートすることはできない。したがって、熟練したユーザーを自前で作り出す必要性が出てくる。まず可能なのは、内部のスタッフでテストをしないというルールを破ることである。通常はデザインプロジェクトやその会社に関わりのある誰か（もちろん、イントラネット調査の場合は除く）をテストしたくはないものだ。こうした人々は内情を知りすぎており、外部のユーザーの思い違いによって引き起こされるユーザビリティ上の問題を発見できなくなるからだ。
知りすぎていることはエキスパート調査では長所にもなりうる。それでも、内部のユーザーが理想的なテスト参加者でないことに変わりはない。なぜならば、そのシステムに対する彼らのメンタルモデルは、UIの表面に現れている部分に接しただけで自然に作られるモデルに比べ、構造的にずっと優れたものになってしまうからである。
一例として、ウェブサイトの構造について考えてみよう。例えば、外部のユーザーはナビゲーションデザインからその構造を推測するしかない。ナビゲーションが優れていれば、ユーザーはIAについてのヒントをそこから得ることはできる。しかし、ナビゲーションは彼らの一番の関心事ではない。ユーザーはサイト上で用事を済ませたいと思ってはいるが、そのサイトの構造に細心の注意を払ったり、1回の訪問で得た知識のほとんどを次回の訪問まで覚えておいたりはあまりしないのである。反対に、内部のユーザーは、製品ラインや会社のビジネスのやり方についての既存の知識によって、概念モデルを作り出すことができ、それは、そのサイトの構造について、彼らがより優れたメンタルモデルを発展させる手助けとなる。
したがって、内部のエキスパートでテストするときは、彼らが外部のエキスパートに比べて、より多くの知識を持ち、行動も異なるであろうことを忘れないようにしよう。
2番目の、そしてもっとうまい方法は、新規のユーザーにインスタントのトレーニングを施し、新たにエキスパートに育てるというものである。それには、参加者がデザインを理解するのを手助けするための個人チューターを任命して、彼らからの質問に全部答えさせればよい。（通常、我々はユーザーからの質問には答えない。なぜならば、彼らの行動にバイアスをかけたくないからだ。しかし、エキスパートの利用や、初めてでないときの利用についてテストする場合には、人々が初期段階の問題点をどのように乗り越えていくかということについて、我々はそれほど気にしない。したがって、指導は問題ない）。
調査開始前、テスト参加者にはそのデザインに慣れる時間をたっぷりと与えてよい。そうすることはコストの節約にもなる。なぜならば、練習セッションの間は、彼らをじっとモニターする必要がないからである。もちろん、ユーザーがエキスパートとして必要な知識を得るために1週間の練習が必要なら、1週間分の謝礼を彼らに支払う必要はある。しかし、少なくとも、その週の間中、彼らの隣に座っている必要はない。単に作業スペースを与えて、定期的に見回ればよい（そして、もし質問がある場合には、チューターに電話できるように、彼らには直通の電話番号を教えておこう）。
トレーニングとマニュアル
追加の支援トレーニングを提供することは、新たなエキスパートを素早く作り出すやり方の1つである。また、正規のトレーニングコースや教材といったユーザーサポートを提供している製品をテストするのであれば、それらを利用することも可能である。新製品の場合は、テストプランのこの部分を作り出して、トレーニング教材そのもののユーザビリティに関する実験データを得ることもできる。
ユーザー調査すべてにあてはまる最上のガイドラインとは、可能な限り実社会に近づける、というものだ。つまり、マニュアルを用意し、トレーニングコースを提供するのであれば、テスト参加者にそうした資源を活用してもらって構わないのである。
不幸なことだが、現実の世界では、たとえ、アプリケーションの最初の公開時にトレーニングコースを提供しても、全てのユーザーがそれを受けるわけではない。翌年、入社した新規の従業員は、もし彼の同僚がそのトレーニングセッションで覚えたことをなんであれ、時間を取って教えてくれるというのであれば、それはラッキーなのである。（悲しいことに、たいていの人は1年前に受けたコースのことなどほとんど覚えていない）。
同様に、購入時のマニュアルやユーザーガイドを提供してもよいだろう。しかしこうした説明書は、新しい従業員がその機械やアプリケーションを利用するように言われるまでは、行方不明になっている可能性もある。
したがって、通常、一番よいのは、説明書を使ってトレーニングをするユーザビリティセッションと、そうした情報抜きのセッションを実施することであろう。
大きな改善は期待しないようにしよう
ユーザビリティに対する投資利益率についての経験則に、初めてのユーザーテストでは、（コンバージョンレートのような）要求されるビジネス指標を倍にすることが可能だというのがある。特にウェブサイトでは、少なくとも1つは、背筋の寒くなるような、ユーザーに嫌がられるデザイン要素を見つけられることが多いだろう。それは内部の人間には決して問題とは見えないが、企業にはビジネス上、大きな損失をもたらすものである。
エキスパートユーザーの場合、ユーザビリティ調査によってもたらされる改善はあまり大きなものでないことが普通だ。ありがたいことに、人間は信じられないほど、柔軟で適応力のある生き物なため、我々はグリーンランドから赤道ギニアにいたるエリアで生活もすれば、努力すればLinuxを使いこなすこともできる。10年間、1つのソフトウェアを使ってきた人なら、そこにある設計上の欠陥を乗り越えるための次善の策や裏技を創り出していくし、そのUIの裏にある多数の恣意的なルールも自分のものとしていくだろう。多くの人々は打たれ強いものであり、悪いデザインにもだんだんと適合してしまって、それを改善するための変更には抵抗をする。結局のところ、彼らは難しいUIの利用方法を既に知っているわけだから、ある程度学習が必要になる、平易なUIになぜ変えるのか、ということになるのである。(学習する時間を無駄にする代わりのことをユーザーは強くひいきするのだ。)
熟練したユーザーは旧式のデザインにも適応していくので、彼らのパフォーマンスを向上させる可能性は、サイトの新規訪問者に対して得られることの多い100％という値よりは小さいのが普通である。平均すると、1/3の改善というのが現実的なところだろう。
エキスパートからの要求に応じるべきか
エキスパートユーザーのためのユーザビリティ調査は、費用がかかるのに、期待できる改善度は大きくない。ではなぜやるのか。理由はいくつかある：
- ユーザーが初心者である期間は短いが、エキスパートになってからの期間は長いものである。少なくとも、継続して利用される製品の場合はどれもそうだ。したがって、より優れたエキスパートユーザビリティから来る（小さな）利益はより長い期間、利子を生み続け、最終的には、初心者向けの改良からもたらされる一時の利益よりも、合計するとずっと大きな利潤をもたらすことになる。
- 既存の大きなユーザー集団を抱えた、成長のあまり望めない大規模な設置基盤を持つ製品もある。ユーザビリティの進歩によって、実際、どのくらい利益が上がるかを計算するには、ユーザー1人あたりの利益にユーザー数をかけてみればよい。そうすれば、このシナリオもまたエキスパートユーザーを重点的に扱うことに有利に働く。
- 頻繁に繰り返し利用される製品もある。よくある例としては、コールセンターの販売員向けのアプリケーションがそうだ。その他、断続的にしか利用されなくても、ユーザーパフォーマンスの善し悪しによるインパクトは計り知れないという製品もあるだろう。工場のコントロールルームでのエラー処理がこのよい例である。こうした事例では、ユーザーはよく訓練されているので、初心者向けのユーザビリティをそれほど考慮する必要はない。しかし、エキスパートのユーザビリティを損なうことは致命的である。
- 最後に、ヘビーユーザーが利益の大部分を偏って占めている場合もありうる。忠実な顧客を育くむeコマースのサイトはとりわけそうだろう。こうしたサイト上では、頻繁だったり、大きな買い物は、特に簡単にすませたいものだからである。
理由はなんであれ、エキスパートのためのユーザーエクスペリエンスを改善するために、ユーザビリティにさらに投資をすることは、たいていの場合、価値があるものである。
