ユーザーリサーチ入門

リサーチが必要な理由から、具体的な検証方法まで。

2018年3月15日と4月25日にPivotal Labsで開催したmeetupのイベントレポートです😎

Pivotal Labsでは、定期的に無料のmeetupを開催しています。実践的ですぐに使える内容になるよう、ワークショップ型のイベントを基本としています。
３月と４月に開催した「ユーザーリサーチ入門」イベントの中で、「スライドを公開して欲しい」という方が数名いらしたので、内容をまとめることにしました！

イベントの前半はPivotal Labsでのユーザーリサーチの進め方の紹介、後半はインタビューの実践練習という構成でした。前半の部分のスライドと内容を公開します！
また、Pivotal Labsでは、ペアデザインを行っています。今回のスライド作成＆当日のトークも、プロダクトデザイナーのCanyonと私でペアをしながら共同で行いました😊

◆目次◆
1. Pivotal Labsは何をする会社？
2. ユーザーリサーチはどうして必要なの？
3. Pivotal Labsのデザインプロセス
4. デプスインタビューについてもう少し詳しい話

Pivotalでは、ペアプログラミングだけでなく、デザインやプロダクトマネージメントもペアで進めます。この写真ではたまたまクライアントが4名、Pivots（私たちは社員のことをPivotと呼びますw）が2名ですが、クライアントとPivotal社員はそれぞれ同じ人数でプロジェクトが組まれます。

プロジェクトの期間中は、クライアントチーム全員が六本木ヒルズのPivotalオフィスへの出勤します。Pivotsとクライアント混合チームとしてフルタイムで一緒に開発を進めることで、手法の伝授とチームビルディングを行います。

ウォーターフォール型開発の流れと役割分担です。チームごとに多少差はあっても、大方このような体制であることが多いのではないでしょうか。

ウォーターフォールとの対比をすると、Pivotalの開発体制はこのような形です。「バランスチーム」と呼ばれるチーム構成で、常に３つの視点から議論＆決断をすることで、バランスの良いプロダクトを一緒に作っていくと考えます。理想のチームは、全ての役割のパワーバランスが同等で、どんな意見も言い合えるようなチームです。

私たちの開発方法は「Pivotal手法」と呼ばれることもありますが、新しい手法を作り出している訳ではありません。それぞれ３つの役割でベースとする手法があり、それらを組み合わせています。デザイン部分は「ユーザー中心設計」や「デザイン思考」、プロダクトマネージャが担うビジネス面は、「リーンスタートアップ」、デベロッパーはアジャイルの一派である「エクストリームプログラミング」の考え方と開発手法が基になっています。

縦軸はリスク（検証されていないものにかける労力）、横軸は時間を表しています。赤い線は、リリースまで結果が分からないウォーターフォール型開発のリスクを表しています。プロダクトに対する「思い込み」を検証をせずに、新しい機能をどんどん追加することで、リスクがどんどん増えてしまいます。

反対に、リーンやアジャイルでは、「思い込み」がないかどうか細かく検証をするので、その都度リスクを抑えることができます。このサイクルを、「作る・測る・学ぶ」サイクルと呼びます。

「思い込み」の定義です。思い込みにも、色々な種類がありますが、大きく分けて競合、顧客（ユーザー）、技術の３つにカテゴリ分けすることができます。

「思い込み」は、自然と正しいと思い込んでいるから「思い込み」なので、なかなか自分で気がつくのは難しいものです。そこで、Pivotalでは、スライドにあるような定型文に当てはめて、「思い込み」の洗い出しを行います。（この定型文に当てはめることを何度か繰り返していくうちに、自然と自分の思い込みに気づけるようになります。）

と、ここまで理論的な話が続いたので、、妄想プロダクトで具体的な例を紹介します。

猫同士が出会える、マッチングアプリです。想定ユースケースはこんな感じです↑。家で１人寂しく、悲しい思いをしている猫がターゲットのサービスです。

このユースケースにはたくさんの「思い込み」が隠れていますね。顧客（ユーザー）、技術、機能案に関する思い込みで、それぞれリスクの高そうなものを例として挙げました。このように、新しいサービス案を思いついた時や、新しい機能案を思いついた時、すぐに開発を始めるのではなく、一度立ち止まって思い込みの洗い出しとリスクの順位づけをしてみてください。

Pivotal Labsでは、サービス案からいきなり仕様書を作成し、画面デザインをする、ということはしません。まずはペルソナを使ってユーザーを検証し、次にシナリオでユースケースを定義します。シナリオを基に手書きのスケッチでアイディア出しをしたあと、ワイヤーフレームレベルのプロトタイプを作って機能案の検証をします。（ここで初めて、Sketchなどのデザインツールを開きます。）そして、機能案の検証ができてから、UIやインタラクションを作り込んでユーザビリティテストを行います。また、それぞれのステップは一度決めたら終わりではなく、リサーチを通して新しいことが分かればその都度アップデートを行います。

まず１つめのステップであるユーザーの検証は「デプスインタビュー」で検証します。まずは「プロトペルソナ（仮のペルソナ）」で、ユーザー像の仮説を立て、本当に当てはまる人がいるのか？を明らかにします。ここでのポイントは、想定デモグラフィックに当てはまる人がいるかどうか？だけではなく、その人は想定した「行動」をしていて、想定した「課題やニーズ」を抱えているかどうか？を確認することです。私が今まで経験したプロジェクトでは、プロトペルソナが100%合っていたケースはありませんでした。必ず何かしら間違っているので、リサーチ結果を基にペルソナ像をアップデートします。一定期間探してもインタビューする人が見つからないときや、複数人に話を聞いてもパターンが見つからないときは、そもそも想定ユーザーが存在していない可能性があります。

ユーザーの存在が確認でき、答えるべきニーズや解決するべき課題が明確になったら、機能案を検証するフェーズに入ります。まずは、ユーザー目線でサービスとの関わり方を定義する「シナリオ」を作成します。次に、シナリオを基に手書きのスケッチで機能案のアイディア出しをします。数多く出したアイディアの中から、確度の高そうな案を選んだら、「評価インタビュー」で機能を検証をするためにプロトタイプを作成します。ここではワイヤーフレーム程度の完成度で、まだUIの作り込みはしません。このインタビューでは、ユーザーがプロトタイプを使って問題を解決できるか？または、目的を達成できるか？を確認します。使い勝手に戸惑っていても、ユーザーが必要とする情報があるか？また、その情報を見せる順番は正しいか？など、機能の大枠が間違っていないかを検証します。答えは「イエス」か「ノー」の二択です。「ノー」の場合は、ユーザーから何故使えないのかを聞き出し、別の機能案を考えます。

機能案の検証ができて初めて、色・文言・インタラクションまで含めたUIを作り込む段階に入ります。そして、プロトタイプを使ってユーザビリティテストをします。この段階では、ユーザーがどのくらい使いこなせるか？を確認します。ユーザーがどこで躓いたか、もしくは迷わずに使い切れたか、に注意して観察します。答えは、「使いにくい」から「使いやすい」のグラデーションで評価します。使いにくい部分は、改善をします。

ユーザビリティまで検証ができたら、リリースをして、引き続き検証をします。リリース前に使われ方について予測を立てて置くことが大切です。例えばCats Meetの場合は、想定ユーザーに使われているか？想定したようなプロフィール写真がアップされているか？想定した頻度でアプリを開いているか？などのポイントでチェックすることが考えられます。事前に予測を立てておかないと、アナリティクスを見て闇雲に一喜一憂することになってしまいます。

イベント後半のワークショップが、デプスインタビューの練習だったので、それについてもう少し詳しく紹介しました。

デプスインタビューでは、質問のガイドとして「トピックマップ」を利用します。写真にあるように、ペルソナを基にチームで検証したい「思い込み」を洗い出した上でトピックごとにまとめます。これもデザイナーだけではなく、必ずプロダクトマネージャも一緒で、場合によってはデベロッパーも一緒に作成します。トピックマップは、ユーザーから出てきた話の流れに合わせてトピック間を移動できるので、自然な会話をするようにインタビューをすることができます。そうすると、より深い本音を引き出しやすくなります。逆にスクリプトを使うと、質問を１から順に聞いていく形になるので、どうしても尋問のような聞き方になってしまいがちです。

インタビューは、ユーザーができるだけリラックスできる環境を作るように心がけます。Pivotalでは、同席するのは、[ ユーザー・インタビュアー・ノートを取る人 ] の３人になるようにします。インタビューを進行するのはインタビュアー１人で、ユーザーの近くに座り、１対１の会話となるように気をつけ、深く話を掘っていくようにします。ノートを取る人は、少し離れたところに座り、ユーザーの言うことや表情を全て静かに記録します。

インタビューの分析も、写真のようにチームで行ないます。分析の目的は、複数ユーザーの間にパターンがあるか？を見つけることです。そうすることで、１人に最適化されたプロダクトを作るのではなく、複数の人が共通して抱える課題やニーズに答えるプロダクトを作ることができます。分析の中でパターンを見つけやすくする為に、ノートは、ユーザー１人につき１色、１つの発言につき１枚の付箋に記録をとります。そして、付箋をトピックごとにグループ化していくと、その中に何色の付箋があるのか？で何人のユーザーが同じことを言っていたのか？を視覚的に確認することができます。

おまけ：ワークショップの様子

２日とも、３人ごとのグループに分かれ、[ インタビュアー・ユーザー・インタビュアーへフィードバックする人 ] の３つの役割を全て体験できる構成でした。みなさん「難しい〜！」と言いながらも、それぞれのグループで盛り上がっていました。

3/15の様子。プロダクトデザイナーのマリアム＆Meghan Radkeの共同ファシリテーションでした。

4/25の様子。プロダクトデザイナーのMeghan Radke＆プロダクトマネージャのYui Anzaiの共同ファシリテーションでした。

参加してくださったみなさま、ありがとうございました〜✨

以上、イベントレポートでした。長くなってしまいましたが、最後まで読んでいただき、ありがとうございます。ユーザーリサーチやプロダクトデザインを進める上で参考になると嬉しいです。

Pivotal Labsでは、定期的にワークショップ型イベントを開いたり、ブログでプロダクト開発やチームビルディングなどについて紹介していきます。

イベントの最新情報：
Meetupグループに参加すると、いち早く案内が届きます😎📩

公式ブログ：
Product Runも是非フォローお願いしますっ🙌🏻🗒