ゴール、目的、仮説を定義する

ユーザーリサーチの実施には、ユーザーに何かを尋ね始める前から、かなりの準備が必要です。しかし、合意形成を行いリサーチ計画を立てることに費やす時間は、リサーチを実行する際の道筋を保つのに役立つため、非常に 報われます。

良い質問 と 適切な質問から始めることで、有用な答えにたどり着けます。良いリサーチ質問は、具体的で、実行可能で、実用的です。つまり、

• あなたが利用できる手法・方法を使って、その質問に答えることが可能であること。
• 学んだ内容に基づいて意思決定を行うのに十分な確信度をもって、答えに到達する可能性があること（ただし保証はない）。

リサーチ質問を特定して初めて、その質問に答えるための最適な方法（例えば、どのリサーチ手法を使うか）を選択できます。

下の図に示すように、リサーチの仮説、ゴール、目的を作成する主なステップは5つあります。

ステップ1 - 問題について考え始める

顧客の問題を聞くと、すぐに飛び込んで解決策を考案したくなることがあります。しかし、問題に対して唯一の良い解決策があるわけではないということを覚えておくのが重要です。問題は、何にフォーカスする必要があるかによって、さまざまな方法で解決できます。

ユーザーは予測不可能でもあります。私たちが彼らのペインポイントを解決すると考えるものが、実際には彼らが直面している問題に対処することを始めないかもしれません。そのため、解決策の構築を始める前に、アイデアをテストすることが望ましいのです。これを行う一つの方法は、仮説を書き、テストすることです。

仮説とは？

仮説とは基本的に仮定です。今日真実だとあなたが信じていることに関する記述です。リサーチを使って証明または反証できるものです。

強い仮説は通常、既存の証拠によって駆動されます。自問してみてください。なぜあなたはその仮定が真実だと信じているのですか？ もしかすると、その勘は顧客との何気ない会話、サポートチケットやIssueで読んだもの、あるいはGitLabの利用データで見つけたものから生まれたのかもしれません。

• 自問してみてください。
  • ユーザーについて、現在どのような信念を持っていますか？
  • 留意すべき組織的またはその他の障壁は何ですか？
  • プロジェクトのビジネス目的は何ですか？
  • リサーチが答える必要のある質問は何ですか？
  • 私たちは何を学ぼうとしていますか？
  • リサーチが 必ず 達成すべきことは何ですか？
  • 以前のリサーチ は存在しますか？
    • 以前のリサーチは何を教えてくれましたか？

ステップ2 - ‘答えが必要な質問’ を埋め始める

• これはステップ1から思いついた答えすべてのブレインダンプを意図しています。
• これはユーザーに直接尋ねる質問ではありません - ディスカッションガイドを埋めるときに、後でそのステップに到達します。

ステップ3 - 仮説を埋める

• ステップ2でリストした質問を導きとして使用してください。

仮説の構造化方法

仮説にはさまざまな構造がありますが、良いアプローチはこのシンプルな文を使うことです。

「私たちは、[これらの人々] に対して [これを行う] ことで [この結果] を達成できると信じている。」

この文は3つの要素で構成されます。

1. 私たちは、[これを行う] はユーザーの問題に対する提案された解決策を詳述するべきです。
2. [これらの人々] に対して はあなたがターゲットにしているのが誰かを特定するべきです。
3. [この結果] を達成できる は成功の指標を文書化する場所です。あなたの期待される結果は何ですか？

例:

仮説を書くときは、まずシンプルな解決策にフォーカスし、スコープを小さく保ってください。ユーザーに関する仮定をうまく表現できないときは、弱い仮説を形成して目的のないリサーチ研究を行うよりも、まずユーザーへのより良い理解を深めることから始めるほうが恐らくよいでしょう。

ステップ4 - リサーチのゴールを述べる

• ゴールは、答えに到達したかを把握できるほど具体的で、研究のスコープ内で答えられるほど実用的で、リサーチ研究を完了した後に発見に基づいて行動を起こせるほど実行可能である必要があります。
• ゴールは、リサーチの発見によって答えられるべき中心的な質問です。
• ゴールは常に動詞（identify、understand、learn、gaugeなど）で始めてください。
• プロジェクトごとに定義するゴールの数を制限してください。1つか2つのことを非常によく学ぶようにしてください。これにより、リサーチをデザインの結果につなげ、ユーザーの行動の1つの側面について明確な理解を得られます。

ステップ5 - リサーチ目的を作成する

• うまく書かれたリサーチ目的のリスト:
  • プロジェクトのゴールを描き、整合させます。
  • 全体的な高レベルアプローチと、尋ねるかもしれない質問を定義します。
  • 利用できる最も適切な手法とツールを規定します。
  • 研究から得られる結果を決定します。
  • 高レベルでありながら、リサーチが各々について簡潔な答えを提供できるほど具体的である必要があります。
• リサーチの取り組みごとに 4つを超えない目的 を作成してください。1つの研究で4つを超える目的を達成しようとすると、各目的がディスカッションガイドで最大12個の質問／タスクを表すことになるため、やりすぎになります。
• ‘答えが必要な質問’ のリストをレビューし、そこに見えるテーマを特定してください。以前に書いた ‘仮説’ と ‘ゴール’ を参照してください。

下の図表は、リサーチのゴールと、ユーザビリティテストで参加者に尋ねるタスクや質問との関係を示しています。

この図表は、リサーチのゴールと、ユーザーインタビューで参加者に尋ねるインタビュー質問との関係を示しています。

ご覧のとおり、開始時に持つ目的が多ければ多いほど、尋ねる必要のある質問が増え、リサーチセッションが長くなります。ユーザーセッションが1時間を超えないようにするのが良い経験則です。GitLabでの典型的なリサーチセッションは30〜45分続きます。

仮説をテストする

良いユーザーリサーチプロジェクトは、パフォーマンスデータと態度データの両方を評価することによって、仮説が真か偽かのように見えるかどうかを確認できる条件を作り出します。シンプルな2値の指標（はい/いいえ、合格/不合格など）がパフォーマンスデータを収集するために使われます。態度データ、たとえばセンチメントや意見は、参加者のエクスペリエンスを説明するのに役立ちます。

強い仮説はテストしやすいものです。仮説を検証または無効化するためのリサーチ研究を設計するのに、多くの時間はかからないはずです。

仮説がユーザーによって無効化されたとしても、落胆しないでください。あなたは、ユーザーの問題を解決しない解決策の構築に貴重なエンジニアリングの時間が費やされるのを止めたのです。何かを捨てることは、ユーザーリサーチがそれが機能しないことを証明したことの良い指標であり、これがイテレーティブであることの良い指標です。最初から物事を正しく行えるとは限りません。複数の仮説をテストすることでユーザーニーズについてより多く学び、その結果、将来のラウンドのテストのための新しいアイデアを生み出します。

ページのソースコードを見る - ページの編集 - please contribute.