#ユーザーインタビューけものみち
ユーザーインタビューは難しい。ターゲットを設定してその属性に近い被験者や、自サービスを使っている被験者に会って話をするが「で、何が分かったんだっけ?」となるケースが多い。ここでは、そういう経験を乗り越えて、自分が心掛けていることを記載する。
設計:インタビューの目的設定
「何を知りたいか?」ではなく「何を決めたいか?」から始める。これはリサーチの設計だけでなく、あらゆる意思決定の手順と同じである。
何を決めたいか?
↓
そのためにどんな情報が知りたいか?(=何が知りたいか)
↓
その情報を得るために何をすれば良いか
「何を決めたいか?」の裏には「誰が決めるか?」「どうやって決めるか?」も絡んでくる。例えば意思決定者が定量化を重視する人物の場合、N数の少ないインタビューでファクトを集めても、意思決定の材料にならないことが多い。
フォーカスする課題を決めたい
↓
ありうる課題を定量的に測りたい
↓
自サービスユーザーにオンラインアンケートを行う
上記の場合はこのような出口(オンラインアンケート)になるはずだ。そこを外してはいけない。デザイナーやリサーチャーがチームの意思決定プロセスや力学を掴めていないプロジェクトでは、無駄リサーチが繰り返されることが多い。
設計:インタビュー準備〜実査
半構造化インタビューや探索型・検証型などいろいろなメソッドがあり、そういう情報はインターネット上に転がっている。拾って組み合わせれば良いためここでは割愛する。ちなみに現職場ではリサーチ設計がある程度体系化されたフォーマットがあり、例えば「顧客課題探索・定性」と選択するとインタビュー骨子や質問例が自動的に出力される。便利。
なお、実査もラポールや深掘りの仕方などいろいろ tips はあるが、こちらも経験で積んでいくものだと思っているので割愛する。
過去に被験者に「なぜ」と問いかけることについて書いた。こちらも併せてご覧いただきたい。
実査後:デブリーフィング
実査後は同席者と共にすぐ1時間ほどのデブリーフィングを行う。自分は仕事柄、学校でインタビューをすることが多いため、実査後は最寄りの喫茶店やファミレスで行う。
デブリーフィングでは、同席者がそれぞれインタビューで得たファクト、特に注目した事実とそこから得た示唆を書き出していく(コンフルエンスやスプレッドシートなど、事実と示唆が左右見比べることができるフォーマットが良い)。これは、インタビューに同席できなかったチームメンバーに内容を共有すること・翌日以降に行う分析会の準備をする目的がある。
実査後:分析会
実査翌日以降、できるだけ早いタイミングで分析会を行う。ここでは、デブリーフィングで集めた事実と示唆をお互いに共有し、気付きを多角化して被験者の理解を深める。その後(このプロセスが一番重要なのだが)あらかじめ設定していた目的(=何を決めたいか?)に対する評価を行う。
コンセプトアイデアが複数あり、どれを採用するかを決める調査であれば、どのアイデアを採択するのか(またその理由はなにか)。プロダクトの要件を決めることが目的であれば、候補の要件をバックログに入れるか入れないか(またその理由はなにか)を話して決めていく。
この分析会の過程で、インタビューに対する改善点(メモがいまいち取れていない etc)被験者チョイスの改善点(ターゲットと少しずれていた etc)のようなトピックが挙がることが多いため、それも次回インタビューや被験者選定への改善ネクストアクションとなる。
参考)計画的なインタビューの場合
上記は単発インタビューの際の進め方だが、複数人を被験者とする計画的なインタビューの場合は分析会は毎回行わない方が効率的。それでもデブリーフィングはしておいた方が良い(非同席者が雰囲気を掴むため)
計画していた人数にインタビューを行いログが溜まった後に、チームでKA法なりなんなり行い、価値ツリーなりジャーニーマップなりメンタルモデルなり、目的の分析を行えば良い。その際、チームメンバーが公平にファクトにアクセスできるように、インタビューの録音 or 録画がマストになる。
ユーザーは答えを教えてくれない
試行錯誤の瓦礫を踏み抜きまくった結果、現在上記のような進め方をしている。このプロセスでいちばん大事なことは「ユーザーは答えを教えてくれない」という至極初歩的なことをリサーチャーもチームも忘れないことである。誰も教えてくれない答えにチームで挑むからこそ、今決めたいこと・どういう情報があればそれを決めることができるか・その情報を得るためにチームでできることをリサーチの前に考え、答えを出しておく必要がある。
この記事が気に入ったらサポートをしてみませんか?