ユーザー調査は「はい」や「いいえ」で終わらせない
プロダクトのステークホルダーはユーザー調査を、すでに下した決定を検証するためのツールと見なしている。しかし、デザインを肯定または否定するだけの二者択一の調査結果は、ほとんど価値をもたらさない。
二者択一の検証という誘惑
ユーザーエクスペリエンスの専門家は、調査とデザインがフィードバックループを構成する2つの要素であると理解している。すなわち、ユーザーの行動とニーズを観察し、そうしたニーズに対処するデザインソリューションを導き出して、テストし、そこで得られた情報をデザインの次の反復に活かすというループである。
しかし、事業部門のステークホルダーは、多くの場合、このプロセスを直線的なものとして思い描いている。そのため、デザインの意思決定に情報を提供する知見を生み出すために発見から始めるのではなく、しばしば、仮定に基づいてソリューションのアイデアを拙速に定義してしまう。
結果、ステークホルダーがUX担当者を関与させるころには、そのアイデアはすでに完全に形になっている。彼らがユーザーリサーチャーに求めるのは、そのアイデアを洗練させるのに役立つ知見ではなく、単に提案したデザインビジョンを検証することである。言い換えると、開発を始める前に、単純な「はい」という肯定の答えを求めているというわけだ。
こうしたやり方を取ると、調査活動の価値は無視できるほど小さくなる。しかし、ソリューションの妥当性は、二者択一の「はい」か「いいえ」では測れない。この両極端の間にある微妙なニュアンスを明らかにすることこそが、調査を行う最も重要な理由の1つだからである。
「はい」と「いいえ」は信頼できない
ユーザー調査に既存の意思決定を検証することを求めるのは、調査をまったく行わないよりも悪い。というのも、「はい、このソリューションは素晴らしいです」以外の回答を持ち帰れば、納期が危うくなるからだ。その結果、リサーチャーはユーザーテストの参加者が抱えている問題を軽く扱い、肯定的な調査結果のみに注目するよう（意識的に、または無意識的に）圧力をかけられることもありうる。
そして、検証に固執していると、「ええ、いいですね」という参加者の反応は、そこで話を打ち切れそうな区切りのように聞こえる。結局のところ、そうした返答は、ソリューションの背後にあるデザインの意思決定の裏づけになるからだ。一応、リサーチャーが参加者に欠点についても言及するよう促しても、「いいえ、変えたいところはないです。良いと思います」という答えが返ってきたりもする。
しかし、そうした返答は誤った結論につながりかねない。
そのつもりがなくても、ユーザーインタビューで肯定的な反応を得るのはこれ以上ないほど簡単だ。ユーザーが新機能や改善に対して「いいえ」と否定することはめったにないからである。質問の聞き方が、ユーザーに何らかのトレードオフを求めない場合は、特にそうだ。また、質問の言い回しによって自分の望むことを言うように参加者を誘導することも可能だ。たとえば、「何が難しかったですか」や「どれくらい簡単でしたか」と尋ねることは、期待している答えをほのめかすことになりうる。
その上、調査参加者はリサーチャーを喜ばせたいと思っているものだ。テストしているプロダクトをデザインしたのがリサーチャー自身だと彼らが思っている場合は、特にそうである。率直な意見を話すのではなく、あなたが聞きたがっていそうなことを言いかねない。
「使う人はいると思いますよ」という返答は、参加者がリサーチャーに気を遣っていることを示す典型的な兆候といえる。しかし、参加者がそれを使うかもしれない人物を思い描けたとしても、それはデータではなく、単なる推測にすぎない。調査参加者に、他人の行動を想像するよう求めてはならない。この返答から得られるデータは、その参加者が自分ではそれを使わないことを認めている、ということだけである。
態度データは行動データで補強される必要がある
検証しているアイデアへの参加者の反応がどうであれ、彼らの意見だけに耳を傾けることには重大な限界がある。つまり、人は言うこととやることが違う、ということだ。人は自分の将来の行動を予測するのが得意ではない。将来の行動はそのときには考えていなかった要因に大きく左右されるからだ。参加者が、そのアイデアが抽象的なユースケースには合っていると考えたとしても、それは具体的な現実の状況では破綻する可能性がある。
参加者にソリューションのアイデアについて尋ねて収集できるデータは、態度データという1種類のデータだけだ。さらに厳密性を高めるために、行動データも収集するよう努めるべきである。可能であれば、プロトタイプテストのような調査手法を用いれば、参加者がソリューションについて何を言うかだけでなく、実際にどのように使いそうかに関する知見も得られるだろう。
しかし、検証というレンズを通して見ると、行動データでさえチームに不正確な印象を与える可能性がある。態度データが「はい・いいえ」へと単純化されるのと同じ誘因によって、行動データも「ユーザーはタスクを成功裏に完了できた」という評価に単純化されうるからだ。こうなると、「はい」を導き出すようにという圧力で、チームは参加者に対し、最も異議の出にくいユースケースや案だけを提示してしまう恐れもある。
一方、リサーチャーがより幅広い知見を得る準備ができていれば、ずっと挑戦的な視点や、より複雑なシナリオをテストできる。そして、参加者が最終的にどこで線を引くのかを見ることで、参加者からはるかに多くのことを学べる機会を得られる。その場合、教訓になるのは、参加者が成功したか失敗したかという単なる事実ではなく、参加者がどのように成功し、どのように失敗したかである。
二者択一の検証は次のアクションにつながらない
調査の目的は、意思決定に情報を提供することである。つまり、調査から得られる知見は、実行可能であり、次のステップを促すものでなければならない。ところが二者択一の答えは、その逆で、これ以上検討する必要がないかのような印象を与える。
二者択一の検証を行うよう求められたリサーチャーは、どちらか一方の結果を裏づける発言の引用と測定値という、二者択一のデータを収集することになる。しかし、なぜそうなったのかについての知見がなければ、「はい」（我々は成功した）であれ「いいえ」（我々は失敗した）であれ、そこで行き止まりだ。これが、検証に従事しているチームが「はい」を持ち帰るように圧力をかけられる理由である。きっぱりとした「いいえ」は、それまでのすべての作業が無駄になることを意味するからである。
しかし、仮説が完全に正しい、または完全に誤っていることはめったになく、調査を通して収集されるデータは、こうしたニュアンスをとらえている必要がある。自分たちのアイデアが「どのように」成功し、同時にどのように失敗したのかを学べるチームは、調査からより多くの価値を得ることができる。それによって、プロダクトの強みと弱みについての全体像を作り上げることができるからだ。その結果として示される「いいえ」であれば、ステークホルダーにとってもはるかに受け入れやすい。というのも、それにはただし書き（「このコンテキストではない」）または改善に向けた道筋（「この機能がない限りは」）が伴うからである。
調査を検証のためのツールとしてのみ使用するプロダクトリーダーは、最終的に、投資収益率（ROI）があまりにも低くなる結果に終わるか、誤った仮定とともにソリューションの有望な部分を捨てることになる。しかし、ソリューションの強みと弱みをそのニュアンスまで理解できれば、反復を重ねていこうという姿勢が生まれ、チームはより大きな価値を手にすることができるだろう。
記事で述べられている意見・見解は執筆者等のものであり、株式会社イードの公式な立場・方針を示すものではありません。
