27章 ゲリラユーザビリティテスト
- いつでも・気軽に・3～5人・5分
- 観察・記録する
- 行き詰ってなければ口を挟まない
28章 ユーザビリティテスト
ペーパープロトタイプ(11章)でやったようなことを実際のアプリで行う
- 凝らなくてもよい。少しやるだけで有意義な結果が得られる
- 全くやらないのは問題
- ユーザー層にあまりこだわらず広くテスターを集める
全くやらないか、あれもこれもやろうとするかの両極端をやめよう
29章 対面テスト
ユーザビリティテストを対面で行う
- 調査者介入型 行き詰ったり質問があったとき以外は黙って観察
- 調査者不在型 テスト開始したら一旦部屋を出る(キャプチャなどしておく)
- 自由形式 作業を決めない
30章 リモートテスト
画面共有などしながら
- テスターの慣れた環境でできるのと、調査者の影響が少ないのがメリット
- 観察しづらいのがデメリット
- 調査者不在型もありうる(キャプチャーを後でもらう)
31章 ユーザビリティテスト「べからず集」
- UI表示通りの表現で作業を表現しない
- テスターに影響を与えない
- テスターにストレスをかけない
32章 ユーザーエラーはデザインエラー
- エラーメッセージでユーザーを責めない
- エラーをなくす
- 現在のモードをわかりやすくする
- 入力例の説明をしたり、様々な入力形式に対応する
ここは割りと意識できている。続けよう
33章 A/Bテスト
- 修正後によくなっているか確認したいとき
- 解決策を見極めたいとき
- 局所的な最適化。限界はある
開発だとやらないよなあ。時に有用性を考えるのもいいかもしれない
34章 利用データの収集
リリース後に収集して問題を見つける
- パフォーマンス
- 出口点(使うのをやめるのはいつか？)
- 不具合
- ユーザーの行動
これも開発だとパフォーマンス統計以外やらない。いつかやった方がいい時がありそう
35章 ユーザーからのフィードバック
選択肢
- 無視する
- 適合するよう機能を追加する
- 製品を分割する(別のバージョンにする)
否定的フィードバックもチャンスととらえる
一番ダメなのは振り回されてごちゃごちゃ追加してしまうこと