ユーザインタフェース 第１ １回 ユーザビリティ評価法

果てしない議論 新製品や Web サイトの設計会議は宗教戦争？ – 管理者、マーケティング、プログラマ、デザイナ がそれぞれの立場から発言 – どれもまともな要求 – すべての要求を取り入れる ことは不可能 – でも、だれも引き下がらない 取捨選択のための判断基準 – 何を取り入れて何を捨てるかの判断が必要 絶対無二の解 – テスト – 一般のユーザに使ってもらう – ユーザのふるまい に聞け

ユーザビリティ評価の復習 総括的評価 – 定量的評価を目的 – プロジェクトの前後で実施 形成的評価 – 問題点発見が目的 – 開発中に繰り返し実施 分析的手法 – 専門家が知識や経験に基づいて評価 実験的手法 – ユーザに実際に使ってもらい、データを収集する

何を評価するか（復習） ＩＳＯ９２４１でのユーザビリティの定義 特定のコンテキストにおいて、特定のユーザに よって、ある製品が、特定の目標を達成するため に用いられるさいの、 効果 ・ 効率 ・ 満 足度 の度合い 効果 (effectiveness) – ユーザが目標を達成できるか。もっとも重要。 効率 (efficiency) – できるだけ最短経路で目標を達成できる。 満足度 (satisfaction) – ユーザに不愉快な思いをさせていないか。

ユーザ中心設計をまとめると 調査する – 師匠・弟子のコンテキスト調 査法 分析する – シナリオ／ペルソナ法 プロトタイプを作成する – プロトタイプ／カードソート 評価する – ヒューリスティック評価法 – 思考発話法，回顧法 – パフォーマンス測定

ヒューリスティック評価法 専門家がガイドライン と照らし合わせて評 価 別名、専門家レビュー ガイドラインとして有名なもの – ヤコブ・ニールセンの １０ヒューリスティックス – シュナイダーマンの８つの黄金律 – ＩＢＭの設計の原理 – ＩＳＯ９２４１ Part-10 – Ｗｅｂについては クルーグの原則 レポートは実はユーリスティック評価 Jakob Nielsen Ｓｔｅｖｅ Ｋｒｕｇ

ヤコブ・ニールセンの１０の ヒューリスティックス 1. システム状態の視認性（ Visibility of system status ） 今、どういう状態にあるかを常にユーザに知らせているか。 Windows の砂時計、ウェブページのパンくずリスト 2. システムと実世界の調和 （ Match between system and the real world ） ユーザになじみのある言葉、習慣で情報を提示しているか。 ゴミ箱、ショッピング・カート、右矢印は進むで、左矢印は 戻る 3. ユーザコントロールと自由度 （ User control and freedom ） 常にユーザが動作をコントロールできる状態にあるか Web でのトップページへのリンク, Flash 動画のスキップボ タン 4. 一貫性と標準化 (Consistency and standards) 操作性や用いられる用語は一貫しているか Web の習慣に従う。リンクラベルとその先のページタイトル を一致

ヤコブ・ニールセンの１０の ヒューリスティックス 5. エラーの防止 (Error prevention) エラーの発生そのものを防止するような工夫がなされてい るか Web の電話番号入力フォームで、ハイフンはあってもなくてもよ い 6. 記憶しなくても見ればわかるように (Recognition rather than recall) 操作や情報を覚えずとも見れば判るようになって いるか。 ショッピングカート中の商品は番号でなく品名，注文内容をメー ルで送信 7. 柔軟性と効率性 (Flexibility and efficiency of use) 上級者にはショートカットやカスタマイズの機能があるか。 ブラウザのブックマーク、日本語変換の辞書登録

ヤコブ・ニールセンの１０の ヒューリスティックス 8. 美的で最小限のデザイン (Aesthetic and minimalist design) 情報を詰め込みすぎていないか。 適切な画像、空白の利用 9. ユーザによるエラー認識、診断、回復をサ ポート (Help users recognize, diagnose, and recover from errors) エラーメッセージはわかりやすく、解決策が提示されてい るか エラー番号でなく、エラーメッセージを示す 10. ヘルプとマニュアル (Help and documentation) わかりやすく簡潔なヘルプやマニュアルがあるか FAQ を用意する

ヒューリスティック評価実施の 手順 1. 評価計画を立てる – インタフェースのどの部分を評価するかを定義 – 基準とするヒューリスティックス を決める 2. 評価者を集める – ニールセンによると 5 人いればかなり正確 – 少なくとも 3 人以上 3. 個別評価を実施する – すべての人が相談なしですべてのインタフェースを評 価 4. 評価者ミーティングを実施する – 他の評価者の意見を 否定する ことは禁止 – 多くの評価者が同じ問題を見つけることは、まれ 5. 評価結果をレポートにまとめる

実施コスト 専門家を 3 人も用意するのは高コスト 評価者をさらに絞ることもある。 「個人の感想でないか」という批判を受 ける可能性 以下の点に注意して簡易レビューを実施 する – 好き嫌いでなく、論理的に評価する – 評価というよりも、アドバイスするつもりで – 意見が分かれれば、議論せず、実験的手法で 結論を出す。

ここで評価法をサーベイ！ 分析的手法 実験的手法 総括的評価 形成的評価 ヒューリスティッ ク評価法 パフォーマンス測 定 思考発話法 回顧法

実験的手法によるユーザテスト 別名、ユーザビリティ・テスト ユーザがシステムと格闘する様子を、開発者が マジックミラーで仕切られた隠し部屋から観察 する – 必ず 1 人ずつ順番にテストす る – ユーザにタスク（作業）実 行を依頼 – ユーザがタスクを実行する 過程を観察、記録 隠し部屋つきのテスト室を、ユーザビリティ・ラボ という 手前が、開発者が見ている隠し部屋

パフォーマンス測定 プロジェクトの前後で成果を示す場合に 実施 – 定量的データ収集を目的 – 実験的手法 による、総括的評価 [ 例 ] 家電品のインタネット販売サイトで、 ショッピングカート放棄率が何％向上したか ターゲットユーザごとに 20 人以上 は 必要 – かなりの高コスト – 経営トップは好むが、定量的データの必要性 が明確でない限り、実施しない

定量値の測定方法 効果 – タスク達成率 を測定 – ユーザが正確にゴールに到着する確率 効率 – タスク達成時間 を測定 – ユーザがタスク達成に費やした時間 締め切りを設け、それを超えるとタスクは未達成とみ なす。 満足度 – アンケートなどの 主観的評価 で求める – タスク終了後に 5 ～ 10 段階で評価 規格化されたアンケートが存在、ただし、有料

パフォーマンス測定の短所 多数ユーザからの多様なデータが獲得で きるので ユーザビリティの非専門家 は大好き 「ここが良くない」というのはわかるが、 「なぜできないのか」という問いには答 えられない。 実施するうえでの コストが高い 最終的な改善結果を示すために、開発プ ロジェクトの 前後で 実施。 開発プロジェクト中は 形成的評価 を 実施