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