リサーチインサイト
インサイトとは？
調査研究を実施するとき、私たちには調査質問を調査する際にガイドとなる目標と目的があります。機能のユーザビリティを評価したり、探索的なインタビューを実施したり、定量的データを収集したりするかどうかにかかわらず、調査研究はおそらく、ユーザーの体験に関連する観察、パターン、行動のリストになります。研究からの生データが調査結果です。
調査結果のリストだけでは、多くの場合、ユーザーがトピックをどのように概念化しているか、またはなぜ特定の苦労を経験したかを完全に伝えるには不十分です。調査研究で収集されたデータの分析と統合を通じて、関連する懸念事項間の点をつなぎ、追加の理解レイヤーを提供するインサイトを蒸留することができます。これらの統合された調査結果は、ステークホルダーが情報に基づいた意思決定を行うことを可能にする一貫したインサイトのコレクションに進化します。各インサイトは、議論中に参照できる証拠で裏付けられており、通常はビデオクリップ、インタビューの引用、または統計データの形式です。
GitLab では、調査研究によって生成されたインサイトを次のように追跡します:
- インサイトを「実行可能」または「情報提供」として区別する
- 各実行可能なインサイトに明確な推奨事項またはアクションが関連付けられていることを確認する
- 実行可能なインサイトの完了を追跡する
インサイトには 2 つのタイプがあります: 実行可能と情報提供。
- 実行可能なインサイトは、解決するためにアクションが必要な調査結果です。これには、UI の変更、機能の追加、さらには追加の調査の実施が含まれる場合があります。これらすべてのインサイトは、調査を実施した人が、提案されたソリューションのパスとともに実行可能なインサイトを文書化する GitLab Issue を作成することを必要とします。
- 情報提供のインサイトは、トピックに関する追加のインサイトを提供するが、解決するものが何もないためアクションを取る必要のない調査結果です。情報提供のインサイトは Dovetail でのみ作成されます。
情報提供のインサイト
情報提供のインサイトは、何かや誰かについて学ぶのに役立ち、即時のアクションをもたらしません。代わりに、これらのインサイトは、ユーザー、業界、競合他社などについての知識を構築するのに役立ちます。例えば:
- 調査に参加した開発者のほとんどは、学生のときに最初に GitLab に紹介されました。
- 開発者は、仕事の一部として GitLab に加えて約 3 つの他のアプリケーションを使用しています。
情報提供のインサイトを文書化する際、特別なアクションやプロセスに従う必要はありません。これらは単に、標準プロセスに従って Dovetail に文書化するか、対応する調査レポート（例: Google Slides）に文書化します。Dovetail または調査レポートへのリンクを調査 Issue に含めます。
調査レポートに Dovetail または Google Slides を使用するタイミングに関するガイダンス
Slides は、インサイトの背後に語るストーリーがある場合（つまり、結果のコンテキストと重大度を聴衆が理解するのを助けるため）、および／またはより多くの議論とコラボレーションを必要とするより大きなインサイトの場合に最適です。文書化されたデッキは、より広範なアクセシビリティ、進行の追跡、歴史的な参照（つまり、将来参照することを予想するトピックではデッキがうまく機能します）に役立ちます。
Dovetail は、説明が少なくスコープが小さいインサイト（例: 機能固有のユーザビリティ調査結果）を文書化するために使用される場合があります。
実行可能なインサイト
実行可能なインサイトには、調査の観察やデータの結果としてフォローアップアクションが常に必要であり、明確な推奨事項またはアクションが関連付けられています。実行可能なインサイトは、インサイトを定義し、次のステップを明確に呼び出します。以下に 2 つの異なる例を示します:
- 提案されたデザインで「Submit」ボタンが見つけられなかったため、ユーザーはマージリクエストを送信できませんでした。彼らはそれがページの上部にあることを期待していました。アクション: デザインをイテレーションして、「Submit」ボタンをページの上部に移動して再テストする（Issue # XYZ へのリンク）。
- IT 管理者は、15 分単位でチームの活動を時系列で表示する方法を望んでいます。IT 管理者は、新しい会社のポリシーの一部としてこの情報について報告するように求められています。アクション: そのようなリクエストの実現可能性を探る（Issue # ABC へのリンク）。
機能や使用中の製品エリアへの変更を提案する実行可能なインサイト Issue を作成する際、そのエリアに関連するトップ JTBD への変更のより広範な影響を認識してください。インサイトを裏付けるデータが、強調された問題に対する十分な確信を提供しない場合は、それを検証するための追加の手段を取ってください。
実行可能なインサイトの文書化方法
実行可能なインサイトは、情報提供のインサイトとは異なる方法で扱う必要があります。実行可能なインサイトは時間とともに追跡され、フォローアップを含むため、実行可能なインサイトを Dovetail と GitLab で固有の Issue として文書化します。
実行可能なインサイトを文書化するとき、その 3 つの主要な要素は次のとおりです:
- インサイト自体: 多くの場合、問題、発見、または観察。
- 「なぜ」: インサイトを支持する裏付け証拠。多くの場合、問題が発生している理由、または発見や観察の背後にある詳細を説明します。
- アクション: 調査の結果として実行する必要のある次のステップまたはアクション。アクションは明確に定義され、達成可能であり、インサイトに直接結び付けられている必要があります。
実行可能なインサイトを書くためのヒント:
- consider, possibly, maybe, suggest など、人々がオプションとして解釈できる言葉を使わないでください。
- 代わりに、conduct, explore, redesign などの指示用語を使用してください。これらの言葉は、次のステップとして取る必要のある明確なアクションに貢献します。
実行可能なインサイトを文書化するには:
ステップ 1: Dovetail にインサイトとしてすでに文書化されている場合、実行可能なインサイトのタイトルの前に「ACTIONABLE:」を付け、取る必要のある次のアクションを明確に説明します。プロジェクトで Dovetail の代わりに調査レポートにインサイトを入れている場合は、このステップをスキップしてください。
ステップ 2: GitLab.com/GitLab-org/gitlabで、適切な実行可能インサイトの Issue テンプレートを使用して固有の Issue を作成します:
Actionable Insight - Exploration needed - これは UX 調査研究から派生した実行可能なリサーチインサイトです。このインサイトに対処するには、さらなる探索が必要です。それは、フォローアップ調査、デザイン探索などの形式で行われる場合があります。この Issue テンプレートには
~"Actionable Insight::Exploration needed"スコープラベルが含まれています。Actionable Insight - Product change - これは UX 調査研究から派生した実行可能なリサーチインサイトです。このインサイトに対処するには、製品体験への変更が必要です。この Issue テンプレートには
~"Actionable Insight::Product change"スコープラベルが含まれています。製品の変更を必要とする実行可能なインサイトには、~"SUS::Impacting"ラベルと重大度ラベルの両方が必要であることに注意してください。
両方のテンプレートは、対応するスコープラベル（上記）を使用して、次のステップに関する進捗を追跡します。このプロセスを合理化するために、すべての詳細を再度入力する代わりに、Dovetail インサイトへのリンクを GitLab Issue に追加します。（詳細を含めたい場合は、もちろん含めることができます。）
ステップ 3: Issue に適切な
Group（例:~"group::source code"）ラベルを追加します。これは、グループレベルで実行可能なインサイトを識別および追跡するために行われます。ステップ 4: 関連 Issue 機能を使用して、これらの実行可能インサイト Issue を GitLab UX Research プロジェクトの元の Research Issue にリンクします。
既に他の場所で文書化されている場合、新しい実行可能インサイト Issue を作成する必要がありますか？
インサイトがすでに Issue 内に文書化されている場合、冗長な文書化を避けるために ~"Actionable Insight::Product change" または ~"Actionable Insight::Exploration needed" ラベルを追加できます。ただし、既存の Issue が 1) インサイト、および 2) 行うべきことを正確に対処していることを確認することが重要です。1 つまたは両方の側面で詳細が不足している場合、ラベルを追加する前に既存の Issue を更新する必要があります。
誰が実行可能なインサイトを作成および管理しますか？
実行可能なインサイトは、調査に最も近い人によって作成および管理されます。これは通常、Product Manager、Product Designer、または UX Researcher です。 ただし、最終的には実行可能なインサイトを誰が管理するかをチームが決定します。
実行可能なインサイトの管理方法
これらの Issue はパフォーマンスインジケーターとして追跡されるため、実行可能なインサイトについてのすべての議論と決定は Issue 内に文書化する必要があります。私たちは時間とともに実行可能なインサイトを追跡するため、ユーザー調査に基づいてどのような決定を行っているかを理解することが重要です。
実行可能なインサイト Issue を閉じるとき、なぜ閉じられたか、および元のアクションが実行されたかどうかを文書化することが重要です。
場合によっては、低優先度、努力が大きすぎる、技術的に実現不可能などのさまざまな理由でアクションが取られないこともあります。理由にかかわらず、Issue を閉じる際に決定を Issue に文書化してください。
どのような種類の検証調査に実行可能なインサイトが適用されますか？
問題検証とソリューション検証の両方で、実行可能なインサイトが発見された場合、実行可能なインサイトの文書化プロセスに従う必要があります。例えば:
- 問題検証: 追加の調査、次のステップのために新たに特定されたターゲット、または対処すべき特定された問題をもたらすインサイトがある場合、それらは実行可能なインサイトです。
- ソリューション検証: ユーザビリティ問題、ユーザーが経験するかもしれない痛みのポイント、またはデザインの問題を発見するインサイトがある場合、それらは実行可能なインサイトです。
上記の例は、調査の種類に関係なく、共通点が 1 つあります。インサイトは実行可能であり、したがってそのように文書化する必要があります。
さらに、UX スコアカードテストでも実行可能なインサイトを生み出すことができます。UX スコアカードテストはエキスパートレビューおよび／またはヒューリスティック評価であるため、Dovetail インサイトを作成することは適用されない場合があります。代わりに、GitLab.comで実行可能インサイトテンプレートを使用して、詳細を GitLab Issue に文書化することを確認してください。
顧客通話を通じて特定されたインサイトを含む Issue は、UX 調査の取り組みや追跡と直接関係しないため、他のインサイトとは異なるラベルを付けます。顧客通話（または他の顧客サポートチャネル）から派生したインサイトを含む Issue には、~"Customer feedback" ラベルを使用してください。
実行可能なインサイトを追跡する理由
実行可能なインサイトは GitLab で次の目的で追跡されます:
- 説明責任: 調査を実施した結果として行う必要のあることがあれば、それを行うべきです。このプロセスは、これらの実行可能なインサイトが失われたり、無視されたり、対処に時間がかかりすぎたりするのを防ぐのに役立ちます。
- 調査インパクトの測定: 現在、調査プロジェクトが製品に与える影響を正確に測定することは困難です。実行可能なインサイトを追跡することで、特定の調査プロジェクトを振り返り、調査結果の結果として特定されたアクションを確認し、それらのアクションが特定されて以来、製品内でどのようなアクションが取られたかを判断できます。
現在、次のデータが追跡されています:
- 四半期ごとの新規にオープンおよびクローズされた実行可能インサイト Issue の数
- 四半期ごとに作成された新規の実行可能インサイト Issue の数
- 四半期ごとに閉じられた実行可能インサイト Issue の数 - そしてそれらが閉じられた理由
- 実行可能インサイト Issue が完了して閉じられるまでにかかる平均日数
- 製品内で実行可能なインサイトに対処するのにどれくらい時間がかかっているかを理解することが重要
- これまでのすべての実行可能インサイト Issue の内訳
- オープンとクローズドのステータスで分割された、合計の実行可能なインサイトの数についての理解を提供します
上記のデータは、各実行可能インサイトのスコープラベルで表示できます:
時間とともに、十分なデータが集まれば、ステージ／グループレベルでこのデータをスライスして、何がうまく機能しているか（またはうまく機能していないか）を理解するのに役立つかもしれません。学んだことに基づいて、アプローチをイテレーションします。
実行可能なインサイトの将来のデータ追跡の考慮事項:
- Issue 内で活動のない、現在オープン中の合計実行可能インサイト数（>6 ヶ月間活動なし）
- 少なくとも 1 ヶ月間活動が見られない実行可能なインサイトの総数。これらの実行可能なインサイトはフォローアップされ、活動がなかった理由を理解します。
- Issue 内で活動のある、現在オープン中の合計実行可能インサイト数（活動が <=6 ヶ月前）
- 過去 1 ヶ月以内に活動が見られた実行可能なインサイトの総数。これらは何らかの方法で積極的に対処されており、破棄されていないことが暗示されます。
実行可能なインサイトをクローズドとして文書化する方法
実行可能なインサイトのタイプに関係なく、各クローズドな実行可能インサイト Issue をグルームし、適切な closed:: スコープラベルを割り当てます。現在、これは Slack ボット通知を介して UX Research リーダーシップチームによって隔週で行われる手動プロセスです。UX Research リーダーは、実行可能インサイト Issue が閉じられた理由を理解することから始め、その後単に正しい closed:: スコープラベルを追加します。既存の Sisense クエリがレポート目的で Issue をピックアップします。
有用なインサイトの作成
人々がインサイトを単独で読んで誤解する可能性があるため、インサイトにはコンテキストが必要であることを覚えておくことが重要です。調査のレポート作業を行う際は、対象者を念頭に置き、彼らに何を学んでもらいたいかを考えることが重要です。
例えば、GitLab インターフェイスで実施された調査からのすべてのインサイト（大小を問わず）を文書化して、インターフェイスが時間とともになぜ変化したかを説明することが有用な場合があります。これは、以前のデザイン決定がなぜ理想的でなかったかの記録を作成し、新しいチームメンバーとの議論に役立ちます。一方、デザイン評価やプロトタイプを用いたテストでは、これらの調査は実装前にしばしば追加のデザインイテレーションをもたらすため、包括的な調査質問に答えるインサイトの文書化に集中する方が関連性が高い場合があります。
どちらの場合でも、プロジェクトの説明の上部に簡単な「コンテキスト」セクションを追加し、関連するデザインアーティファクトへのリンクを提供することで、読者が研究の背景をよりよく理解するのに役立ちます。
Dovetail インサイトの活用
Dovetail を検索することは、GitLab ユーザーに慣れ親しんで、すでに実施された調査について学ぶ素晴らしい方法です。インサイト、ハイライト、タグ、チャートを検索およびフィルタリングして、あらゆるステージ、機能、調査の種類に関連する調査を見つけることができます。
別のアプローチは、ステージ間で実施されている調査の高レベルな概要を見たい場合、Dovetail で GitLab ワークスペースのホームページを見ることです（内部アクセスのみ）。
ユーザーペルソナをよりよく理解したい、機能のユースケースについて学びたい、問題を解決するためのコンテキストを集めたい、将来の調査研究を計画したいなど、Dovetail にはあなたのためのものがあります。
複数の調査からのインサイトの照合
デスクリサーチまたは二次調査としても知られています。既存の調査を要約および照合して、特定の調査の外側のユーザーのより広範な絵を持つことが役立つ場合があります。過去の調査からのインサイトは、将来の調査の基盤となり、ユーザーの行動とメンタルモデルの高レベルな概要を提供できます。
複数の調査からのインサイトを文書化するには、個々の Dovetail プロジェクト内でテーマにタグを付け、インサイトを作成します。複数の調査からの結果を要約するために、別の Dovetail ストーリーまたはプロジェクトを作成します。照合された調査プロジェクトを概説する Issue を GitLab で作成します。その Issue 内に、関連する Dovetail リンクと関連する Issue を追加します。
bfd74782)