ユーザインタフェース 第7回

ユーザインタフェース 第11回
ユーザビリティ評価法
果てしない議論
• 新製品やWebサイトの設計会議は宗教戦争?
– 管理者、マーケティング、プログラマ、デザイナがそ
れぞれの立場から発言
– どれもまともな要求
– すべての要求を取り入れる ことは不可能
– でも、だれも引き下がらない
• 取捨選択のための判断基準
– 何を取り入れて何を捨てるかの判断が必要
• 絶対無二の解
– テスト
– 一般のユーザに使ってもらう
– ユーザのふるまい に聞け
ユーザビリティ評価の復習
• 総括的評価
– 定量的評価を目的
– プロジェクトの前後で実施
• 形成的評価
– 問題点発見が目的
– 開発中に繰り返し実施
• 分析的手法
– 専門家が知識や経験に基づいて評価
• 実験的手法
– ユーザに実際に使ってもらい、データを収集する
何を評価するか(復習)
ISO9241でのユーザビリティの定義
• 特定のコンテキストにおいて、特定のユーザによっ
て、ある製品が、特定の目標を達成するために用
いられるさいの、 効果 ・ 効率 ・ 満足度 の度
合い
• 効果(effectiveness)
– ユーザが目標を達成できるか。もっとも重要。
• 効率(efficiency)
– できるだけ最短経路で目標を達成できる。
• 満足度(satisfaction)
– ユーザに不愉快な思いをさせていないか。
ユーザ中心設計をまとめると
• 調査する
– 師匠・弟子のコンテキスト調査法
• 分析する
– シナリオ/ペルソナ法
• プロトタイプを作成する
– プロトタイプ/カードソート
• 評価する
– ヒューリスティック評価法
– 思考発話法,回顧法
– パフォーマンス測定
ヒューリスティック評価法
• 専門家がガイドライン と照らし合わせて評価
• 別名、専門家レビュー
• ガイドラインとして有名なもの
– ヤコブ・ニールセンの
10ヒューリスティックス
– シュナイダーマンの8つの黄金律
– IBMの設計の原理
– ISO9241 Part-10
– Webについては
Jakob Nielsen
クルーグの原則
レポートは実はユーリスティック評価
Steve Krug
ヤコブ・ニールセンの10の
ヒューリスティックス
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の習慣に従う。リンクラベルとその先のページタイトルを一致
ヤコブ・ニールセンの10の
ヒューリスティックス
5. エラーの防止(Error prevention)
エラーの発生そのものを防止するような工夫がなされているか
Webの電話番号入力フォームで、ハイフンはあってもなくてもよい
6. 記憶しなくても見ればわかるように
(Recognition rather than recall)
操作や情報を覚えずとも見れば判るようになっているか。
ショッピングカート中の商品は番号でなく品名,注文内容をメールで送信
7. 柔軟性と効率性
(Flexibility and efficiency of use)
上級者にはショートカットやカスタマイズの機能があるか。
ブラウザのブックマーク、日本語変換の辞書登録
ヤコブ・ニールセンの10の
ヒューリスティックス
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段階で評価
• 規格化されたアンケートが存在、ただし、有料
パフォーマンス測定の短所
• 多数ユーザからの多様なデータが獲得できる
ので ユーザビリティの非専門家 は大好き
• 「ここが良くない」というのはわかるが、「なぜ
できないのか」という問いには答えられない。
• 実施するうえでの コストが高い
• 最終的な改善結果を示すために、開発プロ
ジェクトの 前後で 実施。
• 開発プロジェクト中は 形成的評価 を実施