ゲストで実現する格安ユーザーテスト、その3大注意点とは？

テストの基本

ユーザーがパソコンと格闘する様子を、デザイナや開発者がマジックミラーで仕切られた隠し部屋から観察している――ユーザーテストの事例としてよく紹介される光景だ。

日本でもこのようなテストが頻繁に実施されるようになってきた。Webサイトに限らず、ケータイからテレビまでテスト対象もテスト手法もさまざまだが、どのテストも、まさしく「百聞は一見にしかず」という体験を設計チームに与えてくれるものだ。ユーザーテストのうんちくを語り始めるときりはないが、その基本はとても単純なものだ。

• ユーザーにタスク（作業）を実行するように依頼する。
• ユーザーがタスクを実行する過程を観察、記録する。

図1　ユーザーテストの様子

テスト人数に関しては、ヤコブ・ニールセンが提唱した5人のユーザーでテストすれば約85％の問題点が見つかるという法則がある。これに異論を唱える人もいるが、現在ではほぼ世界標準となっており、少人数のユーザーでテストするのが普通だ。

ただ、マーケティングで活用されている「グループインタビュー」と混同して、5人のユーザーを1部屋に集めて同時にテストするようなことをしてはいけない。ユーザーテストでは必ず1人ずつ順番にテストすることが大切だ。現実でも、ほとんどの場合、ユーザーは1人で判断しながらWebサイトを操作しているのだから。

観察のポイント

ユーザーの行動を漫然と観察していても発見は少ないだろう。以下の3つのポイントに絞って観察しよう。

• まず、ユーザーは独力でタスクを完了できただろうか。もし完了できなかったとすれば、そのWebサイトには「効果問題」があると言える。これは端的に言えば、そのサイトは「使いモノにならない」ということであり、もっとも深刻なユーザビリティ問題である。

• 次に、ユーザーは無駄な操作を行ったり、戸惑ったりしなかっただろうか。独力でタスクを完了できたとしても、その間に、ユーザーを考え込ませたり、遠回りさせたりするようなWebサイトには、「効率問題」があると言える。

• さらに、ユーザーは不安や不満を感じていないだろうか。たとえ、ユーザーがほぼ想定ルートを通って独力でタスクを完了できたとしても、途中で不愉快な思いをさせるようなWebサイトには「満足度問題」があると言える。ユーザーはタスク実行途中に明示的に不満を表明する場合もあるが、表情や態度で暗示的に不満を表明している場合もある。

「ユーザーテストとは、効率問題（無駄な操作の有無）を発見することを目的としている」と考えている人が多いのではないだろうか。実際、テストで発見される問題点の多くも効率問題だ。しかし、より深刻な効果問題が潜在している可能性に絶えず注意を払うべきだ。

ユーザビリティ人名図鑑（その6）

図3　スティーブ・クルーグ

図2　『ウェブユーザビリティの法則（原題「Don't Make Me Think！」）』（ソフトバンククリエイティブ、著：スティーブ・クルーグ、訳：中野恵美子 ）

スティーブ・クルーグ

著書『ウェブユーザビリティの法則（原題「Don't Make Me Think！」）』（ソフトバンククリエイティブ、著：スティーブ・クルーグ、訳：中野恵美子 ）が大ヒットして一躍人気者に。その巧みな話術を活かして、ルイス・ローゼンフェルドといっしょにワークショップを開催したり、コンサルタントとして活躍している。

ラボはなくてもテストはできる

我々プロのユーザビリティエンジニアは専用のラボを使ってテストすることが多い。しかし、これは「テストをするためにはラボが必要」という意味ではない。どちらかと言えば「あるから使っている」だけだ。ラボはなくてもテストはできる。そもそも、ラボを使えない状況でテストすることも少なくないのだ。

ここで仮に、あなたの会社のWebサイトについて、企業情報ページをテストすることにしよう。一般のコーポレートサイトにとってもっとも重要なコンテンツの1つが地図だろう。ある会社を初めて訪問する際に、その会社のWebサイトにアクセスして企業情報ページに掲載されている地図を見る人は多い。このテストをラボで行っても、あまり効果はない。サイト上の地図を見て「わかったつもり」が、現地で迷子になるのはよくあることだからだ。このテストは現場でやるしかない。

まず、テストに協力してくれるユーザーを探そう。条件は「あなたの会社に来る必要があるが、場所をまったく知らない」ユーザーだ。要するに「新規のお客さん」ならば誰でもよいのだが、重要な商談の相手をテスト対象にするのはさすがにリスクが高いので、たとえばアルバイトの応募者や就活の学生などの方が適切だろう。

事前に意図を簡単に説明しておいて、駅の改札口で待ち合わせよう。そして、後は、ユーザーにすべて任せてオフィスまで独力で到達してもらおう。あなたはユーザーの斜め後ろから黙ってついて行くだけだ。決して前を歩いてはいけない（それでは誘導になってしまう！）。

ユーザーは駅の出口を間違えたり、反対方向に歩き出したり、曲がり角をとおり過ぎたりするかもしれない。また、プリントアウトした地図を見直したり、不安そうに周りを見たり、場合によってはとおりすがりの人に質問するかもしれない。そのすべての行動を記録しよう。速記が大変ならばビデオカメラで撮影してもよい（ただし、公共の場で無闇に撮影していると、最近はあらぬ疑いをかけられる危険があるのでご注意を）。

無事オフィスに到着したら、お茶菓子と飲み物を用意しておいて、ユーザーに行動をざっくばらんに振り返ってもらおう。なぜ、反対方向に向かったのか？　不安そうに探していたのは何だったのか？　このテストを5人くらい繰り返せば、あなたの会社の地図における問題点はほぼすべてあきらかになるだろう。それと同時に改善案もたくさん生まれることだろう。

早い段階から繰り返してテスト

テストを行わないのは論外としても、一般的にデザイナや開発者には悪い癖がある。それは、テストの実施時期を遅らせたがることだ。

彼らは完成していないデザインをユーザーに見せることを嫌がる。「中途半端なものをテストしても意味はない。デザインやコーディングが完了してからテストすべきだ」と考える。しかし、これは大きな間違いだ。

ユーザビリティは完成度の問題ではない。前述の地図の例を引けば、ユーザーがオフィスに到達できないのは地図の見た目が悪いからではない。適切な内容であれば、手書きの地図でも十分なはずだ。問題の根源は「あなたにとって当たり前のことが、ユーザーにとってはまったく当たり前ではない」ということを、あなたが理解していないことなのだ。

このようなボタンのかけ違いは早めに直すべきだ。Webサイトでも本格的なデザインやコーディングを始める前にテストしよう――ペーパープロトタイプの段階から。

テストで問題点があきらかになったら、すぐデザインを修正しよう。そして、もう1度テストしよう。なぜなら、その改善案が正しいかどうかは、改めてユーザーに見せてみないとわからないからだ。

おまけ

今回は“会社の地図”の例に言及したが、参考までに優れた地図の事例を紹介しておこう。

• ビービット　地図／アクセス方法
• 富士通　本店・川崎工場ご案内・地図

ビービット社はユーザビリティコンサルティングで著名な会社なので、さすがに地図も上手い。特に、利用可能な2駅からの経路を個別に（それもランドマークの写真入りで）作成している点に注目しよう。

富士通はユーザビリティやアクセシビリティに力を入れた製品開発を行っている（「らくらくホン」は代表例）。この地図自体は一見すると普通だが、視覚に障害のある方へのご案内に気付いただろうか。視覚障害を持ったユーザーに画像の地図はまったく役に立たない。そこで、完全テキストバージョンを用意しているのだ。これこそがユーザー視点のデザインだろう。