ユーザー中心設計（UCD: User Centered Design）について体系的にまとめられたユーザビリティエンジニアリング(第2版)―ユーザエクスペリエンスのための調査、設計、評価手法―の「Part3 評価」の部分を読んだので、学んだことや所感、いわゆる読書ログをまとめます。
過去の章の読書ログはこちらです。
ユーザビリティ、UX、ユーザー中心設計の概要。
インタビュー、ペルソナについて。
アイディアの発想法やプロトタイプについて。
この章は名前の通り、ユーザー中心設計のプロセスの「評価」（解決案の評価）に対応する部分です。本書の中でも1番ボリュームが多いかつ、UCDのプロセスの中でも最重要の部分（評価と改善を反復することがUCDで最重要とされている）です。
総括的評価と形成的評価
評価は学校の期末試験のように学習成果の総合的な達成度合いを測定するための「総括的評価」と、小さい学習単位ごとに、どれくらい理解できているか、理解するために何をしなければならないかをフィードバックするための評価である「形成的評価」に大きく分けることができます。
形成的評価の例は英会話スクールであり、得点をつけることが目的ではなく、理解度を”改善”することが目的です。
ユーザビリティ評価も以下のように総括的評価を形成的評価を区別することができます。
- 総括的評価：パフォーマンス測定（タスク達成率◯％、平均タスク達成時間◯分◯秒など）
- 形成的評価：ユーザーテスト（数名のユーザーに考えていることを口に出しながら製品を使ってもらう。成果は「送信ボタンをキャンセルボタンが近く配置されているので間違って押してしまう」みたいな具体的なもの）
ユーザビリティ評価では以下の2つを理解しておくことが重要です。
- 総括的評価（パフォーマンス測定）は設計プロセスの”前後”で用い、形成的評価（ユーザーテスト）は設計プロセスの”途中で繰り返し”用いる。
- 総括的評価しか行わないのであれば、それは全く無駄な投資である。
なぜ、総括的評価だけしか行わないのはダメなのかというと、パフォーマンス測定で分かった失敗の原因がわからないからです。例えば、タスク（目標）達成度が60％という結果が出たとして、達成できなかった40％のユーザー体験にどのような問題があったのかがわかりません。ユーザービリティテストに限らず、総括的評価は、（形成的評価を繰り返すことで）コツコツと努力を積み重ねた後に、その成果を把握するために実施するべきです。
ヒューリスティック評価
ヒューリスティック評価とは、ヤコブ・ニールセンが数多くのユーザビリティ問題を分析し、抽出した「10ヒューリスティックス」と呼ばれるユーザビリティ問題の背後に存在する原則を根拠として、評価対象の製品が犯している”ルール違反”を探索する手法です。（ヒューリスティックは「経験則」という意味）
10ヒューリスティックスの説明はこちらの記事に譲りますが、項目だけ改めて本記事には載せておきます。
- システム状態の視認性（デザインは、妥当な時間内に適切なフィードバックを通じて、今、何が起こっているのかを絶えずユーザーに知らせる必要がある。）
- システムと実世界の一致（デザインは、ユーザーの知っている言葉によって情報を伝える必要がある。内部向けの専門用語ではなく、ユーザーに馴染みのある語句や概念を使おう。現実世界の慣例にのっとり、自然で論理的な順序で情報を提示しよう。）
- ユーザーの主導権と自由（ユーザーは、誤ってアクションを実行してしまうことがよくある。そのため、「非常口」を明確に示して、長いプロセスを経なくても、望まないアクションを彼らがやめられるようにしなければならない。）
- 一貫性と標準（ユーザーに、異なる言葉や状況、アクションが同じことを意味するかどうかを疑問に思わせてはならない。プラットフォームと業界の慣例に従おう。）
- エラーの予防（エラーメッセージは適切であることが重要だ。しかし、最も良いのは、細心の注意を払って、そもそも問題が発生しないようなデザインにすることである。エラーが発生しやすい状況をなくすか、エラーの状況を確認して、ユーザーがアクションを行う前に確認オプションを提示しよう。）
- 再生より再認（要素やアクション、選択肢を表示して、ユーザーの記憶への負荷を最小限に抑えよう。インタフェースのある部分の情報を別のところで思い出させるようなことをしてはならない。デザインを利用するために必要な情報（フィールドラベルやメニュー項目など）は、表示されているか、必要に応じてすぐに取得できる必要がある。）
- 柔軟性と効率性（ショートカット（初心者には見えない）は、経験の浅いユーザーも経験豊富なユーザーの両方に対応できるデザインで、エキスパートユーザーのインタラクションを高速化することができる。頻繁に行うアクションをユーザーが自分の好みに合わせて調整できるようにしよう。）
- 美的で最小限のデザイン（インタフェースに無関係な情報や、めったに必要のない情報を入れてはならない。インタフェース内の余分な情報はすべて、関連する情報と競合することになり、関連する情報の相対的な可視性が低下するからだ。）
- ユーザーによるエラーの認識・診断・回復のサポート（エラーメッセージは、（エラーコードではなく）わかりやすい言葉で表現され、問題を正確に示し、建設的に解決策を提案する必要がある。）
- ヘルプとドキュメンテーション（システムは、追加の説明が必要ないのが一番だ。とはいえ、ときにはユーザーがタスクを完了する方法を理解するのに役立つドキュメンテーションの提供が必要なこともある。）
ヒューリスティック評価は、ユーザー中心設計の代表的な手法として世界中で知られています。本評価表の優れている点は、「複数」の評価者がヒューリスティックスという「根拠」に基づいて評価するため、単なる専門家よりも精度と客観性に優れています。ただし、本評価法は他の評価方法と同様万能ではなくデメリットもあります。
- 問題点を見つけすぎること
- コストが意外とかさむこと
- 評価の根拠であるヒューリスティックスがあまり知られていないこと
先ほど「ヒューリスティック評価は、ユーザー中心設計の代表的な手法として世界中で知られています。」と書いたので、「評価の根拠であるヒューリスティックスがあまり知られていないこと」と矛盾していそうですが、ユーザビリティ評価の専門家の間では有名なだけで、一般人はもちろん開発者やデザイナであってもヒューリスティックスを知らなかったり、知っていても十分に理解していない場合があり、開発・設計チームの共通語としては利用しづらいことがデメリットとして挙げられています。（ヒューリスティック評価の報告をする際にまずヒューリスティックの解説から始める、というケースもあるよう…笑）
ユーザーテスト（ユーザビリティテスト）
代表的なユーザーテストには以下の手法があります。
思考発話法
ユーザーに「考えていることを話しながら操作してもらう」ことで、単にユーザーが
- 失敗した
- 戸惑った
- 不満を述べた
という事実の発見に留まらず、
- なぜ失敗したのか
- なぜ戸惑ったのか
- なぜ不満を述べたのか
まで明らかにできる、非常に強力な手法です。
思考発話方では以下の3つのポイントを観察します。
- ユーザーが独力でタスク（作業）を完了できるかどうか：効果問題の測定（最重要）
- ユーザーがゴールに到達するまでに無駄な操作を行ったり、戸惑ったりしていないかどうか：効率問題の測定
- 不満の有無：満足度問題の測定
回顧法
操作が終わってから質問に答えてもらう方法のことを回顧法と言います。
回顧法のメリットは
- ユーザーは普段と同じように（しゃべらずに）操作すれば良いので、事前な状態でテストを実施できる
- 操作が終わってから質問するので、途中で操作に関するヒントを不用意にユーザーに与えてしまう心配がない
ですが、デメリットとして
- 効果問題（タスクを達成できるかどうか）を明らかにできないことが多い
- 例えば、ユーザーがタスクの達成に失敗した後に「なぜ失敗したのか？」という質問をしてもその質問に答えられるならタスクは失敗していないから
- ユーザーは自分の行動について、後からもっともらしい理由をつけてしまいがちなのでユーザーが操作している時に感じていたことを正確に引き出せない可能性がある
- テスト時間を消費する
などがあります。
パフォーマンス測定
思考発話法、回顧法はどちらも形成的評価ですが、数値データを集めて活用したい時には総括的評価である「パフォーマンス測定」を実施します。
パフォーマンス測定ではユーザビリティ3要素である効果・効率・満足度に関係した量的データを測定します。
- 効果：タスク達成率
- 効率：タスク達成時間
- 満足度：主観的評価
3つ目の「主観的評価」だけかなち抽象的でわかりづらいですが、主観的評価の方法の一例として、ユーザーに「難易度」「好感度」「再利用意向」などの質問を行い、5〜10段階で回答してもらいます。
パフォーマンス測定に関しては、前述した通り、測定結果は詳細のデータを含まない”数値としての結果”のみなので、「なぜこの結果になってしまったのか？」を読み取ることができません。なので、製品を行う設計・開発チームにおいて、パフォーマンス測定は役立ちません。思考発話法や回顧法などの形成的評価と組み合わせて、フェーズによって使い分けることが重要です。
（パフォーマンス測定はプロジェクトの前後、形成的評価（思考発話法、回顧法）はその途中で繰り返し実施するのが望ましいです）
ユーザーテストの基本理論
ユーザーテストは「反証」を目的とした行為です。
反証とは、その仮定的事実や証拠が真実でないことを立証すること。そのための証拠。
ユーザビリティを実証するためには反証アプローチを用います。反証アプローチは以下のプロセスで行います。
- 「この製品はユーザブルである」という仮説を立てる（ユーザー調査やヒューリスティック評価に基づいて評価）
- この仮説を確かめるために複数のユーザーにいくつかのタスクを実行してもらい、分析する
- そのユーザーテストで効果・効率・満足度に問題があればそれが仮説に対する”反証”になり、「この製品はユーザブルである」という仮説は崩れる
- 反証が見つかればすぐに改善案の検討を開始し、改善できれば再び仮説が成り立つ
- 2〜4を反証が起こらなくなるまで繰り返し実施し、仮説が崩れない状態にする
話は変わりますが、ヤコブ・ニールセン（10ヒューリスティックスの考案者）はテストする人数と発見できるユーザビリティ問題の数に関する公式を明らかにして
「5人のユーザーでテストすれば、ユーザービリティ問題の大半（約85％）を発見できる」
という説を唱えました。
この「ユーザーテストは5人で十分」は鵜呑みしてはいけないです。ヤコブ・ニールセンの公式では問題の数にフォーカスしており、問題の質にはフォーカスしていません。よって、全体のユーザビリティの約85％を発見できたとしても残りの15％のユーザビリティ問題に重大なもの（＝効果問題に影響するもの）があった場合、この5人のテストは十分とは言えません。
5人でテストする本当の意味とは、小規模なテストでも大規模なテストに匹敵する（わずか5人で大規模なテストの約85％の成果が得られる）ことを明らかにして、もっと積極的にテストを実施すべきだという主張です。
（予算やスケジュールに余裕がある大型プロジェクト以外ではテストは行えない、という誤った思い込みを多くの設計者が持っていた）
よって、「5人のユーザーで1回テストすれば製品は合格点に達する」という解釈は全くの間違いであることを認識すべきだと本書では説明されています。
まとめ
最後にこの記事の内容をまとめます。
- 評価は「総括的評価」と「形成的評価」に大別できる
- ユーザビリティ評価では総括的評価（パフォーマンス測定）は設計プロセスの”前後”で用い、形成的評価（ユーザーテスト）は設計プロセスの”途中で繰り返し”用いる。
- ユーザビリティ評価で総括的評価しか行わないのであれば、それは全く無駄な投資である。
- ヒューリスティック評価は、ユーザビリティ問題の背後に存在する10つの原則を根拠としてユーザビリティ評価を行うユーザー中心設計の代表的な評価手法である。
- ユーザーテストには思考発話法や回顧法などの形成的評価とパフォーマンス測定等の総括的評価がある。
- パフォーマンス測定の結果は設計・開発チームにとって役立たないので、必ず形成的評価手法を用いてユーザビリティを向上させていくことが重要。
- ヤコブ・ニールセンの「5人のユーザーでテストすれば、ユーザービリティ問題の大半（約85％）を発見できる」という説の本当の意味はどんなプロジェクトでも積極的にユーザーテストをすべきであるということである。
次は最終章の「Ending」に関する記事を書きます！ラスト！
お得に読書をするなら月額980円で200万冊以上の本が読み放題のkindle unlimitedがオススメです。
30日間の無料体験がありますので、少しでも気になった方はぜひ使ってみてください。
コメント