せっかくプロトタイプをつくって、実際のユーザーに使ってもらってテストを行ったとしても、被験者が実際のターゲットユーザーと異なったり、タスクの設定そのものが実際のユーザーが行うであろうものとかけ離れていたとすれば、いくらテストを行っても本当の意味でのデザイン上の問題点は発見できません。
ユーザーテストはテスト設計が大事です。
役に立たないユーザーテストの例
例えば、クルマに興味のない人に中古車情報検索サイトのユーザーテストを行っても無駄です。そもそも与えたタスクそのものが理解できない場合もあるからです。同じように銀行のビジネスをよく理解していない人に、いきなり定期預金を行うためのオンラインバンキングの口座を開設するための申込みをWebサイト上で行ってくださいといってみてもどうにもなりません。そもそも定期預金やオンラインバンキングそのものがよくわかってないからです。
ほかにも映画のチケットをWebで予約するタスクを与える場合にも「まず劇場を探して、その後に自分の見たい映画のチケットを予約してください」といった場合にも問題があります。多くの人はみる場所を先に決めるのではなく、先に何の映画をみるかを決めることが多いからです。特に都心では。
このようにテストを行う被験者のターゲティングが間違っていたり、与えるタスクそのものがユーザーの現状を理解していないものだったりする場合、ユーザーテストは失敗に終わります。問題は見つかりますが、それは本来使ってもらいたいユーザーが使った場合に見つかる問題とは異なるからです。
僕もユーザーテストを行う前のリハーサル、練習などに、まわりの同僚で試してみたりするのですが、その結果そのものはたいてい役に立ちません。とりあえず近くにいる人にお願いしたのではたいてい本来のターゲティングとは異なる人を見つけることになるからです。
しかし、実際にはこうした間違った被験者のターゲティング、間違ったタスクによるユーザーテストを行い、それでユーザーテストをやったと満足している例もすくなくないのではないかと思います。
ユーザーテストはまず仮説ありき
ユーザーテストはあくまで仮説検証の場です。仮説として作成したデザインをユーザーに評価してもらい、自分たちの仮説が正しかったか、仮説に問題があるとすれば具体的にどの箇所なのかを発見する場です。間違った被験者のターゲティング、テストするタスクの設定してしまう要因はこの仮説があいまいなケースが非常に多い。「IDEOにおけるデザイン・プロセスの5段階」で紹介したIDEOの5つのデザイン・プロセス、ISO13407の人間中心設計プロセスでも、「理解」から「観察」や「利用状況の把握」から「要求事項の明示」という具合に仮説づくりにデザインを行う上での重点を置いた上で仮説としてのデザインを作成し評価を行う点で共通しています。
「ユーザー行動シナリオは最初のデザイン」でも指摘したように観察から得られた生のユーザーの行動をベースに仮説としてのユーザー行動をデザインする。それをプロトタイプとして具体化してユーザーテストという形で評価を行う。こうした流れの中で行うからこそユーザーテストは実りあるものになるのだと思います。
テスト設計は、デザインそのもの、ペルソナを用いたユーザー行動シナリオを描くとおなじです。そこで間違えばテスト自体は何の意味もなさないものとなってしまうでしょう。
関連エントリー
この記事へのコメント