ユーザビリティエンジニアリング(ISBN:4274201449)

book 読書ノート

『誰のためのデザイン?』(ISBN:478850362X)みたいなのを期待したら全然違っててがっかり。

  1. ユーザビリティとユーザ中心設計
    1. ユーザビリティ≠使いやすさ
      1. ユーザビリティはオマケ?
        • 「使いやすさ」→思いやり、ユーザフレンドリ→プラスαの要件
        • ユーザビリティ＝「使用可能性」
      2. 使いモノにならない!
        • 使いモノにならない→使用不可能
      3. ユーザビリティの定義
        • ISO 9021
        • 効果(effectiveness)::目標を達成できるか？
        • 効率(efficiency)
        • 満足度(satisfaction)::不愉快な思いをさせていないか？
    2. 失敗の原因
      1. ゴムのユーザ
      2. コンテキスト(context)
      3. ユーザ体験の店点と線
        • 全体から重大な問題点を取り除いても、ユーザの不満はあまり改善しない。
        • 「"重要な経路"には、まだ問題がいくつも残っている」
        • ユーザインタフェースの役割::ユーザをゴールまで導くこと
    3. ユーザ中心設計
      1. 利用の品質(quality in use)
        • ユーザ中心設計(UCD:user centered design)::利用の品質を保証するための手法
        • 製品の機能・性質が要求を満たしていない→目的を達成できない。
        • 要求どおりの品質でも、使いこなせなければ結果は同じ。
        • 利用の品質≒非機能要件？
      2. UCDの基本プロセス
        1. ユーザの"利用状況"を把握する。
        2. 利用状況から、"ユーザニーズ"を探索する。
        3. ユーザニーズを満たすような"解決案"を作る。
        4. 解決案を"評価"する。
        5. 評価結果をフィードバックして、解決案を"改善"する。
        6. 評価と改善を"繰り返す"。
        • UCD≠ユーザから出される要求や不満に対応すること。
        • UCD＝ユーザの具体的な利用状況を把握したうえで、潜在的なニーズまで探索。
      3. UCDのポイント
        • プロセスの質
        • スパイラル
        • ユーザの参加
  2. ユーザ調査法
    1. 従来のインタビュー法
      1. ユーザの声の限界
        • 「"ユーザの声"に頼っているかぎりユーザビリティは改善できない」
        • ユーザは「自分の失敗に気づいていない」ことが少なくない。
        • 専門知識がなければ妥当な解決策を導き出せない。
        • 意見と実際の行動は一致しない。
      2. グルイン(＝フォーカスグループインタビュー)の限界
      3. インタビューの限界
        • 予定通り
        • 要約される情報
        • 例外に触れない。
    2. 師匠と弟子方式のインタビュー
      1. コンテキスト調査法(context inquiry)
        1. インタビュアーはユーザに"弟子入り"する。
        2. ユーザ（師匠）は仕事を見せながら説明する。
        3. インタビュアー（弟子）は、不明な点があればその場でどんどん質問する。
        4. ひと通り話を聴いたら、弟子は理解した内容を師匠に話して、間違っていないかどうかチェックしてもらう。
        • 「現場に行って話を聞く」
        • 代替案：コンテキストインタビュー
      2. 弟子の心構え
        • 教えを請う
        • 根掘り葉掘り
        • 確認する
        • 専門家であることを悟られない
        • 仮説検証しない←生データの収集が目的
        • むだに粘らない
      3. 師匠の選び方
        • リクルート(recruting)::調査協力者を探すこと
        • スクリーニング調査
    3. インタビューの実践
      1. インタビュー設計
      2. インタビューの場所・機材・人員
      3. インタビューの進行
        1. 信頼関係構築
        2. ユーザプロフィールの把握
        3. 利用状況の把握
        4. インタビュー終了
    4. シナリオ
      1. ドキュメント化の必要性
      2. シナリオとは
        • ユーザを主人公とした、システムや製品の使用に関するエピソード
        • "物語風"
        • 最大の利点は、コンテキストを失わないこと
    5. シナリオ分析の実践
      1. シナリオの書き方
        1. 個別エピソードの作成
        2. シナリオの推敲
      2. シナリオの検証
        • 再面談
        • デメリット←削除要求
      3. シナリオの利用方法
        • チーム全体で共有
        • 本物のタスク（＝ユーザテストで被験者に行ってもらう作業）
        • 真のユーザニーズ（＝暗黙の／潜在的なニーズ）
      4. ユーザニーズ探索
        1. 分解する
        2. 分析する
          • 「何を(what)」解決すべきか？
          • 「どのように(how)」ではない
        3. 発想する
      5. シナリオ分析のメリット
        • 従来のマーケティングデータに振り回されずに、プロジェクトを推進できる。
  3. プロトタイプ
    1. プロトタイプとは
      1. ローファイとハイファイ
        • プロトタイプは、テストの目的と直接関係する部分だけはハイファイに作られていないと役に立たない。
        • 全体を大ざっぱに作ることではない
        • 目的を達成するために「必要最小限のインタフェースに絞って作る」
      2. Tプロトタイプ
        • 水平プロトタイプ
        • 垂直プロトタイプ
        • Tプロトタイプ::両方のmix→ユーザが実際に作業を行ってみることが可能
      3. オズの魔法使い（＝人力。あたかも動作しているように見せかける）
    2. プロトタイプの作り方
      • ペーパープロトタイプ
      • フォワードシナリオシミュレーション::口頭のプロトタイプ
      • すべてのリンクやボタンをクリックできるようにする→ダミーページ
      • ハイファイにすべき要素
        • 画面遷移（順番、数）
        • 画面要素の相対的な位置関係
        • リンクやボタンに表示するラベルテキスト
        • 画面に表示する指示文の内容
        • データ入力項目と入力書式
        • 操作に関係したアイコンのデザイン
      • なるべく設計チーム全員が議論に参加して作る
    3. カードソート
      1. クローズド
        • 見出し（カテゴリ）のあるカードソート
      2. オープン
  4. ユーザビリティ評価法
    1. 評価とは
      • 総括的評価(summative evaluation)
        • パフォーマンス測定
        • 設計プロセスの前後で実施
      • 形成的評価(formative evaluation)
        • 思考発話法
        • 設計プロセスの途中で繰り返し実施
      • 分析的手法(analytic method)または専門家評価(expert review)
        • 仮説や議論
      • 実験的手法(empirical method)
        • 本物のユーザのデータを収集
        • ユーザテストやアンケート調査など
    2. ユーザビリティインスペクション
      1. ヒューリスティック（経験則）評価法
      2. 10ヒューリスティック
        1. システム状態の視認性
        2. システムと実世界の調和
        3. ユーザコントロールと自由度
        4. 一貫性と標準化
        5. エラーの防止
        6. 記憶しなくても、見れば判るように
        7. 柔軟性と効率性
        8. 美的で最小限のデザイン
        9. ユーザによるエラー認識、診断、回復をサポートする
        10. ヘルプとマニュアル
        • シュナイダーマンの八つの黄金律
        • IBMの設計の原理
        • ISO 9241 Part-10：対話の原則
      3. ヒューリスティック評価の実施手順
        1. 評価者を集める
        2. 評価計画を立てる
        3. 評価を実施する
        4. 評価者ミーティングを開催する
        5. 評価結果をとりまとめる
      4. ヒューリスティック評価の限界
        • 検出過多
        • 実施コスト
    3. ユーザテストとは
    4. 代表的なテスト手法
      1. 思考発話法
      2. 回顧法
      3. パフォーマンス測定
    5. ユーザテストの基本理論
      1. ユーザビリティの論理学
        • ユーザテストは反証を目的
      2. ユーザテストの被験者数
        • ヤコブ・ニールセン「5人のユーザでテストすれば、ユーザビリティ問題の約85%を発見できる」
        • N(1-(1-L)^n) Lは経験的に0.31。
        • あくまで平均値。また、重み付けなしで単純な個数の話。
        • ショーストッパー::非常に深刻な問題
      3. 反復デザインの効果
        • 少人数でテスト→フィードバックを繰り返した方が問題を潰せる
      4. 比較調査は負けの始まり
        • どれがいちばんマシか
        • データの信頼性
        • 品質の基準は競合ではなく、ユーザニーズ
  5. ユーザテスト実践編
    1. プロジェクト計画
      1. ユーザテストのスケジュール
      2. ユーザテストの時間割
      3. ユーザテストの費用
        • 5人のテストで60~110万
        • リモートユーザテストなどでコストダウン
    2. リクルート
      1. リクルート条件の決定
        • 普通のユーザ。初心者お断り
      2. スクリーナの作成
        • スクリーナ::該当者を選別するための判定質問
        • 経験のチェック
        • スキルのチェック
        • プラスαの質問
    3. テスト設計
      1. タスクの設計
      2. インタビューガイドの設計
      3. 実査ツールの準備
      4. パイロットテストの実施
    4. 実査
      • 写ミール
    5. 分析とレポート
      1. テスト記録の作成
      2. データの分析
        1. 問題点の抽出
        2. インパクト分析
      3. 評価レポートの作成
      4. ブレストのススメ
        • 批判厳禁
        • 自由奔放
        • 質より量
        • 便乗歓迎
        • 視覚化
        • 脱線禁止
        • 1度に1人