カスタマーエクスペリエンスに基づくマーケティング戦略
HCD-Net通信
「人間中心設計(HCD)」を効果的に導入できるよう、公の立場で研究や人材育成などの社会活動を行っていくNPO団体「人間中心設計推進機構(HCD-Net)」から、HCDやHCD-Netに関連する話題をお送りしていきます。

HCD-Net通信
ヒューリスティック評価法の99%は間違っている? /HCD-Net通信 #15

これまでのヒューリスティック評価法はエキスパートレビューだったのだ。
[AD]

ヒューリスティック評価法とは、評価者がユーザビリティガイドラインにもとづき、自分の直感と洞察を駆使してユーザビリティの問題点を発見する方法で、1990年にJakob NielsenとRolf Molichが開発した。日本でも2000年に入った頃からよく使われるようになり、今ではユーザビリティテストに次ぐ利用頻度を持っていると思われる。

UPA 2009 International Conferenceにて

米国に本部を置くユーザビリティ専門家の国際組織。毎年北米の主要都市を中心に、世界各国のユーザビリティ関係者を集めたカンファレンスを行っている。2009年のカンファレンスは米国のポートランド州オレゴンで6月8日~12日の5日間開催された。

今年は久しぶりにUPAのカンファレンスに参加したのだが、その中の「ヒューリスティック評価法の使用と乱用(原題: Heuristic Evaluation: Use and Abuse)」というセッションには、ヒューリスティック評価法の開発者であるJakob NielsenとRolf Molichがパネリストとして登壇していた。ヒューリスティック評価法の現状を知るにはちょうどいい内容だと思われた。

しかし、Molichはいきなり意見表明で「(現状の)ヒューリスティック評価法の99%はよくないものだ」と切り出したのだった。もちろんこれは冗談だが、会場にどよめきが走った。彼の論旨は明快で、「ヒューリスティック評価法は有名な10のガイドラインに沿って評価を行う手法であり、必ずしもユーザビリティ専門家が行うものではない。一方で、一般にヒューリスティック評価法とされているものはユーザビリティ専門家が自分の経験にもとづいた洞察によって問題点を見いだすエキスパートレビュー(Expert Review)である」というものだった。ちなみにこの「Expert Review」という用語については、熟練者レビューや熟達者レビュー、さらには専門家レビューなどという訳語も考えられるが、ここではエキスパートレビューのままにしておく。

ヒューリスティック評価法はNielsenとMolichが共同で開発した手法だが、現在MolichはNielsenが所属するNielsen Norman Groupからは離れて、Dialog Designというコンサルタント会社で活動し、Nielsenとは距離を置いた形になっている。そうした内部事情はさておき、Molichの指摘には耳を傾けるべき部分が多い。

会場からも、自分たちがやってきたのはたしかにエキスパートレビューだという声が多くあがったし、著者自身もそう感じたうちの1人だった。これまでヒューリスティック評価法を効果的に実施するためには、ユーザビリティテストの経験が1~2年あって、ユーザーの行動パターンが予測できるようになっていなければならないと言ってきたし、ヒューリスティック評価法を実施するといいながら、10のガイドラインよりは、むしろユーザビリティ専門家としての経験にもとづいた洞察で問題点を発見するように指導してきた。

こうした指摘に対してNielsenは渋い顔をしながら自説を述べていたが、あまり説得力はなく、ついには「あなた(Nielsen)がヒューリスティック評価法を行う際、10のガイドラインを問題発見のために使うのですか、それとも発見された問題を整理するために使うのですか」という質問が出る始末だった。実はエキスパートレビューをやっていたのではないですか? という問いかけを受けたのだ。

今後はどのように評価すればいいのか

Molichが指摘したように、ヒューリスティック評価法を10のガイドラインに即して問題点を発見する手法とするのなら、それはあまりに硬くて柔軟性に欠け、また十分な問題発見はできないだろう。やはり問題点を検出するためには、ユーザビリティに関する経験をもった専門家がチェックを行う必要があり、つまりそれはエキスパートレビューだということになる。しかし、本当に十分な問題摘出をしたかどうかを確認する(問題摘出の妥当性を高める)ためには、ユーザーを利用した他の方法で補う必要がある。

そういった意味では、Molichも指摘していたようにエキスパートレビューとユーザビリティテストを組み合わせるというのが一番良い方法だと思われる。エキスパートレビューは、必ずしもタスク実行の手続きにしたがってインターフェイスをチェックしないので、問題摘出が浅くなる可能性がある。一般に言われるように、エキスパートレビュー(これまでヒューリスティック評価法といわれていた手法)は広く浅く問題点をチェックするものであり、ユーザビリティテストは範囲は狭いが深く問題点をチェックする手法である。

認知的ウォークスルー

評価者が想定されるタスクに沿って実際にシステムを利用しながら、ユーザーの思考過程や行動を推測して問題点を抽出する評価手法

もちろん、エキスパートレビューであっても認知的ウォークスルーのようなやり方にすれば、ユーザビリティテストのように各操作ステップを追ったチェックができるが、厳密に認知的ウォークスルーを使おうとすると手間がかかって時間を浪費してしまう。そのため、エキスパートレビューはある程度操作手順を追いつつも、広く浅くユーザビリティの問題をチェックするものと考えるべきだろう。言い換えれば、デザインの初期の段階でエキスパートレビューを行って問題点の洗い出しをしておくのだ。その結果をもとにデザインに修正を加え、ユーザビリティテストを行う段階では、簡単に検出されるような問題点はあらかじめ取り除かれた状態にしておくのである。そうすればユーザビリティテストをより効果的に利用できる。

構造化ヒューリスティック評価法という考え方

著者自身、構造化ヒューリスティック評価法(sHEM: Structured Heuristic Evaluation Method)という手法を提案し、UPAでも発表をしていて、外国でもわずかだが利用者がいる。この手法の趣旨は、評価者の注意制御を行う点にある。一度に10のガイドライン、さらにはその詳細なポイントを頭に置いて評価するのは、人間の注意容量の限界を超えてしまう。そこで、評価セッションを複数のサブセッションに分け、あるサブセッションではハードウェア的な側面、別のサブセッションではソフトウェア的な側面、次はアクセシビリティに関する面などというようにサブセッションごとに評価する側面を切り替えるというものだった。前に書いたように、著者がヒューリスティック評価法と考えていたのは実際にはエキスパートレビューだったわけだが、その場合でもsHEMの考え方は適用できると考えている。ただ名称はsHEMからsER(Structured Expert Review)に変更しなければなるまい。

なお、画面インターフェイスに関する評価であれば、ペーパープロトタイプを作成し、それを利用したユーザビリティテストを行う方法がある。ただしその場合も、最初からユーザビリティテストを行うのではなく、プロトタイプができた段階でエキスパートレビュー(特に手順を追いながらインターフェイスを調べるウォークスルー)をしておくのは効果的である。また、ペーパープロトタイプといっても、いきなり手順を追った画面プロトタイプを作るわけではなく、画面構成や画面遷移、システム構成などを考慮したうえでタスクを設定し、そのタスクに関してプロトタイプを作る。したがって、タスク設定をする前の段階ではユーザビリティテストは実施できないので、その段階ではエキスパートレビューが必要だということになる。

このような形で、エキスパートレビューとユーザビリティテストを組み合わせて評価を行うのが現在のところ一番良いやり方だと言える。残念なことではあるが、オリジナルのヒューリスティック評価法(ユーザビリティ専門家以外が行う評価)の考え方は、今後消滅していくことになるだろう。

[AD]
この記事が役に立ったらシェア!
tweet30このエントリーをはてなブックマークに追加

日本オラクルからのお知らせ

Oracle WebCenter Sites(WCS)とは?

カスタマーエクスペリエンスの理解を深めるピックアップ記事

記事ピックアップカスタマーエクスペリエンスを理解、実現するためにチェックしておきたいコラムや解説記事をピックアップ

Facebook

みんなが読んでるWeb担メルマガで、あなたも最新情報をチェック
  • SEOやアクセス解析のなどノウハウをゲット
  • 事例やインタビューも見逃さない
  • 要チェックのセミナー情報も届く
  • 編集長コラムを一足先に読める

オラクルダイレクト

あなたにいちばん近いオラクル 「Oracle Direct
システムの導入や提案を支援する日本オラクルのご相談窓口 Oracle Direct ご質問・ご要望にスピーディにお応えします。電話受付時間:0120-155-096(祝日及び年末年始休業日を除きます)