Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Alertbox: ユーザビリティテストの時間配分(2005年9月12日)
[go: Go Back, main page]

USABILITY
Update : 2005/10/06
HOME
レポート
先進事例レポート
インターネットアンケート
連載コラム
Jakob NielsenのAlertbox
黒須教授のLecture
User's Voice
Reference
ユーザビリティとは?
イベント情報
関連書籍情報
リンク集
iid
Jakob Nielsen博士のAlertbox
U-site

2005 年 9 月 12 日

ユーザビリティテストの時間配分

要約:
テスト時間の 40 %が、不必要なことに使われ、無駄にされている。ユーザが対象インターフェイスのデザインを使う様子を観察することに集中したほうが、遙かによい。

ほとんどのデザインチームは、ユーザの実際行動を観察する時間を、十分取っていない。もちろんほとんどの企業がユーザテストを全く実施していないのが実状だが、実施している企業でも、行動を観察する時間を十分取っていないのだ。

理想は、1 週間あたり 1 日(たとえば毎水曜日)を 4 人のユーザでテストを行う「ユーザテストの日」とすることだ。もちろん毎回新しいユーザを使う必要がある。各テストで新しいユーザを使うことは、テストユーザのリクルートにおけるガイドラインの 1 つだ。(実際には 7 つのガイドラインが、この話題に関係している。参加者を繰り返し使ってもよい例外を説明するガイドラインがいくつかあるからだ。)

コンスタントに新しいユーザをテストに参加させることによって、ユーザがデザインの機能を全て使い、ペーパープロトタイプで奇抜なアイディアを試し、競争相手のデザインをどのように使うかを観察することができる。週に 1 度のテストを行い、注意深く観察することによって、ユーザの真のニーズと行動に基づかない決定を省略することができる。

週に 1 度テストを行うことが理想ではあるが、そのように実施されることは、まず無い。私は、このペースでテストを実施できたプロジェクトをわずかしか知らない。そしてそのいくつかは、私自身が実施した物だ :-(

ほとんどの企業では自分たちが作ったデザインをユーザが実際に使うのを観察できる機会は数少なく、素晴らしい経験だ。この機会を最大限活かすべきなのだが、多くの企業はユーザとの貴重な時間を無駄にしてしまうことが多い。

時間を無駄にしてしまう物

一般的なユーザテストは、60 から 90 分だ。それより長いとユーザは疲れてしまい、2 時間以上のユーザビリティテストを実施するのは難しい。(2 日以上にまたがってテストすることは可能だが、そうするには異なる技法を用いる必要があり、私の経験から言えば実施されることはまれだ。)

60 から 90 分で何をすべきだろうか。インターフェイスを操作する上で、ユーザが自然に行動するように心がけよう。ここが、ユーザテストのユニークな点だ。人々がどのような意見を持っているかではなく、実際にどのように行動するかを観察することができるのだ。

不幸にも多くの企業は、ユーザにタスクを遂行させるよりも、ユーザの意見を聞き出すことに長い時間を割いてしまう。ユーザテスト以外にも、コメントや意見を集める素晴らしい方法はいくらでもある。フォーカスグループや、アンケートといった方法がよく使われる方法だ。ほとんどの場合、企業は既に 1 対 1 のユーザテストで採取可能な意見よりも遙かに多い意見を、顧客から集めているだろう。適材適所で各手法を用いるように心がけよう。

一般的に無駄に時間をつぶしてしまう物は以下のような事柄だ。

  • セッションを数多くの統計的な質問で始めてしまうこと。このようなデータは、ウェブサイトでのオンラインアンケートで集めたほうがよい。テストユーザに対しては、事前のスクリーニングと、テスト中の追加質問で間に合わせるようにしよう。
  • タスク後の主観的な満足度評価を質問すること。主観的な評価は、元々データとして弱い。調査研究のプロジェクトは別として、過度に細かい評価は、それを採取するのに要する時間だけの価値があることはまれだ。
  • 全体の評価について 1 つの質問をするのではなく、評価についての多数の質問をすること。たとえば、グラフィックの評価を聞くことは、バカらしい。もし見た目に関して何か強い気持ちがあれば、それが好きだろうが、醜いと思おうが、不適切だと思おうが、彼等はタスクの最中にそれを声に出すだろう。観察者がするべき質問は 1 つだけ、全体の満足度の評価だけだ。細かい事柄に関しては、タスクを振り返って評価してもらうより、ユーザのタスク中の行動に基づいて分析したほうが遙かに有効だ。
  • 新しい開発中の製品にユーザがどのように感じるかなど、セッションの最後に討論を行うこと。これもフォーカスグループのほうが、適している。また、プロトタイプのデザインに対するタスク中のユーザ反応のほうが、どのような物を好むかという彼等の仮説的な憶測よりも有効だ。憶測的なデータよりも、有効なデータを集めるのに時間をかけよう。たとえそのためにプロトタイプを数ページ多く作らなくてはいけなくてもだ。

これら無駄な物事は、個別には数分しかかからない。しかし合計すると、ユーザがタスクを遂行する代わりに、アンケート用紙を埋めるために 30 分も費やしてしまうような、ことになる。

洞察を最大限に活かす

いくつかのオーバーヘッドがテストには、どのような状況でもつきものだ。ユーザを出迎え、同意書(短い物が理想的)に目を通しサインしてもらい、テスト後にはデブリーフを行って、報酬を手渡さなければいけない。このようなオーバーヘッドは 5 分以内に収めるようにして、主観的な評価を採取するための時間も 5 分以内に収めよう。そうすることによって 90 分セッションの内、無駄を 11 %以内に収めることができる。

もしフォーカスグループ風のデータに 30 分、一般的なオーバーヘッド(儀礼的で定型的な記入用紙など)に 10 分費やすとしたら、90 分セッションの内 44 %が無駄になってしまう。

テスト時間の配分を行い、タスクを行うユーザを観察するための、まとまった時間を確保していることを確認しよう。これがプロジェクトにとって、テスト資源を最大限に活かす方法だ。最も有効で活用できるユーザビリティの洞察は、行動の観察から得られる物だ。貴方のキャリアのためにもよいだろう。ユーザビリティの分野で専門的な腕を磨くには、できる限りあり得る行動を幅広く観察しなければいけない。

年間どのくらいの時間、ユーザが実際に自分たちが作ったデザインを使ってタスクを行うことを観察しているだろうか。もし 20 時間以下ならば、もっとユーザテストを実施しなければいけない。たぶん、もっと行動データを生成できるように、テスト時間の振り分け直しも必要だろう。


翻訳:川崎幹人
ウェブ関連中心にデザイン、制作、ディレクション、評価を手がけるフリーランサー。

[ HomeAlertboxTop ]
Copyright(C) 2005 IID, Inc. All rights reserved.
info@usability.gr.jp