Moraeを使ったユーザビリティテスト

From The Joel on Software Translation Project

Joel Spolsky / 青木靖 訳
2005年7月30日 土曜

私が最後に参加したフォーマルなユーザビリティテストは、10万ドルくらいかけて専用に作られたコロラドの立派なラボで行われた。そのラボは基本的にはテレビスタジオであり、マジックミラーにたくさんの特殊なビデオ装置、それに大きなビデオ操作盤を完備していて、スーパーボールの中継でもできそうなほどだった。Junoのユーザビリティテストをするため、私たちのグループはコロラドに飛び、車をレンタルし、ホテルに滞在し、高級レストランで食事し、そうやって人々が私たちのオンラインサービスにサインアップする様子を観察するということのために相当な金を使っていたが、それは大体においてうまく行っていた。

その反対の極端にある方法の「廊下でのユーザビリティテスト」と「ペーパープロトタイピング」を私はずっとみんなに勧めてきたが、これらはユーザビリティ上の最も大きな問題を、それが実際に起るずっと前に見つけ出すことができ、しかも費用は50セントくらいしかかからない。

そしてここに両者の中間とも言うべき方法がある。ミシガン州オケモスのTechSmith社にいる私の友人たちが、最近Moraeという製品をリリースしたのだが、このソフトを使うと贅沢な装置やマジックミラーを使うことなく、安価なWebカムだけで完全なユーザビリティラボを自分のオフィスにセットアップすることができる。彼らの製品自体のユーザビリティテストを、私たちの新しいリモートアシスタンスサービスを材料にFog Creekのオフィスでやってみないかと私が持ちかけたら、彼らは快く引き受けてくれた。

Moraeはこんな仕組みになっている。まず被験者にはWebカムとマイクロフォンのついたコンピュータの前に座ってもらう。

被験者の様子は別なコンピュータから観察することができ、これは何台あってもいい。

この写真でタイラーは2つの画面を見ている。一方は救助側の人を、もう一方は救助される側の人を映している。タイラーは彼らが見ている画面を見ることが出来、彼らの話すことを聞くことができ、そして画面の隅に被験者の様子を映像で見ることができる。Fog Creekにはたまたまオフィスの間に窓があったため、その窓を通して救助者を直接見ることもできた。タイラーが見ている画面にズームインしてみよう。

私は以前UIデザインの本の中で、ユーザビリティテストにおける一般的な問題について書いた。

ユーザビリティテストでは多くの場合、ユーザに対する指示のリストを用意する。たとえば、インターネットアクセスプロバイダーのユーザビリティテストをするなら、そこには「サービスにサインアップする」という指示があるだろう。(実際私は仕事で何度かこのユーザビリティテストをやったことがある。)

そこまではいい。最初のユーザがやって来て、椅子に座り、サービスへのサインアップを始め、そして支払い方法をたずねる画面まで進むと、ユーザは困った顔をして私を見上げ、「自分で払わなきゃいけないんですか?」と聞いてくる。

そのため、私は割り込んで「いいえ、この偽のクレジットカード番号を使ってください」と言うことになる。

そのあとサインアッププロセスは、普通のモデムとケーブルモデムとDSL回線のどれを使うかと質問する。

ユーザは「どれにしたらいいんですか?」と聞く。答えを知らないからだ。彼は自分のコンピュータについてならたぶんその質問に対する答えがわかるのだが、今は自分のコンピュータを使っているのではなく、以前に見たこともないユーザビリティラボのコンピュータを使っている。彼らはそこには始めて来たのだ。

このような問題を回避するため、ユーザビリティテストを行う人たちは、フィールドテストをするようになった。作られた環境でタスクを与える代りに、彼らが自分のデスクで自分の作業をしているところを、近くの茂みに隠れてスパイするわけだ。Moraeはこれをやるのにうってつけだ。このテスト方法は、バージョンnの製品を出していて、バージョンn+1にどのような改善を入れるか検討していときに特に有効だ。

今回のユーザビリティテストはすごくうまく行った。私たちがやったユーザビリティテストでは2人の被験者がいる点で通常のものと少し異なっていた。Fog Creek Copilotには救助者と非救助者がいるのだが、Moraeは1度に1つのコンピュータ、1人のユーザしか観察できない。この問題に対処するには、Morae Remote Viewerをインストールしたコンピュータを2台セットアップするだけで良かった。これでそれぞれの被験者が観察できるようになった。

今朝、これまでにユーザビリティテストセッションを2回行い、素晴らしい結果が得られた。どちらの回の救助者も、再接続するときに混乱しているのがわかったのだ。それはFog Creek Copilotの救助者用アプリケーションは、使い終わったときに自動的に削除されるようになっていたためだった。これはユーザモデルがプログラムモデルに合っていない典型な例だ(ほとんどのプログラムは自分で自分を削除したりはしない!)。このユーザ/プログラムモデル間の不整合というのは、ほとんどあらゆるユーザビリティ上の問題の原因となっていることだ。「プログラマのためのユーザインタフェースデザイン」の最初の章から引用しよう:

すべてのユーザインタフェースデザインの基本原理は：

ユーザインタフェースのデザインが良いというのは、そう振る舞うだろうとユーザが期待したようにプログラムが振る舞うことである。

私はこのことを分っているべきだった。このプログラムのデザインは、私が自分の本に大きな太文字で書いておいた原理を破っていた。プログラムがユーザの期待しないことをしたのだ。ユーザビリティテストの素晴らしいところは、何人かの被験者を使ってユーザビリティテストを1日やるだけで、たとえあなたが私のようにぼけていたとしても、プログラムの振る舞いとユーザの期待する振る舞いの乖離に気付かずにいたところを見つけることができるということだ。

(オリジナル: Usability Testing with Morae)

戻る