見出し画像

#ユーザーインタビューけものみち

あんど

ユーザーインタビューは難しい。ターゲットを設定してその属性に近い被験者や、自サービスを使っている被験者に会って話をするが「で、何が分かったんだっけ？」となるケースが多い。ここでは、そういう経験を乗り越えて、自分が心掛けていることを記載する。

設計：インタビューの目的設定

「何を知りたいか？」ではなく「何を決めたいか？」から始める。これはリサーチの設計だけでなく、あらゆる意思決定の手順と同じである。

何を決めたいか？
↓
そのためにどんな情報が知りたいか？（＝何が知りたいか）
↓
その情報を得るために何をすれば良いか

「何を決めたいか？」の裏には「誰が決めるか？」「どうやって決めるか？」も絡んでくる。例えば意思決定者が定量化を重視する人物の場合、N数の少ないインタビューでファクトを集めても、意思決定の材料にならないことが多い。

フォーカスする課題を決めたい
↓
ありうる課題を定量的に測りたい
↓
自サービスユーザーにオンラインアンケートを行う

上記の場合はこのような出口（オンラインアンケート）になるはずだ。そこを外してはいけない。デザイナーやリサーチャーがチームの意思決定プロセスや力学を掴めていないプロジェクトでは、無駄リサーチが繰り返されることが多い。

設計：インタビュー準備〜実査

半構造化インタビューや探索型・検証型などいろいろなメソッドがあり、そういう情報はインターネット上に転がっている。拾って組み合わせれば良いためここでは割愛する。ちなみに現職場ではリサーチ設計がある程度体系化されたフォーマットがあり、例えば「顧客課題探索・定性」と選択するとインタビュー骨子や質問例が自動的に出力される。便利。

なお、実査もラポールや深掘りの仕方などいろいろ tips はあるが、こちらも経験で積んでいくものだと思っているので割愛する。

過去に被験者に「なぜ」と問いかけることについて書いた。こちらも併せてご覧いただきたい。

実査後：デブリーフィング

実査後は同席者と共にすぐ1時間ほどのデブリーフィングを行う。自分は仕事柄、学校でインタビューをすることが多いため、実査後は最寄りの喫茶店やファミレスで行う。

デブリーフィングでは、同席者がそれぞれインタビューで得たファクト、特に注目した事実とそこから得た示唆を書き出していく（コンフルエンスやスプレッドシートなど、事実と示唆が左右見比べることができるフォーマットが良い）。これは、インタビューに同席できなかったチームメンバーに内容を共有すること・翌日以降に行う分析会の準備をする目的がある。

実査後：分析会

実査翌日以降、できるだけ早いタイミングで分析会を行う。ここでは、デブリーフィングで集めた事実と示唆をお互いに共有し、気付きを多角化して被験者の理解を深める。その後（このプロセスが一番重要なのだが）あらかじめ設定していた目的（＝何を決めたいか？）に対する評価を行う。

コンセプトアイデアが複数あり、どれを採用するかを決める調査であれば、どのアイデアを採択するのか（またその理由はなにか）。プロダクトの要件を決めることが目的であれば、候補の要件をバックログに入れるか入れないか（またその理由はなにか）を話して決めていく。

この分析会の過程で、インタビューに対する改善点（メモがいまいち取れていない etc）被験者チョイスの改善点（ターゲットと少しずれていた etc）のようなトピックが挙がることが多いため、それも次回インタビューや被験者選定への改善ネクストアクションとなる。

参考）計画的なインタビューの場合
上記は単発インタビューの際の進め方だが、複数人を被験者とする計画的なインタビューの場合は分析会は毎回行わない方が効率的。それでもデブリーフィングはしておいた方が良い（非同席者が雰囲気を掴むため）
計画していた人数にインタビューを行いログが溜まった後に、チームでKA法なりなんなり行い、価値ツリーなりジャーニーマップなりメンタルモデルなり、目的の分析を行えば良い。その際、チームメンバーが公平にファクトにアクセスできるように、インタビューの録音 or 録画がマストになる。

ユーザーは答えを教えてくれない

試行錯誤の瓦礫を踏み抜きまくった結果、現在上記のような進め方をしている。このプロセスでいちばん大事なことは「ユーザーは答えを教えてくれない」という至極初歩的なことをリサーチャーもチームも忘れないことである。誰も教えてくれない答えにチームで挑むからこそ、今決めたいこと・どういう情報があればそれを決めることができるか・その情報を得るためにチームでできることをリサーチの前に考え、答えを出しておく必要がある。



この記事が気に入ったらサポートをしてみませんか？