ユーザー調査とユーザビリティ評価を混同しない

1つ前に「ユーザーテストはテスト設計が大事」というエントリーを書きましたが、もうひとつユーザビリティの向上を目指す人間中心のデザインの手法のなかで誤解を招きやすいものがあります。

それはユーザー調査とユーザビリティ評価の混同です。

具体的に混同されやすいのは、ユーザー調査法としてのユーザーインタビュー(コンテキスト・インタビュー、コンテキスチュアル・インクワイアリー)と、ユーザビリティ評価法としてのユーザーテスト(ユーザビリティ・テスト)の2つです。
ユーザー調査とユーザビリティ評価でも、ユーザー調査法としてのアンケート法とユーザビリティ評価法としてのヒューリスティック評価を混同する人はなかなかいませんが、ことユーザーインタビューとユーザーテストに関しては、両方ごっちゃに理解している人が多くいます。

問題なのは、ユーザビリティを騙って仕事をしている人のなかでもこの2つを混同してる人がいることです。

ユーザーインタビューとユーザーテスト、異なる利用場面と異なる利用目的

まず「ISO13407:人間中心設計」のエントリーでも紹介した、人間中心設計のプロセスをみてください。



  • 人間中心設計の必要性の特定
  • 利用の状況の把握と明示
  • ユーザーと組織の要求事項の明示
  • 設計による解決案の作成
  • 要求事項に対する設計の評価

人間中心設計のプロセスは上記の5つのプロセスからなります。

まず、答えから示せば、ユーザーインタビューは「利用の状況の把握と明示」のために行うもの、ユーザーテストは「要求事項に対する設計の評価」のために行うものです。
もちろん、ユーザーインタビューとユーザーテスト以外のユーザー調査もユーザビリティ評価もそれぞれ「利用の状況の把握と明示」、「要求事項に対する設計の評価」という異なる場面、異なる目的に応じて使い分けるものです。

ユーザーインタビュー

ユーザーインタビューは、これからデザインしようと考えているものの現状のバージョンの製品をユーザーがどのように利用していて、どのような不満や利点を感じているのかを明確にするために行う調査です。
それは実際のユーザーの利用シーンを観察することで、ユーザーと対象製品のインタラクション、それに関わるユーザーの行動や心理を知ることが目的です。

デザイン・プロセスにおいては、こうした調査から得られたユーザーの実際の行動を元に、いまからデザインしようとするものをユーザーが利用する際、どのような行動を行い、どのような経験をするのかを、行動シナリオとして描く段階に移ります。
それはまさに「ユーザー行動シナリオは最初のデザイン」で書いたように最初のデザイン・イメージとしてのユーザー行動シナリオを書き起こすためのインプット情報になるわけです。

そのためユーザーテストのように、あらかじめ決められたタスクを与えてそれを実行してもらうという形をとるのではなく、普段実際に使っているものを調査担当者の目の前で再現してもらいながら、そうした行動を行う理由や実際に何をやっているのかをインタビューで教えてもらう方法をとります。

ようするに、ユーザーインタビューの原点にあるのは、人類学の調査で用いられるフィールドワーク調査です。
実際の人々の暮らしの文脈のなかに調査担当者がはいりこんで、その文脈ともども調査対象者の行動の意味を発見するもので、それゆえ、コンテキスト・インタビューだとか、コンテキスチュアル・インクワイアリーといった呼び方をされることもあるのです。

ユーザーテスト

一方のユーザーテストの目的は、ユーザーインタビューとは大きく異なります。それは仮説をベースにつくったデザインのプロトタイプ、ある意図をもって形にしたものを、実際の対象ユーザーに使ってもらうことで、想定した仮説、意図した行動をユーザーが問題なく行えるかどうかを評価するものです。

だからこそ、「ユーザーテストはテスト設計が大事」でも書かせていただいたような、テストの被験者としてきちんとターゲティングを行うこと、デザインを行った際の仮説、意図通りのタスク設計を行い、それをユーザーに実際にやってもらうことで、あらかじめ想定していたユーザー行動と実際にユーザーが行った行動の際からデザインの問題点を抽出することが必要になります。

ユーザーインタビューが潜在的なユーザニーズに関する仮説発見を目的としたものだとしたら、ユーザーテストは明らかにその仮説の検証を目的としたものなのです。
ですので、この2つの手法を混同して使ってしまえば、結局どちらの目的も達せられない結果になりかねないのです。

はじめに仮説を発見することと、自らが持っている仮説の正しさを検証することが別のものであることは考えればわかるはずです。
しかし、その2つの目的を達成するための手法となると、何も考えずに混同してしまうことが本当によく起こりえてしまうのです。

無知を知ること

問題設定を誤れば本来得られるはずの答えさえ得られないことはあります。
ましてや手法の使い方を間違っておきながら、答えが得られないことを手法のせいにするのはあまりおろかです。

もちろん、正しい手法を使っても欲しい答えが見つからないことは多々あります。

しかし、それは、そもそもの期待に問題があるのでしょう。

われわれはついうっかり、世界をありのままに見れば、隠されるものの何もない状態があらわれる、「ちゃんと」見れば世界の謎は消える、と考えてしまうことがあります。
しかしレオナルドは、「ちゃんと」見れば見るほどあらわれてくる謎があることを、知っていました。

そう。好奇心の構造はそうなっているのだと思います。
見れば見るほど謎があらわれるからこそ、もっとよく見よう、もっと知ろうという好奇心が加速されます。
無知を知ることこそが知ることの動機です。

そして、それこそがデザインの動機でもあるのではないでしょうか。自分の無知を知り、それに好奇心を駆り立てられてデザインをする。その動機をちゃんと理解するならば、ユーザー調査とユーザビリティ評価を混同することなど本来ないはずなのだと思います。

成功の障害としての「わかってるつもり」」をいうエントリーでも関連した話を書きましたが、知ろうとする気のない人ほど、何事も「わかったつもり」になり、自ら成長したり、周囲とともに成長したりということができないのだろうと思います。

  

関連エントリー

この記事へのコメント

  • 浅野 智

    これはとても良い話ですね。
    確かに混同している人がいますね。
    2007年06月09日 07:05

この記事へのトラックバック