> > HCDの理解 in 名古屋 2011 Vol.3「ユーザー評価」

HCDの理解 in 名古屋 2011 Vol.3「ユーザー評価」

小川貴史

このエントリーをはてなブックマークに追加

ユーザー評価とは、ユーザーが実際に行った行動や感想(発話)から、どんな問題点があり、どんな改善ができるかを知る目的で実施されます。評価手法としては様々ありますが、今回は「プロトコル分析(短期ユーザビリティテスト)」を実習しました。ユーザーテストはタスク設計が重要になってきます。

去年に引き続き「HCD(人間中心設計)の理解 in 名古屋」に参加してきました。今年はVol.3の「ユーザー評価」からの参加です。講師は去年と同じく浅野智先生です。

人間中心設計プロセス図における「ユーザー評価」

図:人間中心設計プロセス図

ユーザー(ユーザビリティ)評価とは「特定の目的を果たすための効率性や有効性」を実際にユーザーに使ってもらうことで確認するテストのことです。ユーザーが実際に行った行動や感想(発話)から、どんな問題点があるか、どんな改善ができるかを知る目的で実施されます。

プロダクト製品などでは最終段階に行われるそうですが、Webサイト制作ではリニューアル前やリニューアル後のサイトで行われます。前任の制作会社の悪口を言うことで信頼を得るという作戦でも使われます(違)。

ユーザー評価は「人間中心設計プロセス図」における「要求事項に対する設計の評価」の「モニター短期評価(プロトコル分析)」になります。

実習:課題サイトを「プロトコル分析(短期ユーザビリティテスト)」

30分ほどの座学の後は、ひたすら実習でした。各グループで課題サイトを「プロトコル分析(短期ユーザビリティテスト)」していきます。私の班の課題サイトは「名古屋市科学館」でした。

実習は以下の流れで行われました。

  1. タスク(アクティビティ(抽象的))とゴール(インタラクション(具体的))を決める。
  2. エキスパート(専門家)テスト(1名)
  3. ノービス(初心者)テスト(2名)
  4. 行動と発話の書き起こし
  5. NE比解析
  6. 発表

ユーザーテストはタスク設計がカギ

タスクとは、ユーザーテストで被験者に行ってもらう何らかの作業のことをいいます。

"ユーザーテストはタスク設計がカギ"というのは、ユーザビリティエンジニアの共通認識

引用元:それはタスクではない!

というほど重要のようです。

去年受講した経験から少し慎重に決定しました。最後の発表の際に浅野先生から「タスクは、まあ問題ないか」との言葉をもらったので、そんなに間違ってはいないのかなと思っています。

仮の状況(コンテキスト)
父親(35歳)が子供(3歳)に「プラネタリウム」を見せたいと思っている。一緒にTVCMで見た「竜巻ラボ」も見ていきたい。
タスク(アクティビティ(抽象的))
  1. 車でのアクセス方法を知りたい。
    なるべく安い駐車場料金も知りたい。
  2. 今日のプラネタリウムの空席状況が知りたい。
  3. TVCMで知った「竜巻ラボ」の夏休み平日のタイムテーブルが知りたい。
  4. プラネタリウムの子供向けプログラムの内容が知りたい。

タスク設計の基本

タスク設計は以下の基本を元にすると正しく作りやすいそうです。

基本:
仮の状況(コンテキスト)+目的(ゴール)+してください
タスク例:
仮に、あなたは今夜7時に渋谷で友人と待ち合わせをしているとします。仕事の都合で、待ち合わせ時間を7時半に変更したいと思います。この携帯電話を使って、変更時間をメールで連絡(送信)してください。
引用元:ユーザーテストの"マル秘"タスク設計法

エキスパートテストとノービステスト

ユーザーテストは、タスクを決めた班のメンバー1人が行うエキスパートテストと、他の班から被験者を2名借りてきて行うノービス(初心者)テストになります。タスクごとにどれぐらい時間がかかったか、どんな行動・発話をしたかを観察します。ちなみに、ユーザーテストで評価するのは、ユーザーではなくサイトデザインです。

ユーザーテスト注意点
  1. 最初にタスクを声を出して読ませる(滑舌を良くする)
  2. モデレーターは常に発話を促す(人は熱中すると無口になる)
  3. 被験者の質問に答えない。(例:これでいい?)
  4. 質問には「自分で考えてください。」と答える。
  5. 最後に「終了しました。」と言ってもらいテスト完了。
  6. テスト終了後、感想をインタビューする。これが大切!

失敗談

エキスパートテスト中に「あっ、このタスクまずい」と思い、タスクを直してしまったのですが、その様子を見ていた浅野先生に怒られてしまいました。「それじゃあ、正確なテストができんじゃないか!ダメだよ!馬鹿たれ!(一部誇張)」と。

エキスパートテストの定義に関しては、今でもイマイチよくわかっていません。なにをもってエキスパート(専門家)と呼ばれるのでしょう...。この時は、とりあえず同じ課題を与えられていた他の班から被験者を借りてきてエキスパートテストとしました。

NE比解析

NE比解析とは、Novice(初心者)とExpert(専門家)の頭文字をとったもので、決めたタスクごとにエキスパートとノービスの操作に要した時間を比較して、問題のある操作ステップを把握する評価手法です。

NE比 = Tn / Te
  • Tn:ノービスユーザーが要した平均時間
  • Te:エキスパートユーザーが要した平均時間

グラフ:ノービス平均とエキスパートの操作時間の比較 グラフ:NE比のグラフ化

NE比が大きいほど、ユーザビリティ上の問題が多い操作ステップとなります。一番時間のかかった箇所が一番問題のある箇所ではありません。ようするに「専門家が簡単であろうと考えていたその操作ステップは、初めて使う人にとっては難しい操作ステップだった。」ということがわかるのです。

失敗談

通常、NE比を元に問題のある箇所を見つけ、発話などから改善案を導き出していくのですが、我が班は、NE比を横目にタスク全部の改善点を導き出そうとしてしましました。結果、発表資料を作る時間が無くなってしまう羽目に...。

まとめ

先ほども書きましたが、HCDセミナーは2回目の受講になります。それもあって去年に比べてだいぶ理解が進んだ気がします。ユーザーテストを行う案件がまだまだ少なく、業務に取り込もうにもあまり機会がないという状況ですが、部分的にでもいいのでこの技法を活用していこうと思います。(カードソートは最近、頻繁に使うようになってきました。)

発表資料を作る時間が足りず中途半端な発表になってしまい、かなり凹みましたが参加してよかったです。

次回の「HCD ペルソナ・シナリオ法」は、失敗しないように予習しておこうと思います。

このエントリーをはてなブックマークに追加

読者のコメント

コメントを投稿

コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。

(HTMLタグは使用できません)

トラックバック

このエントリーのトラックバックURL
http://www.ibnet.ne.jp/mt/mt-tb.cgi/1032

ホーム > 勉強会&セミナー > HCDの理解 in 名古屋 2011 Vol.3「ユーザー評価」

このページの先頭へ