ユーザーテストの超ざっくりの流れ。
ユーザーテストで確認すること
こちら側が想定しているコンテキストと、ユーザーが想像するコンテキストのずれが無いかテストする。
あたりまえ品質の担保
https://www.juse.or.jp/departmental/point02/08.html
準備
前提をインタビュイーに共有する。
機能についてのテストであって、あなた自身をテストするわけではありません。
発話手法について
操作する際に、思ったこと、感じたこと、これからすることを声に出して操作してみてください。例えばこんな感じ。
確認したい仮設を整理しておく
シナリオ、質問項目を事前に準備しておく
- 課題仮設の設定
- 仮設を検証するために必要な操作シナリオを作成
- 必要に応じてデータ、UI、プロトタイプを作成しておく。
[point]
「効率」より「効果」
よりわかりやすい操作ができる状態にするのは当然として、それ以前に、そもそも操作ができるか？を確認しておかないと、不完全な製品としてリリースされてしまう。
[point]
「満足度」（ユーザーの不安や不満）を軽視しない製品をつくる
[point]
「ユーザーにレビューしてもらう」のではなく、「操作してもらう」
判断を下すのは作る側の仕事。重要度、優先度もふくめてテスト結果をプロダクトに反映させるかどうかを検討する。
[point]
「シナリオはあくまでも仮説」
間違っている可能性がある。
[point]
テストの大まかな流れ
- アイスブレイク（ラポール形成）
- シナリオに沿って操作してもらう
- 事後アスキングを行う
[point]
ポイント
- 操作につまることがあっても教えない
- なぜ？と聞かない
- ☓ なぜそれをクリックしなかったのですか？
- ○ それに気が付きましたか？
テストは理解のフェーズ
その課題を実際に修正するべきかどうか？は別で考える。
テスト中は、何が起こっているのか？の理解に全力をそそぐ。
イメージとしては全部実施したとして、簡単な機能であれば半日くらいの稼働時間。