ユーザーテスティングとは
自サービスの有益性やアイディアをテストする手法。サービスの初期段階から行うことが可能。ユーザーが現状どんな行為をしていて、それが新しい方法に置き換えられるのか、またどのように置き換わるのか、テストをする。
Uberのファウンダー、トラビス・カラニックがパリでタクシーが捕まらないことをきっかけにその場でユーザーテスティングを行い、結果Uberの開発に至った事例が有名。
参照：User Testing v/s Usability Testing

これからユーザーテスティングをする人向けマニュアル。
内容確認の機会があったのでついでにメモ。

このテスト手法で発見できること

「do you need this service?」
あなたはこのサービスが必要ですか？
（あなたにとって使う価値がありそうですか？）
*使い勝手に関してはユーザビリティ評価で検証する

検証方法

1. 被験者の選定
2. 質問項目の作成
3. プロトタイプの準備（ラフでも良い）
4. 記録準備
5. テストの実施
6. テスト結果のまとめ

1. 被験者の選定

サービスの価値を検証するテストなので、できるだけターゲット/ペルソナに近いユーザーを選ぶ。

2. 質問項目の作成

質問項目の例
▼新しいサービスの場合
・普段どうやってこの課題を解決していますか？
・この方法よりもっと良い方法が思いつきますか？
・この行為をしたいと思いますか？（この課題解決の手法がワークするか）
・このサービスを使うのにお金を払ってもいいと思いますか？

▼既存サービスのアップデートの場合
・どうやって私たちのサービスについて知りましたか？
・私たちのサービスについて考えた時、どんな思いや印象が頭に浮かびますか？
・私たちのサービスを評価するとしたら、10点満点で何点つけますか？
・私たちのサービスを選ぶ前に、どの他サービスを検討しましたか？
・その中でなぜ私たちのサービスを選んでくださったのですか？
・xサービスと比べて、私たちのサービスはどうでしたか？
・私たちのサービスで一番好きなところはなんですか？
・私たちのサイトは使いやすいですか？使いづらいですか？それはなぜですか？
・私たちのサービスで、あなたが思う一番重要な機能はなんですか？
・逆に一番必要ないと考える機能はなんですか？
・これから一番欲しい機能はなんですか？
・なにがきっかけで私たちのサービスを知りましたか？
・契約時に、一番懸念したこと/することはなんですか？
・私たちのプランごとの料金指標はわかりやすかったですか？
・初めてサイトを使った時の印象はどうでしたか？
・このページで、足りないと思う機能はりますか？
・あなたの好きなブログ・Webサービスはなんですか？
・もし私たちのサービスが気に入らない場合、どうしたら好きになってもらえますか？
・私たちのサービスを使う中で、あなたが最も行なっているタスクはなんですか？

3. プロトタイプの準備（ラフでも良い）

ペラでもいいので、サービスの機能が説明できたり想像できたりするもの。
既存サービスのアップデートを検証する場合は、既存ユーザーならアプデ分の画面デザインなどを準備。

4. 記録準備

記録
インタビュー形式なので、ボイスレコーディング／できれば表情も映る動画撮影などを準備。

場所
しっかりしたテストを想定する場合は、リラックスして落ち着ける場所がいい。周りの視線や思考の邪魔が入る場所だと、検証内容のノイズになる可能性がある。
ただトラビスの例をみると、ユーザーが実際にサービスを使う場面だとより利用イメージがつくので直感的な意見を聞けるかもしれない。

人員
リラックスして本音で話せる場づくりが必要なので、質問者1人と被験者1人の環境にする。人の話を聞くことに集中したいので、メモ書きはしないOR最低限にして、相手の話に耳を傾ける（そのためのレコーディングでもある）。もし記録者がいる場合は、ツイタテを使ったり、テストルームにお金がかけられるならモニタリングしながら別室で記録するのもよい。

5. テストの実施

質問をする人（モデレータという）の注意点。モデレータは場の雰囲気の操作や、質問の仕方に気を配ったりとかなりスキルが必要。
場数が勝負なので専門家がいなくても以下のことに注意しながらテストをしていけば、後からスキルは付いてくる（と信じている）。

▼テストを始める前

リラックスして本音で話して良いんだ、という状態を準備
・アイスブレイクをして本音がでやすい雰囲気にする
・良いことも悪いことも遠慮なく言ってください、と一言伝えてあげる

初対面でいきなりリラックスはもちろん難しい。テストでは最後の10分とかでやっと本音が聞ける場合もある。でもできるだけ最初からオープンな空気を作ってあげること。

▼テスト中

バイアスや誘導尋問になるような質問を避ける
「xxということですか？」「xxですよね？」「xxと思いましたか？」というような質問は誘導尋問になるのでNG。かわりに「どうしてそう思ったのですか？」「なぜですか？」といったオープンクエスチョンで深掘りすると良い。

怒らない
これは自分は感じたことないけど、モデレータの中にはサービスへの自負が強すぎて「なんでそんな考えになるんだ！」と怒る人がいるらしい。
被験者は敏感なので、そういう雰囲気を感じたら保身や気遣いに走る。そうなったら検証の質がグンと落ちる（嘘のデータになる）。
心は冷静に、外面はフレンドリーに対応すること。

むしろ感謝する
ユーザーは自分たちが気づかない視点を与えてくれる。そんな機会をくれることに感謝しよう。

6. テスト結果のまとめ

サンプルが複数集まれば、その中で共通の意見や課題が見えるはず。
定性、定量の両方の観点で集計することもできるので、他の人が参照できるような形でまとめる。テストの結果を共有して、社内の共通認識を深められるような、そして同じ課題について皆んなで試行錯誤できるような組織が作れたら良いと思う。

形は表組みの集計でも良いし、レポートでもいい。会社や自分にあった方法で。また将来的に同じようなテストをするかもしれないので、ある程度フォーマットが揃っていたり、他の人も作れるような形だと運用負荷が低い。

さいごに

テストにはいろいろな種類があって、検証できる内容や特徴などが違うので、求めている用途にあったものを選ぼう。弊社では、価値検証の後にユーザビリティ検証（操作の検証）をする予定。他のテストの例でいうと、複数人で行うフォーカスグループ、エスノグラフィー/フィールド調査、アンケート、などなど。

また、それだけ手法があるからこそ境目が曖昧になっている場合もあるかもしれない。このマニュアルで一般的な手法から大きく外れた内容があったらご意見をいただけると嬉しいです。