定性調査からインサイトを定義する方法
「定性調査の結果から、施策起案に悩んでいたデザイナーが、インサイトの定義手法を使って得た知見！」
はじめに
こんにちは！グロービスで学び放題というサービスのデザインを担当しています、「受講者開発チーム」のニーです。今回の記事では、「インサイト定義」を通して得た知見を、みなさまに共有したいと思います。
目次
インサイトを定義し始めた背景
始まり
グロースハックの結果
インサイトとは？
インサイトの定義
インサイトを定義する目的
インサイトを定義するゴール
インサイトの使い方
ユーザー調査からインサイトを定義し、施策起票までの流れ
インサイトを定義する例
最後に
インサイトを定義し始めた背景
始まり
開発チームが、プロダクトに置いたKPIの改善を早くしたかったため、グロースハックプロセスをチーム内に導入。二週間ごとのサイクルをいくつ回してみました。
素早くKPIを改善できる施策を見つけるため、チームの時間を費やし、非定期にチーム全員が集まったアイディエーション（アイデア出すためのブレストーミングワーク）も数回行いました。しかし、結果は希望通りにいきませんでした。
グロースハックの結果
アイディエーションに沢山アイデアが出ました。しかし、アイデアの収束と選出がうまくできませんでした。結局チームのみんながアイデアを納得いかないままに、考えたアイデアを放置してしまいました。
グロースハックプロセスを改善するために、開発チームで振り返りをしました。議論がうまくいかなかった原因を2つにまとめました。
①事象からアイデアを発想したこと
開発チームは、特定なテーマでユーザーリサーチをやっていました。当時はまだアイディエーションのために、リサーチの結果を整理していませんでした。アイディエーションは、KJ法で整理した事象を元に開催しました。その結果、考えたアイデアは表層の事象に左右され、事象の裏にある、ユーザーの発言や行動の本質を見通すことができませんでした。
例）あるユーザーが調査中に「コース一覧を絞る機能が欲しいな」と発言したと仮定し、事象のままにアイデアを考えるとします。そうすると「コース一覧にフィルターを追加する」という発想になりがちです。該当ユーザーの発言の裏を探ってみると、ただ「自分の見たいコースを早く探したい」というニーズがあるかもしれません。こんな風に考えてみると、フィルターの追加はあくまで「コースを早く探せる」手段の一つにすぎません。
②軸のない状態で議論をしたこと
チームメンバーのみんなが自分の価値観を持って話したので、アイデアがいいかどうかを判断する基準が揃っていませんでした。時に「そのアイデアで解決する課題が本当にユーザーのためになるか？」のような課題仮説の話をしたり、「そのアイデアが本当にユーザーに価値を提供できるか？」のような価値仮説の話をしたりした結果、議論が発散し、収束できませんでした。
インサイトとは？
インサイトの定義
インサイト（Insight）を、直訳すると、「洞察」と言った意味です。物事の本質を見通す、見抜くことを意味しています。
特にUXの観点でインサイトの意味を更に解釈すると、我々は下記の見解に辿り着きました。
事象から推測できる洞察、気付き、発見。
ユーザーの行動の根底に動機や本音があったが、本人でも意識していないことが多い。
インサイトを定義する目的
表層の事象に左右されず、定義したインサイトでユーザーに共感し、ユーザーのためにアイデアを考えるため
インサイトを定義するゴール
定義したインサイトでアイデアを評価できる状態にすること
アイデアを発想するとき、定義したインサイトで「このアイデアはユーザーのニーズを満たせるか？」「このアイデアはユーザーの課題を解決できるか？」などの観点から評価できる状態。この状態で議論すれば、自然に軸のある議論になります。
インサイトの使い方
ユーザー調査からインサイトを定義し、施策起票までの流れ
わたしたちはグロースハックを改善するため、ネットや本の資料を参考にして、調査から施策起票までの流れをまとめました。
ユーザー調査から施策を起票する方法は、ネットで調べるといくらでもあります。流れの順序や言葉の定義もそれぞれです。下記にまとめたのは、あくまでわたしたちのチームにとって最適なものだと思っていただければ幸いです。
①ユーザー調査
ユーザー調査を実行し、調査中ユーザーの発言や行動を記録し、事象として残す。
②調査分析
調査を分析するのに、KJ法や上位下位分析などの手法がいろいろあります。どれもユーザーの行動や発言の裏にあるインサイトを見抜くための手法です。
インサイトは三つのステートメントで構成されています。分析の結果と事象を踏まえ、ステートメントが事象を最適に表現できるまで繰り返し、書き直すことがが大事なポイントです。具体的にどうステートメントを書くのかは、後述します。
ユーザーの現状を説明する(思考、行動、感情などを調査から推測)
ユーザーが抱えているジレンマを説明し、何故それが不満なのかを明確に説明する。
ユーザーのニーズと、理想な状態を説明する
インサイトに紐づく根拠はありますが、あくまで事象から「推測」したものに過ぎないことを認識しないといけません。「推測」を検証するために、「計測指標」が必要です。インサイトのステートメントにある、「ユーザーのニーズと、理想な状態を説明する」から「計測指標」を立てることができます。
③アイディエーション
アイディエーションを行う方法は沢山あります。アイデアを発想する時に、土台になるのは、丁寧に定義したインサイトでないといけません。我々のチームで行われているアイディエーションは、インサイトに基づいた問い「How Might We?」から始まります。ブレンストーミングの形でチームメンバーを集め、問いに答えるためのアイデアを付箋化します。そして、発表し、グルーピングし、最後にアイデアたちを「インパクト（主にインサイトに定義してあるユーザーのニーズを満たせるか？ユーザーに価値を提供できるか？で判断する）」と「開発工数」の二軸で評価。施策化していくアイデアを選出します。
HMWは英語の「How Might We?」の略称。ユーザーのニーズを満たす(理想な状態に達する)ために、問いで我々は何ができるのかを明文化するフォーマットである。
日本語に訳するとこうなる：「どうすれば我々は『対象ユーザー』のために、『理想な状態に達する価値』を提供できるだろう？」
④施策起票
アイディエーションから選出したアイデアを開発Readyにするため、POとデザイナーは協業します。エンジニアさんとアイデアの実現可能性や工数や運用コストなどの考慮をしながら、アイデアを精緻化し施策化していきます。開発Readyの施策ができたら、バックログに入れます。
インサイトを定義する例
調査の事象を、KJ法と親和図などの方法をある程度整理します。そうするとユーザーの行動や発言の裏にある共通している何かを発見できるようになります。
下記の画像のように、事象をKJ法でグルーピングします。グループとの間に関係性を発見しました。
グループA：朝に短いコースを一気に最後まで見たい。長いコースは朝に見ない。中途半端になるのが嫌だから、、、
グループB：通勤中、短いコースをいくつか見たい。達成感があるから、10分で終わるコースに気持ちが移ってしまった。
グループC：通勤中長いコースを見たい。余計な操作はしたくないから。
この三つのグループから、一見コースの選択に対する好みはユーザーそれぞれ違います。我々は下記のようにインサイトを推測し、一見関係のない事象をまとめてみました。
ユーザーの現状を説明する(思考、行動、感情などを調査から推測)
自分の生活スタイルや好みに合わせて学習ができると、学習に投資した時間が報われたと思うユーザーが抱えているジレンマを説明し、何故それが不満なのかを明確に説明する
放題で学習するたびに、自ら自分の生活スタイルや好みに合うコンテンツを探さないといけないのが、大変だと思うユーザーのニーズと、理想な状態を説明する
放題の中に自分の生活スタイルや好みに合うコンテンツは手間をかけずに簡単に見つけられる。そして、いつでもすぐに報われる学習ができるような状態になる。
最後に
施策起票までのデザイン手法は、いくらでもあります。どの手法を使っても、ユーザーの本当のニーズを見抜かないといけません。なぜなら、そのニーズがないと、いくら開発に頑張ってもユーザーはプロダクトを使ってもらえません。今回の記事は、少しでも定性調査の結果から、施策起案に悩んでいたデザイナーの役に立てれば幸いです。これからは、一緒に本質を見抜けるUIUXデザイナーになりましょう！
参考にした資料
How exactly do you find insights from qualitative user research? (by Taylor Nguyen)
WHAT IS INSIGHT? THE 5 PRINCIPLES OF INSIGHT DEFINITION（by JONATHAN DALTON）
Design Thinking: The Ultimate Guide（by Interaction Design Foundation）