読者です 読者をやめる 読者になる 読者になる

めも帖

「めも帖」代わりにダラダラと書いていったり、めもしたりしているだけです。

ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック

読むきっかけ

ユーザー中心デザインの導入vs納期 -仁義なき戦い- | webディレクターの阿呆な研究」を読んで、ユーザービリティの「現実的な落とし所」に興味がでました。
ユーザービリティといえば、UI/UXルームを用意して…とか、インタビューをして…とか、そんなこと、なかなかできないよなあ、と思うなかで、ユーザービリティは、どのように実現するんだろう?と思っていました。
しかも、ユーザービリティって、民主主義的に決め始めると、結局、なんか決まらない…ということに。最悪、なんか使えそうで使えないとなります。微妙に使えるのが、また、モヤモヤさせるところであります。
それだけに、「現実的な落とし所」について気になるのでした。

ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック

読んでみて

読んでいる途中にメモを色々と書いていました。かなりメモしていたので、それを整理してみました。

ユーザービリティの評価方法には、色々とあることがわかります。また、実施方法や、そこにかかる費用なども、ある程度見えてくるのではないでしょうか。費用とスケジュールなども考えると、実際に行うとなると、かなり難しいことなのだと思います。

そこで、「ヒューリスティック評価法」が、「現実的な落とし所」になるのだと思います。この方法であれば、デザイン担当、システム担当、ディレクター担当?などで検討して落とし所を出すことが出来ると思います。結局、なんだか決まらない、というのもヒューリスティック評価法の基準を持って考えることになるので、話の軸が保たれる(もしくは、保たれやすい)のだと思います。
ウェブサービスの開発であれば、作ったらリリースなのではなくて、試験期間をとり、そこで、ヒューリスティック評価法を使うのは、現実的なのかも?と思いました(それさえ厳しい時も多いけれどさ)。

ユーザビリティの定義
  • 特定のコンテキストにおいて、特定のユーザによって、ある製品が、特定の目標を達成するために用いられる際の、効果・効率・ユーザの満足度の度合い
  • ISO9241 この時に、「ユーザービリティ」の定義
グループインタビューの限界
  • 参加者の意見に影響される
  • 参加者がいることで、ウソにならない脚色がはいる
  • ユーザビリティでは、人間の行動を扱う。感情や、本音を扱うわけじゃない
  • 悪いインターフェイスのユーザの本音は、なんとなく腹立たしい
  • 事前に質問を用意してインタビューしてしまうと、アンケートと変わらない。仮説がある状態

コンテキスト調査法

  • 「師匠と弟子」の関係を築く
    • 教えを請う、根掘り葉掘り、確認する
    • 専門家にならない
    • 途中で仮説検証しない
    • 粘らない
    • 体験を知る
インタビューのドキュメント化
  • 情報を要約しては意味がない
    • 断片的な体験の把握になってしまう
    • ユーザの意見を要約するのは可能
    • 師弟関係を築いてしりたかったのは、体験
    • ユーザの自白ではなく、状況証拠から結論を導く
ユーザの本物のタスクは何か
  • ユーザの真のニーズ
    • 明示的なニーズだけじゃない
  • 当たり前のことは、ユーザは言わない
    • 気付いていないニーズがある
    • 大発見となるニーズだけじゃない。当たり前と感じられるニーズも大切。全体を適切に扱う

ニーズと解決策を混同しない。何を解決すべきか?どのように解決するかは、また別な話

プロトタイプ。試作ではなく、試用品
オズの魔法使い

    • 試用するために作る=システム開発とは限らない
    • 影から人が動かしてもよい
評価
  • 総括的評価と、形成的評価の二種
  • ユーザビリティで使うのは、形成的評価
    • インタフェースの設計をこれからするのか?途中なのか?終っているのか?
    • 総括的評価しかしないなら、全くの無駄

分析的手法または専門家的評価と、実験的手法の二つに区分される

ヒューリスティック評価法
  1. システム状態の視認性
  2. システムと実世界の調和
  3. ユーザコントロールと自由度
    1. 出口ややり直し
  4. 一貫性と標準化
  5. エラーの防止
  6. 記憶しなくても、みれば分かるように
  7. 柔軟性と効率性
    1. ショートカットとか
  8. 美的で最小限のデザイン
  9. ユーザによるエラー認識、診断、回復をサポートする
  10. ヘルプとマニュアル
ヒューリスティック評価の方法
  • 複数人。三から五
  • エンジニアや、デザイナー
  • 当事者以外
ヒューリスティック評価の方法:計画を立てる
  • 部分的に行う
ヒューリスティック評価の方法:実施
  • 評価者同志は、相談しない
  • 複数の視点が大切
  • 時間をかけない
ヒューリスティック評価の方法:評価者ミーティング
ヒューリスティック評価の方法:ミーティングの結果をまとめる
  • ブレインストーミングで解決策なども提示するのもあり
ヒューリスティック評価の方法:ヒューリスティック評価の問題
  • 問題を見つけすぎる
  • ユーザテストよりも、重箱をつつく形になる
  • ヒューリスティック評価の専門家を頼んだら、10人日などもあり得る
代表的なテスト手法
代表的なテスト手法:思考発話法
  • 考えていることを話しながら操作してもらう
  • 強力な評価手法。失敗成功の事実だけではなく、なぜ?がわかる
代表的なテスト手法:回顧法
  • 操作完了後に話しながら操作
    • インタビュアーの経験が浅くても大丈夫
    • 操作が完了しなかった時に、理由がわからない、という欠点
    • テスト時間がかかる。回顧するため

思考発話法、回顧法は、形成的評価

代表的なテスト手法:パフォーマンス測定
  • タスク達成率 → 効果
  • タスク達成時間 → 効率
  • 主観的評価 → 満足度
  • テスト会場などを用意して行う
  • ターゲットユーザ毎に20人以上で意味がでる。
  • 複数のインタフェースをテストする。基準がないから。
  • マーケティング担当は、数値があり喜ぶ
  • 設計担当は、原因がわからないので、手の打ち用がない
  • パフォーマンス測定は、総括評価。プロジェクトの前後で行う
  • 評価紙には、日本向けもある
  • ウェブユーザビリティ評価スケール
    • 内容の変更はしないこと
    • 総括評価として優れているが、形成的評価の代わりではない
ユーザビリティの倫理学

ユーザビリティを実証するのは困難

  • 何人のユーザでテストしたら?何種類のタスクを検証したら?ユーザテストは、反証を目的にしている
    • ユーザブルであるという仮説に対して、ユーザテストをすることで、問題がでたら、具体的な反証となる
    • ユーザテストをする前に、ユーザブルである仮説を立てるためには、プロトタイプや、ヒューリスティック評価が必要
ユーザテストの被験者数
  • 5人で85%の問題発見。あくまでも平均。また、問題の質は考慮しない
    • 15人で一回よりも、三回に分けてテスト
    • 5人で3回行ったほうが、問題が減っていく

おすすめ

ユーザービリティを気にする人向け。
ウェブサービス開発で手を動かす人なら、読むといいかも。

ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック

ユーザビリティエンジニアリング―ユーザ調査とユーザビリティ評価実践テクニック