Designer - 2024 -
ユーザーインタビューは、手がけるプロダクトの良い点、悪い点を明らかにしたり、プロトタイプ形成にも一役買ってくれるだろう。ただし、そこにかける時間や費用が必ずしも効果をもたらすとは限らない。プロダクトにしっかりと関わり、ユーザーインタビューの必要性について考えてみよう。
ペインポイント(痛み)やアハモーメント (快感・喜び)を可視化していく手段としては、綿密な行動分析によるユーザーストーリーマッピング、仮説による簡易ペルソナ、データなどファクトに基づいたペルソナ、制作者のヒューリスティック評価など様々だが、プロダクトが成長していく過程においてはユーザーインタビューが効果を発揮するケースがある。もっと言えば、ユーザーインタビューやアンケートのみでしか拾えない要素がある(かもしれない)。
さて、ユーザーインタビューにより拾い上げられる情報には、喜び、希望、苦痛など様々なものがあるだろうが、例えば通院するという体験を考えてみても、週に何度も大きな病院に通う年配の方は、一連の体験の中で感じるストレスをある程度受け流すことも可能だろうし、逆に年に数回しか病院とは縁が無いといった一般的な人であれば、様々なストレスをそのままの尺度で感じ取り、時に激しいほどにその痛みを評価するだろう。
上記の理由により、ユーザー・インサイトを拾い上げていく際には、(有限な時間と予算のなかで)ユーザーの許容値と必要な施策のバランスをコントロールすることが重要になってくるだろう。スティーブ・ポーチガルはその著書「ユーザーインタビューをはじめよう」の中で、「ユーザーリサーチの問題をいっそう複雑にしているのは、デザイナーやエンジニアがペインポイントととらえられていることを、人々が必ずしも痛いと感じていないという事実である。1956年にハーバート・サイモンがsatisfyとsufficeを合わせた造語satisficing(最善の選択肢ではなく、満足できる選択肢を求めること)は、100パーセント喜んで受け入れるとまではいかなくても、人はそこそこのソリューションに対して寛容なことを言い表している。」と述べている。
また自宅のリビングにあるラックには無駄なものも並んでいると語りかけながら、「率直なところ、私はどのリサーチプロジェクトもそこそこでよしとする。デスクトップ上にある整理されていないMP3ファイル、はまりの悪い食品保存用の蓋、絡まって長さの足りない接続ケーブルは、どれもそこそこという満足化の例だ。言い換えるなら、人は問題がもたらす痛みよりも、問題を解決する労力のほうが煩わしいと思うものなのだ。あなたがニーズと認識したことは、もしかしたら顧客にとっては問題なく容認できることかもしれない。彼らは食品をしっかり密閉できる容器に入れたいと思っているだろうか? もちろんだ。ではそのためにちゃんと手間ひまをかけるだろうか。多分かけない。」とユーザー心理のひとつの核心に触れている。
ユーザーインタビューが有益と思われるのは以下のような状況・段階においてではないだろうか。
上記も同著書からの引用になるが、ユーザーインタビューが効果を発揮するケースとそうでないケースの見極めは非常に重要になってくる。経験から言うと、UIUX設計の質が低い企業はインタビューの設計も満足に出来ていないケースがほとんどである。HCDなどのブームもあり、なんでもユーザーにという風潮もあるが、上記のようにまずはしっかりと仮説を立てることが大前提であるし、仮説そのものも設計力に依存するものであるから、インタビュー内容もなんとなく、分析もなんとなく、プロダクトへの落とし込みもなんとなくという悪循環に陥ってしまうことにも繋がるフレームワークであることは銘記すべきであろう。
ユーザーインタビューで引き出したいのは客観性である。それもなるべくなら、デザイナーの経験則や、各部署に蓄積されたデータよりも、何かしらの輝きがほしい。正直なところ、若いスタッフが私の経験則に勝るインタビュー企画を作れないということも多い。部署間のつながりや、製品を売るうえで一番大切な部分を深く考え、どの部分のインサイトを拾い上げていくのかをはっきりさせてから本番に臨もう。
さて、企画が通り、実際にインタビューが行われることになった際は、対象者とのラポール(信頼関係)の形成にはどのような作法が有効だろう。今月、原宿のとある美容院に2度目の訪問をした際、担当の若い子がやたらと親しげに、軽やかに会話を始めてきた。「信頼して、また訪問してくれた」というだけで相手は心の底から話を切り出してくるものだ。うれしさや驚きがあると、人は人に親近感を抱き、やがて信頼する。地位や見た目、人柄など様々なファクターはあるだろうが、バイアスは必ず外れる。ユーザーインタビューも対ヒューマンの施策であることを銘記しておこう。
言ってみれば、ユーザーインタビューというのは昔から行われてきた「原始的」なものだが、良きものもそうでないものも拾い上げてしまう「あつかいにくいフレームワーク」でもある。
「ユーザーが良いと言っていたからプロダクト設計は間違っていない」ではまったくもって不合格であり 、安易に組織の中に中途半端な情報を流されることは、もっともおそれる「のぼり方」とも言える(こういった時の損失は、インタビューにいくら払ったかなんていうものとは桁が違ってくるのだが、組織の中にあってビジネスやモノツクリのセンスのない人が「保身」的にこういった情報を流すケースも見てきた)。
あくまで一旦は経験者の各種手法に委ね、各タッチポイントが鮮明になったタイミングで、さらに深掘りした方が良い点を(経験者と共に)ピックアップし、ユーザーインタビューの結果を吟味しながら(仮説に裏付けを行い)バックログ化していくことが大切である。
もちろん経験者とはインタビューの名人ではなく関連各部署の名人(深い専門性を有した方々)を指している。