ユーザーの現状理解をすべきだ、そして課題の本質を探れ、ユーザーのニーズをそのまま機能にのせるな、まずは課題の深堀りからだ！
UXデザインの本を読んだり勉強会に参加したりワークショップに出向いたりすると耳が痛いくらい同じことを言われる。大切さは理解しているし、実際の業務で直面しなければ出来そうな気にはなる。
そう、実際の業務に直面した瞬間、それは非常に難しいことに気がつく。
課題を深ぼっていたはずなのに気がつけば解決策を検討していたり、解決策がいつの間にかに課題からそれていたり。ヒアリングの設計だってめちゃくちゃ時間がかかってしまう。
ではどうしたらいいのか、経験したこと・学んだことを記録に残していこうと思う。
今回はリサーチから意思決定までのプロセスのなかで、UXデザイナーとかプロダクトデザイナーとかと言われる私達がどのように関わっていくべきかについてまとめてみる。
その前にまずはデザイン・リサーチの定義について考えてみようと思う。
デザイン・リサーチとは
大雑把に言ってしまえば、課題を発見するために、ユーザーのもとへ出向き、ヒアリングをしたり現場を見たりすること。ってなるんだけど、実はリサーチの観点って3つあると思う。ここを混同してしまうと、なんのためにリサーチしているのかの目的を見失ってしまう。
- 私達のプロダクトやサービスにどのような課題がありそうかを知る。
日々の定量調査だったり、BtoBであれば営業やカスタマーサービスから入ってくるユーザーのニーズなどを探り、課題の重要性（解決しないとプロダクト価値が提供しえないとか）を見ていく。
これはデザイナーが主導して行うというよりむしろプロダクトマネージャーやオーナーとともに並走していくのが理想的に感じる。 - 「こういう機能あれば良さそうだよね〜」に対しての課題を見つける。
大抵は1で出てきた課題に対して既に必要そうな機能のアイデアがいくつか出ている。が、ちょっと待った。ここでさらにユーザーにヒアリングしたりユーザー行動を実際に見たりして、実際のところどんな状況でどんな問題があるのか？を今一度見てみる。
本質的な課題を探れ！とよく言われるのはこのフェーズで行うことと思う。
ここで色々でてきたアイデアの妥当性が実証されて、何をすべきかがはっきりする。 - 使い勝手の検証
俗に言うユーザビリティテスト。多くは新機能開発などでエンジニアが開発する前に、デザイナーが作ったプロトタイプをユーザーに触ってもらう形で実施する。
課題が解決され価値が提供できているかという軸はあまりここでは実証できないと思う。なぜならプロトタイプをその場で触っているだけなので、ユーザーが実際に利用している背景とは違うから。
もし価値の実証を行いたいなら、β版などで1ヶ月ほど運用しヒアリングする手法が妥当と思うが、フルリニューアルとかでない限りは、リリースしちゃって1の調査の中で検証して行くほうがスピードを失うことなく改善サイクルが回せるのではないだろうか。
課題発見から意思決定までのプロセス
では本題。
2.「こういう機能あれば良さそうだよね〜」に対しての課題を見つける。
について、どういうプロセスで行えばいいのだろうか。大体の課題はわかっている、解決案もいくつか出ている。さぁ、あなたならどうしますか？
私は何度も失敗しました。一人で時間をかけてあーでもないこーでもないと考え、一つの解決案を出してチームに共有すると、「そもそもなんでやるんでしたっけ？」ってなる・・ということがあり（ひとしきり落ちこだ後に）プロセスに目を向けてみた。
大体の課題やニーズがはっきりしたら、私達プロダクトデザイナーが以下のプロセスで検討内容を意思決定の場にもっていくとうまくいくのではないだろうか。
- 課題を細分化し、仮説をいくつかたてる
- 細分化した課題に対してそれぞれのアイデアを出す
- 上記の状態でチームに共有し知識をシェアしたり、議論を行い、チームの意見の中で検討を深める
- 課題の仮説やアイデアをもとにユーザーへヒアリングを行う
- ヒアリング内容をもとに、プロダクトマネージャーの意思決定を支える提案を行う
UXデザインプロセスを必要とする課題やニーズには抽象度が高いことが多い。抽象度が高いということは一つの課題に様々な小さな課題が含まれている。まずはその小さな課題をいくつか予想してみる。
もし難しいと感じた場合は、逆に解決案から考えてもよいかもしれない。この解決案ではどんな課題が解決できるのだろうか？と。
私がよく使う手法は構造化シナリオ法の行動のシナリオ。課題には必ず課題を巻き起こす背景やシーンがあるはず。そしてシーンから分解すると仮説が立てやすいし、シーンごとの課題が想像しやすい。
アイデアはすでにあるものを当てはめてもいいし、他のサービスではどうしているか調べたり、まずは思いつきでもよいと思います。
とにかくたくさん課題をだしてたくさんアイデアを出す。まずは選択肢を広げて視野を大きく持つことが大切と思います。なぜならこれが機会発見につながるから。
そして、この状態で一旦チームと議論をする。課題の方向性はブレていないかのフィードバックや営業やカスタマーサポート、開発それぞれの知識や見解を聞きながらある程度方向性を絞っていきます。また議論中にユーザーに聞かないとわからないということがあれば、このあとのユーザーヒアリングで聞けば良いです。
ユーザーヒアリングでは主に仮説を検証します。仮説の正当性はもちろんですが、意図してない課題は他にないのかについても確認してみると仮説の検証漏れを防ぐことができます。
そして結果をプロダクトマネージャーと共有し、意思決定を支えていく。
プロダクトデザイナーが行うAs Isフェーズの課題発見はこんな感じでうまく回るはず。
最後に
まだまだいろんなプロセスを試しながらなので、ご指摘などあればコメントください。
今回はプロセスに焦点を当てたので、それぞれの手法についてはざっくりとしています。詳細についてはまた改めて書いていきます。
コメント