ユーザーエクスペリエンスの測定

ユーザーエクスペリエンスの測定 — UX メトリクスの理論と実践」という本を読みました。

ユーザーエクスペリエンスの測定 (情報デザインシリーズ)

UX デザインを評価するにあたり、ユーザーと製品 (たとえばウェブサイト) との間でのインタラクションにおける「有効性」「効率」「満足度」 (これらは ISO 9241-11 が定義しているユーザビリティの尺度でもあります) を数値によって測定し分析しようという主旨で、様々な測定手法が紹介されています。それらの測定手法のことを、本書では「UX メトリクス」と称しています。

UX をなぜ数値で測定する (定量的に評価する) のか

UX (≒ユーザビリティ) の評価は、ユーザビリティテスト (ユーザー行動観察)、ヒューリステック評価、認知的ウォークスルーなど、一般的には定性的評価が中心になります。そんな中、UX を数値で測定する (定量的に評価する) ことの意義は何だろう?という疑問が浮かぶかもしれません。

本書では「1.5 UX メトリクスの価値」で、UX を数値で測定することの意義を説明しています。要約すると以下のようになります。

UX メトリクスで何を測定するか

UX メトリクスで何を測定するのかについては、大別すると「パフォーマンス」と「満足度」があると本書には記されています。(参考 : 「3.2 ユーザーの目的」)

パフォーマンスの測定

ユーザーが製品 (たとえばウェブサイト) とインタラクションする際の「有効性」(目的を達成できたか) や「効率」(スムーズに目的を達成できたか) を計測するものです。タスクの成功/失敗、エラー件数、タスク時間、ゴール達成までの努力量 (クリック数や遷移ページ数など)、といった評価軸が含まれます。(参考 : 「4. パフォーマンスメトリクス」)

ユーザビリティテストの中で、ユーザー行動観察と並行して各種パフォーマンスを計測したり、すでに公開済みのサイトであればアクセス解析ツールで動線分析をしてみる、といった方法が考えられます。

満足度の測定

満足度を測定すると言われても、ピンと来ない方もいらっしゃるかもしれません。本書では「自己申告メトリクス」という名で、様々な手法が紹介されています。(参考 : 「6. 自己申告メトリクス」)

特にリッカート尺度 (参考 : 「6.2.1 リッカート尺度」) は使いやすそうです。これは、ある質問文に対して、「まったく同意できない」「同意できない」「どちらとも言えない」「同意できる」「非常に同意できる」という選択肢を提示し、ユーザーに選択してもらうものです。ユーザビリティテストのセッション (あるいは各タスク) の後に実施することができそうです。

また、リッカート尺度をベースに汎用的な設問を用意したものとして、SUS (System Usability Scale) があります (参考 : 「6.4.2 システムユーザビリティ・スケール (SUS)」)。SUS は自由に使えるよう公開されており、また、少ないサンプル数 (8人~10人程度) でも比較的信頼度が高いデータが取れるようなので、様々なベンチマーク評価でも使いやすそうです。

より自由なフォーマットでユーザーの満足度を聞き出す手法として興味深いのは、ユーザビリティテストのセッション後に、製品についてもっとも好きだった点を3つほど、もっとも嫌いだった点を3つほど、自由記述で書かせるというアイデアです (参考 : 「6.7.3 自由記述式の質問」)。定量的にデータを分析するには少し工夫が要りそうですが、導入はしやすそうです。

UX メトリクスをどう実践的に活用するか

ほかにも、本書にはたくさんの手法やノウハウが紹介されており、いろいろと勉強になりました。

少し横道に逸れますが、「パフォーマンス」や「満足度」の測定だけでなく、IA 設計時に使えるメトリクスとしてカードソーティングの分析方法についても触れられていたりして (参考 : 「9.2 カードソートのデータ」)、その点でも興味深かったです。

ただ、勉強にはなったものの、どう実践しようかと考えると「もやっとした」のも正直なところです。複雑なメトリクスや分析法に圧倒されたというのもありますが、その結果として次のアクションにつながる具体的なイメージが (大半のメトリクスの解説を読んでいて) わかなかったからです。

特に総括的調査としてまとめた場合 (参考 : 「3.1.2 総括的ユーザビリティ調査」)、単なる上層部へのレポーティングで終わってしまう (「よかったね」と総括されて終わる) ケースが少なくないような気がします。せっかくの UX メトリクスを、実践的に活用するには、どうしたらよいのでしょうか?

KPI と絡めて実践する

個人的には、UX (≒ユーザビリティ) の定量的な測定は KPI と絡めるのが、組織 (チーム) としても取り組みやすいのかな、という気がしています。KPI (Key Performance Indicator : 重要業績評価指標) とは、ビジネスゴールを達成するための構成要素 (大小様々な、手段やプロセスなど) について、具体的な数値目標を定め、達成度を計測するものです。

KPI は小さくても (また特に初めは仮説でも) よいので、「自社のビジネスゴールは■■で、その■■に▲▲の面で貢献するためにウェブコンテンツがある。▲▲の達成度合いは●●という数値で測ることができる」という具合にロジカルに設定します。そのうえで、あくまで PDCA を回す手掛かりを得る目的で、ユーザビリティテストのセッションやアクセス解析などを通じて KPI を測定し、目標値よりも悪ければ xx の可能性がある、と仮説を立てて実際に改善し、再び KPI を測定してみるのです。

総括的調査としてではなく、改善を目的とした形式的調査 (参考 : 「3.1.1 形式的ユーザビリティ調査」) としてまとめるのであれば、6~8人程度の参加者がいれば十分という著者の知見もあるので (参考 : 「3.4.3 参加者」)、このように小さく PDCA を回してみる、というのが UX メトリクスを実践する第一歩としてはやりやすいのかな、と感じました。