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

読むきっかけ

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

読んでみて

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

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

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

ユーザビリティの定義

特定のコンテキストにおいて、特定のユーザによって、ある製品が、特定の目標を達成するために用いられる際の、効果・効率・ユーザの満足度の度合い
ISO9241 この時に、「ユーザービリティ」の定義

グループインタビューの限界

参加者の意見に影響される
参加者がいることで、ウソにならない脚色がはいる
ユーザビリティでは、人間の行動を扱う。感情や、本音を扱うわけじゃない
悪いインターフェイスのユーザの本音は、なんとなく腹立たしい
事前に質問を用意してインタビューしてしまうと、アンケートと変わらない。仮説がある状態

コンテキスト調査法

「師匠と弟子」の関係を築く
- 教えを請う、根掘り葉掘り、確認する
- 専門家にならない
- 途中で仮説検証しない
- 粘らない
- 体験を知る

インタビューのドキュメント化

情報を要約しては意味がない
- 断片的な体験の把握になってしまう
- ユーザの意見を要約するのは可能
- 師弟関係を築いてしりたかったのは、体験
- ユーザの自白ではなく、状況証拠から結論を導く

ユーザの本物のタスクは何か

ユーザの真のニーズ
- 明示的なニーズだけじゃない
当たり前のことは、ユーザは言わない
- 気付いていないニーズがある
- 大発見となるニーズだけじゃない。当たり前と感じられるニーズも大切。全体を適切に扱う

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

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

- 試用するために作る＝システム開発とは限らない
- 影から人が動かしてもよい

評価

総括的評価と、形成的評価の二種
ユーザビリティで使うのは、形成的評価
- インタフェースの設計をこれからするのか？途中なのか？終っているのか？
- 総括的評価しかしないなら、全くの無駄

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

ヒューリスティック評価法

ヒューリスティックス
- 経験則
ヤコブ・ニールセンのヒューリスティック評価法
- ユーザビリティの評価手法 – U-Site

システム状態の視認性
システムと実世界の調和
ユーザコントロールと自由度
1. 出口ややり直し
一貫性と標準化
エラーの防止
記憶しなくても、みれば分かるように
柔軟性と効率性
1. ショートカットとか
美的で最小限のデザイン
ユーザによるエラー認識、診断、回復をサポートする
ヘルプとマニュアル

ヒューリスティック評価の方法

複数人。三から五
エンジニアや、デザイナー
当事者以外

ヒューリスティック評価の方法：計画を立てる

部分的に行う

ヒューリスティック評価の方法：実施

評価者同志は、相談しない
複数の視点が大切
時間をかけない

ヒューリスティック評価の方法：評価者ミーティング

他の評価者を否定しない
ヒューリスティックに基づくので、全て妥当であり、全て仮説である

ヒューリスティック評価の方法：ミーティングの結果をまとめる

ブレインストーミングで解決策なども提示するのもあり

ヒューリスティック評価の方法：ヒューリスティック評価の問題

問題を見つけすぎる
ユーザテストよりも、重箱をつつく形になる
ヒューリスティック評価の専門家を頼んだら、10人日などもあり得る

代表的なテスト手法

代表的なテスト手法：思考発話法

考えていることを話しながら操作してもらう
強力な評価手法。失敗成功の事実だけではなく、なぜ？がわかる

代表的なテスト手法：回顧法

操作完了後に話しながら操作
- インタビュアーの経験が浅くても大丈夫
- 操作が完了しなかった時に、理由がわからない、という欠点
- テスト時間がかかる。回顧するため

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

代表的なテスト手法：パフォーマンス測定

タスク達成率 → 効果
タスク達成時間 → 効率
主観的評価 → 満足度

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

ユーザビリティの倫理学

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

何人のユーザでテストしたら？何種類のタスクを検証したら？ユーザテストは、反証を目的にしている
- ユーザブルであるという仮説に対して、ユーザテストをすることで、問題がでたら、具体的な反証となる
- ユーザテストをする前に、ユーザブルである仮説を立てるためには、プロトタイプや、ヒューリスティック評価が必要